Changelog

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

• iOS and Android SDKs now available — The Banxa iOS SDK and Banxa Android SDK (both BanxaPaymentSDK) are now available as payment execution layers for Banxa Native on native mobile. Each configures once and starts a payment in a single call: startPayment(request:controller:) on iOS and the StartPayment composable on Android. Both run eligibility, order creation, and native payment sheet presentation internally, and report the outcome on a delegate (iOS) or callback lambdas (Android). They join the React Native SDK and the JS Native Payments SDK, so all four front-end stacks are now covered. The Native API continues to handle identity, eligibility, and pricing, and neither SDK accepts a quoteId. Note: the internal eligibility result is not exposed to your app, so continue to call POST /eapi/v0/eligibility from your backend and gate on paymentReady to drive the KYC remediation loop. → iOS SDK Reference · Android SDK Reference

• Nonce should now be generated in microseconds (16 digits) — All HMAC documentation and code examples now generate the nonce as a Unix timestamp in microseconds. Seconds (10 digits) and milliseconds (13 digits) remain accepted, so this is non-breaking and requires no change to a working integration. Millisecond nonces collide under concurrent load and are rejected as reused (40003); microsecond precision reduces that materially. Note that padding a millisecond timestamp with three zeros does not help — the nonce must come from a clock with genuine sub-millisecond resolution. → Authentication
• Webhook nonce format documented — Banxa signs outbound webhooks with a 16-digit microsecond nonce. Webhook pages now state this explicitly, show a worked Authorization header, and instruct partners to treat the nonce as an opaque string rather than parsing or length-validating it. → Webhooks

• JS Native Payments SDK now available (web): The Banxa JS Native Payments SDK (@banxa-official/javascript-native-payments-sdk, v1.0.0) is now available as the web payment execution layer for Banxa Native. The <banxa-primer-checkout> web component presents the native payment sheet for cards, Apple Pay, and Google Pay in the browser, gated on eligibility paymentReady, while the Native API continues to handle identity, eligibility, and pricing. It is the web counterpart to the React Native SDK. → JS Native Payments SDK Reference

• Configuration endpoints now available — Four new GET endpoints return supported options for building transaction and onboarding flows. Use these to populate payment method selectors, crypto and fiat pickers, and country dropdowns without hardcoding values in your client.
  • GET /eapi/v0/payment-methods/{transactionType} — returns supported payment methods for onramp or offramp, including supported fiat currencies per method.
  • GET /eapi/v0/cryptocurrencies/{transactionType} — returns supported cryptocurrencies and their blockchain networks (with contract address, minimum amount, and restricted countries) for onramp or offramp.
  • GET /eapi/v0/fiats/{transactionType} — returns supported fiat currencies and their available payment methods for onramp or offramp.
  • GET /eapi/v0/countries — returns countries supported for KYC and transactions, including state/province lists where applicable.

• Embedded Payment Button now available — Apple Pay and Google Pay can now be embedded in web apps (Vanilla JS, React, Vue) via @banxa-official/embedded-checkout-web-component (v0.1.0). Pass a checkoutUrl from POST /{partner}/v2/buy as the source attribute on <banxa-checkout> and the component renders the button and presents the native payment sheet. Provisioning required — contact your Banxa integration contact to enable the button-only setting on your environment before use. → Apple Pay · Google Pay

• React Native SDK now available — The Banxa React Native SDK (@banxa-official/react-native-sdk) is now available. Use it alongside the Native API to present native payment sheets for cards, Apple Pay, and Google Pay — payment methods that require PCI-compliant tokenisation via Primer and cannot be handled through the API alone. Bank transfers continue to run directly through the Native API without the SDK. → SDK Reference
• Sumsub Copy Applicant support — A second Sumsub integration approach is now available alongside Reusable KYC. Copy Applicant retrieves name, DOB, selfie, document, address, and TIN directly from your Sumsub account, satisfying a broader set of eligibility requirements without additional PATCH calls. Copy Applicant is a separate Sumsub product and must be configured by Banxa — contact Banxa to have it enabled on your account. → KYC Token Sharing

