Table of Contents
Fintechs that already issue USDC wallets through BVNK's Embedded Custom API can now attach a virtual spending card to each customer's wallet balance.
The named object is BVNK Cards (beta): partners call POST /card/v1/cards with ledger type BVNK_EPC_WALLET and assetCode: USDC, then display PAN/CVV through BVNK's PCI-scoped SDK.
This guide follows BVNK's public docs as of September 20, 2026: Issue cards, Prepare for integration, and Create cards. It does not invent fee schedules, unsupported countries, or unpublished hostnames.
Key Takeaways
- BVNK Cards issue virtual USDC-backed spend cards via Embedded Custom API against BVNK_EPC_WALLET.
- Flow: eligibility GET → CARD_AGREEMENT session → POST /card/v1/cards → SDK for PAN/CVV → webhooks for status and spend.
- Partners must be PCI-compliant but need no PCI certification; sensitive data stays in BVNK's iframe/SDK.
- Docs require Customers v1 + Agreements v1; v2 onboarding customers cannot receive cards yet.
- Named downside: Cards are beta, one card per customer, eligible jurisdictions only, and UI must pass BVNK review.
Who this is for
Use BVNK Cards if you already run Embedded Custom wallets and need end users to spend USDC locally without leaving your branded app.
Typical buyer: remittance or neo-bank platforms that issue USDC wallets today and want tap-to-pay or online card spend against that balance. BVNK's embedded wallets product page positions cards as the Spend layer next to Send, Receive, Store, Convert, and Earn.
Stablecoin Insider previously covered BVNK leadership context in Jesse Hemson-Struthers at BVNK and the Marqeta partnership for stablecoin-backed cards. This post is the operator how-to for the Cards API itself.
What BVNK Cards enables
Per BVNK docs, partners can issue virtual cards linked to a customer USDC wallet, freeze/unfreeze/cancel via API, query pending/settled/declined transactions, and receive webhooks for card and transaction status changes.
Digital wallet provisioning is pull-based: the customer views card details in the SDK, enters them into Apple Pay or Google Wallet, and completes issuer OTP. Card-not-present spend uses 3DS OTP from the card issuer.
| Capability | What operators get | Doc source |
|---|---|---|
| Issue virtual cards | POST /card/v1/cards linked to USDC BVNK_EPC_WALLET | Create cards |
| View PAN/CVV | BVNK front-end SDK iframe (partner never stores CHD) | Create cards / PCI |
| Card controls | Freeze, unfreeze, cancel via Manage Cards APIs | Manage Cards |
| Webhooks | bvnk:card:card:updated and bvnk:card:transaction:status-change | Prepare + Create |
| Sandbox sims | POST /card/v1/simulation/transactions (+ PATCH settle/reverse/refund) | Create cards |
Prerequisites before the first POST
Complete these before calling issuance. Skipping any of them returns eligibility failures or async CANCELLED cards.
- Cards feature enabled on your BVNK account (contact Solutions / account manager).
- Hawk-authenticated API keys in sandbox first (api.sandbox.bvnk.com), then production (api.bvnk.com).
- Customer created and KYC-approved via Customers v1 (not v2).
- Customer has a USDC wallet; capture mainWalletId from Portal/API.
- Verified phone and email on file (partner verifies; BVNK does not re-validate contacts).
- Customer in a supported jurisdiction under a BVNK entity authorised to issue cards.
- Partner is PCI-compliant (certification not required).
- Card issuance UI approved by BVNK (terms acceptance is a separate step after onboarding; submit a final UI video).
- Webhooks configured with signature validation for card and transaction events.
Full checklist lives in Prepare for cards integration.
Step 1: Check customer eligibility
Call GET /card/v1/customer-eligibility-status with customerId and ledgerType=BVNK_EPC_WALLET.
Eligible responses return eligible: true with an empty requirements array. Otherwise resolve each requirement (for example missing verified phoneNumber) before continuing.
Step 2: Create the CARD_AGREEMENT signing session
The customer must accept card issuer terms after BVNK onboarding, not inside general KYC.
POST platform/v1/customers/agreement/sessions with useCase CARD_AGREEMENT, customerType (for example INDIVIDUAL), countryCode, and customerReference. Present terms in your UI, then PUT the session reference with status SIGNED and the customer's ipAddress.
Step 3: Issue the card with POST /card/v1/cards
After agreements are signed, send POST /card/v1/cards with a partner reference, customerId, ledger.type BVNK_EPC_WALLET, mainWalletId, assetCode USDC, and an optional daily limit plus cardArt identifier.
Docs example shape: daily limit value 5000, optional cardArt such as cool-art-42 after BVNK approves artwork (typical review 2–3 weeks offline). Omitting cardArt applies program default art.
Immediate response status is often CREATED, then PENDING while the provider provisions. Final ACTIVE or CANCELLED arrives on webhook bvnk:card:card:updated. BVNK does not expose cancellation reasons; the customer may reapply after CANCELLED.
| Status | Meaning |
|---|---|
| CREATED | Issued but not yet activated |
| PENDING | Provisioning with the card provider |
| ACTIVE | Spendable |
| FROZEN | Temporarily frozen; partner can unfreeze |
| BLOCKED | Blocked (for example fraud); partner cannot unfreeze |
| CANCELLED | Permanent; cannot reactivate |
| EXPIRED | Past expiration date |
Step 4: Display PAN/CVV with the BVNK SDK
Sensitive card data never enters your servers. Embed BVNK's front-end SDK so PAN, CVC, expiry, and cardholder name render inside a PCI-scoped iframe from BVNK's card vault.
List cards with GET /card/v1/cards (filter by card ID or customer reference). Docs note only one card or application is returned per customer (most recent if multiple applications exist).
Step 5: Webhooks, spend, and sandbox simulation
Subscribe at least to bvnk:card:card:updated and bvnk:card:transaction:status-change. Acknowledge with HTTP 200 immediately and process asynchronously. Validate signatures.
In sandbox, POST /card/v1/simulation/transactions to authorise a test amount (optional declineReason). Then PATCH the transactionId with action SETTLE, REVERSE, or REFUND to exercise the lifecycle without real network traffic.
Production go-live requires a separate live Portal configuration. Sandbox settings do not copy automatically. Base URL moves from https://api.sandbox.bvnk.com/ to https://api.bvnk.com/.
How Cards fits next to payouts and off-ramps
Cards are spend against a USDC wallet. They complement, not replace, treasury rails such as Circle stablecoin payouts, Bridge virtual accounts for USDC, USDC ACH/wire off-ramps, and USDC payroll.
Operators choosing BVNK often want one embedded stack for wallets plus local spend. BVNK's payments page describes the broader Send/Receive surface around that wallet.
Operator checklist before go-live
- Sandbox: eligibility → agreement → issue → SDK display → freeze/unfreeze → simulation auth/settle.
- Confirm Cards jurisdictions with account manager for every launch market.
- Submit card art early if branding matters (2–3 week approval cited in docs).
- Record UI video showing separate CARD_AGREEMENT step after KYC.
- Mirror webhook endpoints and Hawk keys in production; retest signature validation.
- Document the one-card-per-customer rule in your product UX.
Need the primary reference? Start with BVNK's Create cards guide, then wire eligibility and agreement sessions before the first production POST.
Card art and branding
Optional cardArt lets you brand virtual cards. Design artwork offline, submit it to BVNK Solutions or your account manager, wait for scheme-compliant approval (docs cite a typical 2–3 week review), then store the returned identifier and pass it on each POST /card/v1/cards.
BVNK does not currently list art identifiers in Portal or API responses. Keep your own mapping of identifier to creative. If you omit cardArt, the program default applies.
Manage freeze, unfreeze, and cancel
After issuance, use the Manage Cards APIs documented at Manage Cards to freeze, unfreeze, or cancel. Freeze is reversible. Blocked status is not partner-unfreezable. Cancelled is permanent.
All control actions are audit-logged. Wire your support tooling so agents can freeze a compromised card without waiting on BVNK ops.
Security and compliance notes for operators
BVNK authorises spend against the linked USDC wallet balance and credits the wallet for refunds or chargebacks. Keep wallet funding and spend monitoring in the same reconciliation stream as your other USDC rails.
Because Cards is jurisdiction-gated and beta, treat market expansion as a product launch: reconfirm eligibility, entity mapping, and UI approval for every new countryCode you send into CARD_AGREEMENT sessions.
FAQ
What is BVNK Cards?
BVNK Cards is a beta Embedded Custom API product that issues virtual spending cards linked to a customer's USDC wallet (ledger type BVNK_EPC_WALLET) so users can spend stablecoin online or via digital wallets.
Which API creates a BVNK USDC card?
After eligibility and a signed CARD_AGREEMENT session, partners call POST /card/v1/cards with customerId, BVNK_EPC_WALLET mainWalletId, and assetCode USDC.
Do partners need PCI certification?
BVNK requires partners to be PCI-compliant but not PCI-certified. PAN/CVV display happens inside BVNK's SDK iframe so partners do not receive or store cardholder data.
Can Customers v2 users get cards?
No. Public docs state Cards can only be issued to customers created with Customers v1 and Agreements v1. The v2 onboarding flow is not yet supported for card issuance.
How many cards can one customer hold?
Each customer may have only one active card or pending application. GET /card/v1/cards returns a single record per customer.
How do operators test spend in sandbox?
Use POST /card/v1/simulation/transactions to create authorisations (optional declineReason), then PATCH with SETTLE, REVERSE, or REFUND. Subscribe to card and transaction webhooks while testing.
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional.
){kind=link}