[benjaminwil]

Summary

This pull request makes the payment method configuration forms in solidus_admin more dynamic. Each type of Spree::PaymentMethod contains its own list of settings (Spree::Preferences). In order to make the forms dynamic, I needed to build out a component for each preference field that Solidus supports.

This mirrors the legacy solidus_backend functionality quite closely. However, this dynamic form functionality works for both new records and persisted records. In solidus_backend, dynamic forms were only enabled for already-persisted payment method records.

Demos

Dynamic form replacement on #preference_source change

Here's a video of the payment method Preference Source being toggled between no preference source and a static preference source. See how the fields are auto-filled and marked as disabled.

This functionality works on forms for new records as well as records being edited.

Screencast.From.2026-10-21.15-28-11.webm

Dynamic form replacement on #type change

Here's a video of the payment method Type being changed. See how the fields are replaced with the correct preference fields for each payment type.

This functionality works on forms for new records as well as records being edited.

Screencast.From.2026-10-21.15-22-04.webm

All supported preference fields

Here's a screenshot of all of the preference fields being rendered as part of the form for a Bogus Credit Card type payment method.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have localized any and all user-facing strings that I added to the source code.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[codecov]

Codecov Report

❌ Patch coverage is 99.04762% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 92.50%. Comparing base (6f5b2b9) to head (55e9c17).
⚠️ Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
...lidus_admin/ui/preference_fields/base/component.rb	96.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6706      +/-   ##
==========================================
+ Coverage   92.47%   92.50%   +0.02%     
==========================================
  Files        1065     1074       +9     
  Lines       21541    21637      +96     
==========================================
+ Hits        19921    20016      +95     
- Misses       1620     1621       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jarednorman]

Something looks off to me here, and I'm not 100% what's going on.

[jarednorman]

The create feature tests doesn't actually assert the values of Server and Test Mode, and if they did, they would fail.

[benjaminwil]

I have resolved the outstanding issues and rebased against main.

[benjaminwil]

I updated the commit that adds preference fields after receiving feedback on it on #6713.

(If more discussion is required on this pull request, I'm hoping we can at least merge that separately and make this diff smaller.)

[jarednorman]

Does the encrypted string component spit the encrypted values straight into the view?

[benjaminwil]

Can that be captured as a separate issue? The way it is now is parity with solidus_backend.