For the complete documentation index, see llms.txt. Append
.mdto any page URL for its markdown version.
Five SDKs wrap Banxa Hosted Checkout. Each is configured with your API key, calls the same v2 endpoints under x-api-key authentication, and presents the checkout on its platform. No backend is required for core flows.
This is the fastest way to integrate Banxa Hosted Checkout into an app whose front end you already own. If you need capabilities the SDKs do not cover, use the API integration path alongside them or instead of them.
| SDK | Platform | Language | Distribution |
|---|---|---|---|
| React Native | React Native mobile apps | TypeScript | npm, @banxa-official/react-native-sdk |
| iOS | Native iOS apps | Swift | Swift Package Manager |
| Android | Native Android apps | Kotlin | AAR |
| Flutter | Flutter apps on iOS and Android | Dart | pub.dev, banxa_payments_flutter |
| JS Native Payments | Web | TypeScript | npm, @banxa-official/javascript-native-payments-sdk |
The JS Native Payments SDK is a different package from the referral JavaScript SDK, which only builds referral URLs.
The SDKs differ in how much of the presentation you control.
| SDK | Presentation |
|---|---|
| React Native | You render the CheckoutWebView component. The SDK generates its props and detects your return URLs. |
| iOS | Headless. You pass a host view controller to startPayment and receive the outcome on a delegate. |
| Android | Headless. You render the StartPayment composable and receive the outcome on callback lambdas. |
| Flutter | Hybrid. startPayment presents the native sheet when it can, or returns a BanxaHostedCheckoutView widget for you to render. Outcomes arrive on one stream. |
| JS Native Payments | You mount the <banxa-hosted-checkout> web component, which embeds the checkout in an iframe. |
On iOS and Android, order creation and checkout presentation happen in the same call. That keeps the order inside the one-minute window in which the checkout URL must be loaded, and it means there is no supported pattern for creating an order early and presenting it later.
Choose an SDK if:
- You are building a mobile app or a web front end and want checkout presentation handled for you.
- You want faster time to integration than wiring up API calls manually.
- You want a typed interface with typed request and response models.
For some capabilities you will need the API integration path directly, either alongside the SDK or as your primary path:
| Capability | Path |
|---|---|
| Sell orders (off-ramp) | API integration. Only the Flutter SDK exposes sell order creation, through OrderType.sell; the other four cover buy orders only |
| KYC data sharing (Sumsub token share) | API integration. Uses HMAC auth, which the SDKs do not use |
| Full order list across all customers | GET /{partnerRef}/v2/orders via API integration |
| Order lookup on iOS, Android, and Flutter | Order Lookup via the API, or Webhooks |
| Referral (JS SDK) | API | React Native | iOS | Android | Flutter | JS Native Payments | |
|---|---|---|---|---|---|---|---|
| Integration effort | Lowest | Highest | Low | Low | Low | Low | Low |
| Platform | Web | Any | React Native | Native iOS | Native Android | Flutter (iOS, Android) | Web |
| Backend required | No | No (only for KYC sharing) | No | No | No | No | Yes, for order creation |
| Webhooks | No | Yes | Yes | Yes | Yes | Yes | Yes |
| Order lookup in the SDK | No | Yes (all orders) | By id or customer | No | No | No | By id |
| KYC sharing | No | Yes | No | No | No | No | No |
| Sell orders | Yes | Yes | No | No | No | Order creation only | No |
| Quote UI in your app | No | Yes | Yes | Yes | Yes | Yes | Yes |
| Checkout presentation | Redirect or iFrame | You choose | In-app WebView | In-app, headless | In-app, headless | In-app, native sheet or WebView widget | In-page iframe |
Webhooks are configured in the merchant dashboard, not in the SDK, and are the authoritative source of order state on every path.