Skip to main content
getPaymentMethodsViews returns pre-built views for the payment methods you want to show. Use it to display the SDK’s full payment methods list, a wallet button (Apple Pay or Google Pay), or any combination available on your platform. This feature applies to payment flows only. It is not available for enrollment.
The list is selection-only. It renders payment methods for the shopper to choose from, but does not process payments on its own. After the shopper picks a method, you start the transaction to process the payment. This makes the list composable with any payment flow — including headless integrations where you collect the payment data yourself in your own UI. Mount the list for method selection, receive the selection through the selection callback or controller, and start the transaction with your own pre-collected payment data. See the Headless migration guides (Web, iOS, Android, React Native) for details.

Compact or unfolded: choose the layout

The SDK renders the full list of payment methods enabled in your dashboard: logos, names, and the shopper’s saved methods included. And if you prefer fewer taps, you can choose to show each method’s form expanded right inside the list, so shoppers enter their details without leaving it, for a faster checkout. You enable the expanded layout from the Checkout Builder in your Yuno Dashboard, no code needed.
The payment methods list

Compact list: shoppers select a method to open its form separately.

The list with forms expanded inline

Unfolded display: forms expand directly inline for faster checkout.

Compact layout (default)

The compact layout is the standard out-of-the-box behavior. It requires zero dashboard configuration:
  • The list displays payment method logos, names, and saved methods.
  • The shopper taps a method to select it.
  • Starting the transaction opens or mounts that method’s payment form separately to collect details, or you trigger submission from your own custom Pay button.
Combine compact selection with headless. Because compact mode functions purely as a selection menu, you can use it alongside a headless integration. Mount the list for method selection, receive the shopper’s choice through your platform callback or controller, and start the transaction passing your own custom-collected payment data. See the Headless migration guides (Web, iOS, Android, React Native) for code examples.

Unfolded layout

The unfolded layout expands each payment method’s form directly inside the list row, allowing shoppers to enter card or payment details immediately without separate screens or extra taps. To enable it, toggle Checkout Builder → Styling → Unfolded display in your Yuno Dashboard. When unfolded is active:
  • Selecting a method expands its payment form directly inline inside the list item.
  • Starting the transaction submits the already-filled inline form.
  • Express wallets (Apple Pay, Google Pay, PayPal) render their native buttons directly in the row.

Before you start

Your backend must have created a checkoutSession and the Transaction must be constructed with that session. See Get Started.

Implementation

Call getPaymentMethodsViews with the types you want and a controller. The SDK returns a map of PaymentMethodType to view. Embed each view in your layout. When the user picks a method, your controller receives a PaymentMethodSelected that you pass to Transaction.start().
Each view in the returned object exposes a .mount({ elementSelector, ...config }) method. Per-view styling (Apple Pay button type, Google Pay color, etc.) lives on .mount(). Options you pass to a wallet’s mount() override the same keys in the transaction config’s externalButtons. paymentMethodList.mount() also takes scrollContainerSelector, visibleTriggerOffsetPx, and bottomOffsetPx for a list inside a scrolling container. They override the same keys in the transaction config’s paymentListConfig.What start() does after a selection depends on the Checkout Builder. With forms unfolded inside the list, start({ paymentMethod }) submits the form the shopper already filled in, so it is your Pay action. With folded forms, start() mounts the selected method’s form into the elementSelector of your transaction config and resolves. The shopper then pays from that form’s button. If you set showPayButton: false, call transaction.submit() from your own button instead. Pass elementSelector on the transaction config so the folded form has somewhere to render.

PaymentMethodType

On React Native, pass objects: { kind: 'PAYMENT_METHOD_LIST' }, { kind: 'GOOGLE_PAY', cta, theme, cornerRadius } and { kind: 'APPLE_PAY', buttonType, buttonStyle }, with the same button options as the native SDK of each platform. On Web, pass the values as camelCase strings in types: 'applePay', 'googlePay', 'paypal', 'paypalBraintree', 'samsungPay', 'revolutPay', and 'paymentMethodList'. On Android, a type that does not apply to the platform or configuration comes back as null. On iOS every requested type comes back with a view. On Web every requested type is returned and the check happens in mount(). When the wallet is not enabled for the checkout session, the SDK logs There are not valid payment methods, reports the failure through onStatus, and the promise that mount() returns rejects. mount() is typed void, so await it to catch that rejection, and mount only the wallets enabled for the session.
On Android, PaymentMethodType is a sealed interface rather than a set of string constants: GOOGLE_PAY corresponds to PaymentMethodType.GooglePay(...), which also carries the button customization (cta, theme, cornerRadius), and PAYMENT_METHOD_LIST corresponds to PaymentMethodType.PaymentMethodList. APPLE_PAY does not exist on Android.On iOS, APPLE_PAY is an enum case with associated values, both optional: .APPLE_PAY(type: .buy, style: .black) takes a PKPaymentButtonType and a PKPaymentButtonStyle (defaults .plain and .automatic), which carry the Apple Pay button customization. The bare spelling .APPLE_PAY does not compile — always write .APPLE_PAY().

