For the complete documentation index, see llms.txt. Append
.mdto any page URL for its markdown version.
Four 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 |
| 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. |
| 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. All four SDKs 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 and Android | Order Lookup via the API, or Webhooks |
| Referral (JS SDK) | API | React Native | iOS | Android | JS Native Payments | |
|---|---|---|---|---|---|---|
| Integration effort | Lowest | Highest | Low | Low | Low | Low |
| Platform | Web | Any | React Native | Native iOS | Native Android | Web |
| Backend required | No | No (only for KYC sharing) | No | No | No | Yes, for order creation |
| Webhooks | No | Yes | Yes | Yes | Yes | Yes |
| Order lookup in the SDK | No | Yes (all orders) | By id or customer | No | No | By id |
| KYC sharing | No | Yes | No | No | No | No |
| Sell orders | Yes | Yes | No | No | No | No |
| Quote UI in your app | No | Yes | Yes | Yes | Yes | Yes |
| Checkout presentation | Redirect or iFrame | You choose | In-app WebView | In-app, headless | In-app, headless | 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.