[do not merge][POC] feat(payment): PI-5065 Oney pay grouping in one tab

[bc-dronov]

What/Why?

Payment.tsx
Introduced a generic prefix-based grouping mechanism via a standalone groupMethodsByPrefix function, applied in getDefaultPaymentMethod through GROUPED_METHOD_ID_PREFIXES.reduce(groupMethodsByPrefix, filteredMethods). Methods sharing a common ID prefix (facilypay_) are sorted numerically and collapsed into a single representative — the numerically first variant at its original position in the list. Non-representative variants are removed from filteredMethods entirely. The representative carries all variants in initializationData.groupedMethods and has its numeric prefix stripped from displayName (e.g. "3x Oney by bank card" → "Oney by bank card"). Adding support for a new group in future requires only adding a prefix to GROUPED_METHOD_ID_PREFIXES.

mapToOrderRequestBody.ts
Added support for a methodIdOverride form field that, when present, replaces the methodId derived from paymentProviderRadio. This allows the correct facilypay variant to be submitted without moving the radio selection away from the representative tab, keeping the tab visually selected regardless of which variant is chosen.

AdyenV3PaymentMethod.tsx
When groupedMethods is detected in initializationData, the component takes a lightweight path: renders only the select variant selector, a hidden SDK mount point, and the additional-action Modal (for BNPL redirect/3DS). The Adyen strategy is initialised and deinitialised directly via useEffect — no HostedWidgetPaymentComponent, no hosted card fields. On variant change the strategy is re-initialised and methodIdOverride is updated. methodIdOverride is cleared on unmount to prevent bleed into other payment methods. The non-grouped path (credit card, BCMC, etc.) is completely unchanged.

Rollout/Rollback

It's a draft PR

Testing

Screen.Recording.2026-03-25.at.15.58.35.mov

[bc-peng]

Could you please explain why do we need to do as string | undefined here?

[bc-dronov]

Removed

[bc-peng]

I’m concerned that introducing isHidden concept in the payment method list may not scale well, since some methods need to remain visible during initialization.

Instead of keeping hidden payment methods and teaching PaymentMethodList to skip them, can we consider filtering non-representative methods out of filteredMethods entirely, and let the Oney component handle the selection and showing a represented method?

[bc-dronov]

Good point, I have updated PR.

[bc-peng]

Overall, the pr looks good to me.

Can we break this function into 3 functions:

• One function to select & sort the group
• Another to build the representative
• A third to splice it back into the list

[bc-dronov]

@bc-peng Thanks for the suggestion! Since this is just a POC, we can definitely incorporate these changes during the actual development phase.