# Changelog

> For the complete documentation index, see [llms.txt](https://docs.banxa.com/llms.txt). Append `.md` to any page URL for its markdown version.


## 2026-09-04

#### Added

- **Flutter SDK now available (preview)** — The Banxa Flutter SDK (`banxa_payments_flutter`, 0.1.0) is now available from pub.dev as a payment execution layer for Banxa Native in Flutter apps. Configure once with `BanxaPayments.configure`, then call `BanxaPayments.startPayment` to create the order and present the native payment sheet for cards, Apple Pay, and Google Pay. When no native route is available it returns a `BanxaHostedCheckoutView` widget instead, and outcomes from both routes arrive on the `checkoutEvents` stream. It joins the React Native, iOS, Android, and JS Native Payments SDKs. The Native API continues to handle identity, eligibility, and pricing, and the SDK does not accept a `quoteId`. Note: `startPayment` does not call any eligibility endpoint, so continue to call `POST /eapi/v0/eligibility` from your backend and gate on `paymentReady` to drive the KYC remediation loop. Requires Flutter `>=3.44.9`, Dart `>=3.12.2`, iOS 15.0+, and Android minSdk 24+. This is a preview release: pin `0.1.0` rather than a caret range. → [Flutter SDK Reference](/products/native-api/docs/sdk/flutter-sdk-reference)


## 2026-08-12

#### Added

- **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](/products/native-api/docs/sdk/ios-sdk-reference) · [Android SDK Reference](/products/native-api/docs/sdk/android-sdk-reference)


## 2026-08-04

#### Changed

- **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](/products/native-api/docs/getting-started/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](/products/native-api/docs/transaction-lifecycle/webhooks)


## 2026-07-08

#### Added

- **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](/products/native-api/docs/sdk/javascript-native-payments-sdk-reference)


## 2026-06-18

#### Added

- **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.


## 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 `<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](/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. → [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.