BVNK launches beta API for virtual USDC spending cards

BVNK has opened a Cards (beta) API that lets fintech partners attach virtual spending cards to individual customer USDC wallet balances. The capability is documented by BVNK as of September 20, 2026 and issues cards against the BVNK_EPC_WALLET ledger while using a front-end SDK to keep sensitive card data off partner servers.

Fintechs that already issue USDC wallets through BVNK’s Embedded Custom API can follow an integrated flow to request cards. The documented sequence begins with an eligibility check, proceeds to create a CARD_AGREEMENT signing session, then submits a POST /card/v1/cards request, renders PAN and CVV via BVNK’s PCI-scoped SDK, and subscribes to webhooks for card and transaction status updates.

The SDK exposes PAN, CVC, expiry and cardholder name inside an iframe hosted by BVNK so partners do not receive cardholder data. Digital wallet provisioning is pull-based: customers view card details in the SDK, add them to Apple Pay or Google Wallet, and complete issuer OTP. Card-not-present transactions use issuer 3DS OTP for authentication.

Partners must meet prerequisites before issuing a card. Cards must be enabled on the BVNK account and API keys must use Hawk authentication. Integrations should be tested in the sandbox at api.sandbox.bvnk.com before switching to production at api.bvnk.com. Customers must be created and KYC-approved using Customers v1; the v2 onboarding flow is not supported for card issuance. Each customer must have a USDC wallet (mainWalletId), a verified phone and email, and be located in a jurisdiction where the relevant BVNK entity is authorised to issue cards. Partners must be PCI-compliant, submit their card issuance UI to BVNK for review, and complete a separate CARD_AGREEMENT acceptance step after onboarding.

Issuance is asynchronous. A typical POST /card/v1/cards call returns CREATED, moves to PENDING while the card provider provisions, and reaches ACTIVE or CANCELLED as reported via the bvnk:card:card:updated webhook. BVNK documents lifecycle statuses including FROZEN (reversible by the partner), BLOCKED (partner cannot unfreeze) and CANCELLED (permanent). Partners can freeze, unfreeze or cancel cards using the Manage Cards APIs and can query pending, settled and declined transactions.

Testing is supported in the sandbox. Partners can call POST /card/v1/simulation/transactions to authorise test amounts and then PATCH transactions to SETTLE, REVERSE or REFUND without live network traffic. Webhooks for card updates and transaction status changes must be acknowledged immediately with HTTP 200 and validated using signature verification. Sandbox configuration does not copy to production; go-live requires a separate Portal configuration and production keys.

Operational limits include one active card or pending application per customer and GET /card/v1/cards returns the most recent record for a customer. Card artwork can be customised by submitting artwork for scheme approval; BVNK cites a typical two-to-three week review and returns a cardArt identifier that partners must track. BVNK does not expose cancellation reasons and customers may reapply after a CANCELLED outcome.

BVNK positions Cards as a spend layer that works alongside existing USDC rails such as payouts, virtual accounts, ACH/wire off-ramps and payroll. The product is jurisdiction-gated and remains in beta; partners are advised to confirm supported markets and entity mappings with their BVNK account manager before building.