Skip to content
Last updated

Supported Payment Methods

For the complete documentation index, see llms.txt. Append .md to any page URL for its markdown version.

Banxa Native supports bank transfers, cards, and native wallets. Different methods are executed through different layers of the integration.

Reference table

Payment methodExecution
Interac (Canada)Native API — headless
PayID (Australia)Native API — headless
SEPA (EU / EEA)Native API — headless
ACH (US)Native API — headless
Visa, MastercardSDK native payment sheet
Apple PaySDK native payment sheet
Google PaySDK native payment sheet
PayPal, iDEAL, KlarnaBanxa Hosted Checkout — see Alternative payment methods
PIX, VietQR, SPEI, Khipu and other local methodsBanxa Hosted Checkout — see Alternative payment methods

Prepaid cards are not supported.

Why bank transfers and cards are handled differently

Bank transfers are executed directly via the Native API — no card data is involved, so there are no PCI compliance requirements on the partner side.

Card payments, Apple Pay, and Google Pay cannot be handled through the API alone without PCI compliance, which is a significant certification burden that most partners do not hold. The Banxa SDK integrates with Primer to process card data securely in a certified environment, meaning partners can offer native card and wallet payments without needing to achieve PCI compliance themselves.

Alternative payment methods

Alternative payment methods (APMs) cover redirect-based methods such as PayPal, iDEAL, and Klarna, and scan-to-pay methods such as PIX and VietQR. These are not supported headless through the Native API.

Ramp creation will fail

Creating a ramp with POST /eapi/v0/ramps using an alternative payment method returns an error. The Native API returns no redirect URL and no QR payload for these methods, so they cannot be rendered in your own frontend.

How to offer them

You can still offer APMs inside your Native integration. Only the payment step is handled by Banxa.

  1. Check eligibility as normal. The Native API eligibility endpoint supports alternative payment methods. Use it to confirm the customer is cleared and to determine which methods are available to them.
  2. Create the order through Banxa Hosted Checkout. Either call the Banxa Hosted Checkout Buy endpoint (POST /{partner}/v2/buy) directly, or use the SDK equivalent. The response includes a redirect URL.
  3. Present the redirect URL. If you called the endpoint directly, you choose how to render it — a full redirect, a webview, or an iframe. If you use the SDK, the webview or iframe is handled for you.

Everything up to the payment step — identity, eligibility, quoting, method selection — stays in your app and on the Native API. The customer only enters a Banxa-hosted surface to complete the payment itself.

OTP configuration

This flow assumes OTP is disabled on your account. If OTP is enabled, the hosted surface will also collect the one-time password, which adds a step to the customer's experience. Confirm your configuration with your Banxa integration contact.

Next steps