Express buttons

APPLE_PAY, GOOGLE_PAY, and PAYPAL return the native express buttons, ready to use. You style them through the standard view modifiers of each platform (size, padding, corner radius, etc.). The SDK only adds a loader on top while the payment flow is initializing. On Web, PAYPAL_BRAINTREE, SAMSUNG_PAY, and REVOLUT_PAY are express buttons too, and you style all of them through the options of mount().
Apple Pay buttonGoogle Pay buttonPayPal button
You do not need to call Transaction.start() for express buttons. Tapping the button is the user’s confirmation, so the SDK starts the transaction internally and reports the result through onStatus.This also holds inside the list on Web. When the shopper selects an express wallet row, its button renders inside the row and is the pay control. start() for that selection returns without doing anything, so hide your own Pay button while onPaymentSelected reports an express type (APPLE_PAY, GOOGLE_PAY, PAYPAL, PAYPAL_BRAINTREE, SAMSUNG_PAY, or REVOLUT_PAY).

PaymentListController

The controller you pass to getPaymentMethodsViews. On iOS, Android and React Native only onPaymentSelected is required. On Web onPaymentSelected is optional, but without it the list cannot tell you what the shopper picked, so pass it whenever you request 'paymentMethodList'.
* onHeightChange is optional to implement, but you must apply the reported height when your layout constrains the list.
On Web and iOS, onPaymentSelected can fire before any tap. When the list preselects the shopper’s preferred method on mount, the callback runs with selectionSource: 'auto' (.auto on iOS). A tap runs it with selectionSource: 'user' (.user on iOS). On Web it also fires when the shopper taps an express button you mounted. The Web PaymentMethodSelected is { type, name?, vaultedToken?, selectionSource? }. Keep the latest value and pass it to start() only from your own Pay control. On React Native, selectionSource is 'AUTO' or 'USER'.
If the list cannot be loaded because the payment methods service fails, the SDK reports it through your TransactionController.onStatus with status INTERNAL_ERROR and a message: source backend with the backend error code in code (the HTTP status when the body has none) and the error body in raw, or source sdk for network failures, with context MethodsViewImplementation.getPaymentMethods on iOS and paymentMethodList.getPaymentMethods on Web. The list stays empty: show your own error state or request the views again to retry.
The Edit / remove control that lets a shopper delete a saved method — and the only thing that makes onUnenroll fire — is rendered only when edit_payment_method_list is enabled in Checkout Builder → Styling in your Yuno Dashboard. It is off by default on iOS and Android, so until you turn it on the saved methods show no remove affordance and onUnenroll is never invoked. The same setting controls the remove control on Web. Web has no onUnenroll callback. After a removal the SDK refetches the session’s payment methods and the list re-renders.

Notes

  • getPaymentMethodsViews is synchronous on iOS, Android and Web. On React Native it returns a Promise.
  • You can request any combination of types available on your platform in a single call.
  • The PaymentMethodSelected delivered by onPaymentSelected is what you pass to Transaction.start(). See Get Started.
  • Checking method availability before mounting custom lists (Web): If you build your own custom payment method selector instead of using paymentMethodList, use transaction.isPaymentMethodAvailable({ paymentMethodType }) to verify whether express wallets (such as APPLE_PAY or GOOGLE_PAY) or specific methods are eligible to render on the customer’s current device and checkout session before displaying them.
  • On Web, once a payment on the session reaches a final status, the SDK removes the list and marks the checkout session as finished. start(), submit(), and mount() on that session then throw. To pay again, create a new checkout session and a new Transaction, or call transaction.updateCheckoutSession() with the new session, then mount the list again.