# Changelog ## 2026-06-02 #### Added - **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 `` 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](/products/native-api/docs/guides/apple-pay) · [Google Pay](/products/native-api/docs/guides/google-pay) ## 2026-05-11 #### Added - **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](/products/native-api/docs/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](/products/native-api/docs/how-it-works/kyc-token-sharing) ## 2026-05-04 #### Added - **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. KYC webhooks are opt-in — contact Banxa to have them enabled on your account. → [Webhooks](/products/native-api/docs/transaction-lifecycle/webhooks) #### Changed - **`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. ## 2026-04-09 #### Added - **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. ## 2026-04-08 #### Added - **`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](/products/native-api/docs/how-it-works/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. #### Changed - **`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. ## 2026-04-07 #### Added - **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](/products/native-api/docs/how-it-works/otp-verification) ## 2026-03-24 #### Added - **Basic identity creation** — Create a customer identity with personal details to enable lower-tier KYC transactions. → [Identity & KYC](/products/native-api/docs/how-it-works/identity-kyc) ## 2026-03-23 #### Added - **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. ## 2026-03-16 #### Changed - **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. ## 2026-03-12 #### Added - **Ramp history added** — `GET /eapi/v0/ramps` returns paginated ramp history for a given `identityReference`. Supports filtering by status and transaction type. #### Changed - **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. ## 2026-03-04 #### Changed - **`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. ## 2026-02-04 #### Added - **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](/products/native-api/docs/how-it-works/interpreting-eligibility) ## 2025-11-20 #### Changed - **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](/products/native-api/docs/how-it-works/flexible-amounts) - **Webhook payload updated** — Ramp webhook payloads now include `processingFee`, `networkFee`, and `transaction_hash` fields in the final status notification. ## 2025-10-31 #### Added - **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.