Payment methods are dynamic. The available set depends on the merchant, currency, amount, customer location, device, session mode, and method configuration. Ask for the set for the current checkout and render only what the API returns.

1. Discover methods on your server

Use the returned type and enabled values to build the selection shown to the customer. Keep a server-side allowlist for methods your business accepts, then intersect it with the returned eligible set. Do not assume that a method available for one currency or device is available for another.

2. Request a checkout

If the chosen method is no longer eligible, retrieve the session and ask the customer to select another returned method. Do not silently change the amount or create a second session.

Method-specific behavior

  • Cards: the secure component may request additional customer authentication. Treat an intermediate status as pending.
  • Wallets: display a wallet only when the device and browser expose it and the API returns it as eligible.
  • Bank methods: a customer may leave your site to authorize and return later. Preserve the order as pending until a verified event confirms it.
  • Asynchronous methods: the browser callback is a display signal, not proof of settlement. Reconcile by event and payment ID.

Ordering and fallback

Use the merchant checkout settings or the session’s method list to control order. Keep a clear fallback for an empty or changed list: explain that the selected method is unavailable and offer the methods currently returned. Record the method family, not sensitive payment details, in your own order metadata.