feat: persist user input values when selected payment method is changed

[Shivam25092001]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

Persists user-entered dynamic field values when the selected payment method type changes, so a shopper who types into shared fields (name, email, phone, address, etc.) doesn't lose that input after switching payment methods.

Why this happens:

In PaymentElement.res the payment-method subtree is rendered under <ErrorBoundary key={selectedOption} ...>. Switching the payment method type changes the key and remounts the whole subtree (DynamicFields → ReactFinalForm.Form), destroying all form state. Previously only Country survived, because it round-trips through the persistent userCountry atom.

Changes:

• New Recoil atom userDynamicFieldsValues : Dict.t<string> in RecoilAtoms.res, keyed by confirmRequestWritePath. It lives above the remount boundary, so its contents survive the payment-method switch.
• Persist on change — in FormBody's onFormChange, the typed values of persistable fields are written into the atom every time the form updates.
• Restore on remount — a new initialValuesWithUserInputOverride memo seeds the form's initialValues from the cached atom (layered on top of the existing billing-details override), and the ReactFinalForm.Form now consumes this override.
• New persistableFields set — the fields whose values we persist. Unlike missingRequiredFieldsFiltered (which dedups Email/CardHolderName down to the single visible input), this keeps both name paths (first_name + last_name) and every email path, since the combined name/email inputs write all of them into RFF. It excludes self-managed fields (Country / PhoneCountryCode), which own their value outside RFF and are seeded through their own atom/local-state path.
• Refactor — extracted the shared "does this field render a visible input?" logic out of the missingRequiredFieldsFiltered filter into a single rendersVisibleInput helper, reused by both missingRequiredFieldsFiltered and persistableFields.

No change to the '/confirm' payload shape — seeding stays restricted to the current payment method's rendered fields.

How did you test it?

Manually verified in the SDK: entered values into shared dynamic fields (name / email / phone / address), switched between payment method types, and confirmed the previously typed values are restored on the re-rendered form instead of being wiped.

Screen.Recording.2026-08-06.at.6.18.32.PM.mov

Checklist

• I ran npm run re:build
• I reviewed submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

[XyneSpaces]

[should-fix] Recompute initialValuesWithUserInputOverride when the persisted dynamic-field cache or persistableFields changes. With the current dependency list, updates to userDynamicFieldsValues can re-render this component but keep the memoized initial values stale, so a payment-method switch can still remount the form without the latest typed values.

  }, [initialValuesWithBillingDataOverride, cachedUserDynamicFieldsValues, persistableFields])

[ArushKapoorJuspay]

Could you please explain why PhoneCountryCode and Country are marked as false

[Shivam25092001]

They are being maintained already by userCountry atom.

[Shivam25092001]

Also, PhoneCountryCode is excluded because its dropdown is controlled by component-local state (valueDropDown)

[Shivam25092001]

Removed isPersistableRenderType entirely to simplify the logic.

Description:

• CountryDropdownField derives the rendered country from field.input.value (storedIso), falling back to the userCountry atom only when RFF is empty, and pushes the effective value back into the atom via an effect. Since RFF is the display source of truth, replaying the cached user value into initialValues before the field re-registers is enough to restore the pick — the atom path is just a fallback, not a competing owner.

• PhoneCountryCodeDropdownField has the paired fix: The component rebuilds that UI value from field.input.value (storedCode) so a cached dial code survives the remount.

With both fields reading from RFF, the generic persistence path works for them the same way it works for every other dynamic field.

[sakksham7]

Can you also please add a use case of Update Intent flow with these new changes in the PR description?

[Shivam25092001]

Can you also please add a use case of Update Intent flow with these new changes in the PR description?

Screen.Recording.2026-08-12.at.3.17.59.PM.mov

@sakksham7

[sakksham7]

Can you also please add a use case of Update Intent flow with these new changes in the PR description?

Screen.Recording.2026-08-12.at.3.17.59.PM.mov
@sakksham7

CC: @ArushKapoorJuspay