• KYC status webhooks — Banxa now sends a webhook when a customer's identity verification status changes. The payload includes kyc.status with values PENDING, UNDER_REVIEW, ACTION_REQUIRED, VERIFIED, and REJECTED. Use this to track verification progress without polling GET /eapi/v0/identities/{identityReference}, particularly useful after KYC token sharing, which is processed asynchronously. → Webhooks

• mobileNumber now optional on KYC token share — Previously required on POST /eapi/v0/identities/share/token. Note: Interac (Canada) requires a mobile number to process payments — for headless ramp flows using Interac, omitting mobileNumber will cause the ramp to fail.

• Rate locking added — GET /eapi/v0/quote returns a confirmed rate and a quoteId that can be passed to POST /eapi/v0/ramps to guarantee the price at ramp creation.

• kyc.status added to GET identity response — GET /eapi/v0/identities/{identityReference} now includes kyc.status, the verification outcome of the customer's submitted identity documents (selfie + document). VERIFIED indicates that document and liveness checks passed; other values indicate verification is in progress or requires action. See Identity & KYC for the full status reference.
• EXTRA_VERIFICATION added to customer webhooks — Customer webhook payloads now include EXTRA_VERIFICATION as a KYC status event, triggered when a customer requires enhanced due diligence review. Contact Banxa to have this webhook enabled on your account.

• GET /eapi/v0/identities/transactions/limits response updated — The response now includes remainder across each window, showing the customer's remaining transaction capacity (daily, weekly, monthly, and annual).
• CUSTOMER_BLACKLISTED renamed to ACCOUNT_BLOCKED — Ramp and customer webhook payloads that previously returned CUSTOMER_BLACKLISTED now return ACCOUNT_BLOCKED. Update any status-handling logic that references the old value.
• KYC eligibility requirements now individually itemised — The eligibility response previously returned a single PERSONAL_DETAILS requirement when any personal data was missing. It now returns individual requirements — NAME, DOB, and ADDRESS — so you can prompt for exactly what is outstanding rather than re-collecting data your customer has already provided.

• Headless OTP added — Partner backends can now send and verify one-time passcodes server-to-server without exposing the verification step to the client. Contact your Banxa integration manager to enable. → OTP Email Verification

• Basic identity creation — Create a customer identity with personal details to enable lower-tier KYC transactions. → Identity & KYC

• Transaction limits — Retrieve applicable limits for a given identity and transaction context. Returns provider limits and customer tier limits across daily, weekly, monthly, and annual windows.

• ACH terms of service acceptance now required — POST /eapi/v0/ramps for ACH bank transfer methods now requires explicit terms of service acceptance in the request payload. See the API Reference for the required field.

• Ramp history added — GET /eapi/v0/ramps returns paginated ramp history for a given identityReference. Supports filtering by status and transaction type.

• Market rates added to price and quote responses — GET /eapi/v0/price and GET /eapi/v0/quote responses now include a marketRate object with crypto-to-fiat and forex reference rates at the time of the quote.

• GET /eapi/v0/identities/{identityReference} response updated — The response now includes account.blocked and account.createdAt, making it possible to check account status and creation timestamp in a single call.

• Transaction eligibility — Evaluate whether a transaction can proceed for a given identity, payment method, fiat/crypto pair, and amount. Returns paymentReady: true/false and any outstanding requirements[]. → Interpreting Eligibility

• Ramp creation now supports cryptoAmount — You can now specify the exact amount of crypto to be received (on-ramp) or sent (off-ramp), in addition to the existing fiatAmount. This enables crypto-fixed transactions — for example, "receive exactly 200 USDT" — where the fiat cost is calculated from the crypto side rather than fixed upfront. Previously, only fiat-fixed ramps were supported. Provide either fiatAmount or cryptoAmount (not both), using the same parameter and value from the corresponding price request. → Pricing & Amount Inputs
• Webhook payload updated — Ramp webhook payloads now include processingFee, networkFee, and transaction_hash fields in the final status notification.

• ACH off-ramp bank account details added to payment instructions — sourceDepositInstructions for ACH off-ramp now includes achRoutingNumber and achAccountNumber for the destination bank account.