- Configuration endpoints now available — Four new
GETendpoints 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 foronramporofframp, 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) foronramporofframp.GET /eapi/v0/fiats/{transactionType}— returns supported fiat currencies and their available payment methods foronramporofframp.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 acheckoutUrlfromPOST /{partner}/v2/buyas thesourceattribute 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.statuswith valuesPENDING,UNDER_REVIEW,ACTION_REQUIRED,VERIFIED, andREJECTED. Use this to track verification progress without pollingGET /eapi/v0/identities/{identityReference}, particularly useful after KYC token sharing, which is processed asynchronously. → Webhooks
mobileNumbernow optional on KYC token share — Previously required onPOST /eapi/v0/identities/share/token. Note: Interac (Canada) requires a mobile number to process payments — for headless ramp flows using Interac, omittingmobileNumberwill cause the ramp to fail.
- Rate locking added —
GET /eapi/v0/quotereturns a confirmed rate and aquoteIdthat can be passed toPOST /eapi/v0/rampsto guarantee the price at ramp creation.
kyc.statusadded to GET identity response —GET /eapi/v0/identities/{identityReference}now includeskyc.status, the verification outcome of the customer's submitted identity documents (selfie + document).VERIFIEDindicates 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_VERIFICATIONadded to customer webhooks — Customer webhook payloads now includeEXTRA_VERIFICATIONas 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/limitsresponse updated — The response now includesremainderacross each window, showing the customer's remaining transaction capacity (daily, weekly, monthly, and annual).CUSTOMER_BLACKLISTEDrenamed toACCOUNT_BLOCKED— Ramp and customer webhook payloads that previously returnedCUSTOMER_BLACKLISTEDnow returnACCOUNT_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_DETAILSrequirement when any personal data was missing. It now returns individual requirements —NAME,DOB, andADDRESS— 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/rampsfor 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/rampsreturns paginated ramp history for a givenidentityReference. Supports filtering by status and transaction type.
- Market rates added to price and quote responses —
GET /eapi/v0/priceandGET /eapi/v0/quoteresponses now include amarketRateobject with crypto-to-fiat and forex reference rates at the time of the quote.
GET /eapi/v0/identities/{identityReference}response updated — The response now includesaccount.blockedandaccount.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/falseand any outstandingrequirements[]. → 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 existingfiatAmount. 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 eitherfiatAmountorcryptoAmount(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, andtransaction_hashfields in the final status notification.
- ACH off-ramp bank account details added to payment instructions —
sourceDepositInstructionsfor ACH off-ramp now includesachRoutingNumberandachAccountNumberfor the destination bank account.