> ## Content Index
> Fetch the complete content index at: https://stablecoininsider.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Issue a BVNK USDC Card for Stablecoin Spend (2026)
- URL: https://stablecoininsider.org/how-to-issue-a-bvnk-usdc-card/
- Published: 2026-09-20T12:21:52.000Z
- Updated: 2026-09-20T12:21:52.000Z
- Description: Issue BVNK Cards against a customer USDC wallet: eligibility, CARD_AGREEMENT, POST /card/v1/cards, SDK display, and spend webhooks for Embedded Custom partners.
- Author: Alexandra
- Tags: Fintech, Stablecoins

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.

📌

Stablecoin Insider's framing: BVNK Cards turn an idle USDC wallet into local spend (online or Apple Pay / Google Wallet) while the partner owns the front end. Cards are beta, jurisdiction-gated, and limited to Customers v1 onboarding.

This guide follows BVNK's public docs as of September 20, 2026: [Issue cards](https://docs.bvnk.com/bvnk/use-cases/cards/), [Prepare for integration](https://docs.bvnk.com/bvnk/use-cases/cards/prepare-for-cards-integration/), and [Create cards](https://docs.bvnk.com/bvnk/use-cases/cards/implement-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.

⚠️

Named downside: Cards is in beta and may change. Confirm target markets with your BVNK account manager before building. Only Customers v1 / Agreements v1 customers are supported, and each customer may hold only one active card or pending application.

## 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](https://www.bvnk.com/embedded-wallets) 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](https://stablecoininsider.org/jesse-hemson-struthers-bvnk/) and the [Marqeta partnership for stablecoin-backed cards](https://stablecoininsider.org/marqeta-taps-bvnk-for-stablecoin-backed-cards/). This post is the operator how-to for the Cards API itself.

[Open BVNK Cards docs](https://docs.bvnk.com/bvnk/use-cases/cards/)

## 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](https://docs.bvnk.com/bvnk/use-cases/cards/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.

💡

Stablecoin Insider's take: treat CARD\_AGREEMENT as a hard gate. Issuing before a signed session is a common sandbox failure mode and will block production launch reviews.

## 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](https://stablecoininsider.org/how-to-send-a-circle-stablecoin-payout/), [Bridge virtual accounts for USDC](https://stablecoininsider.org/how-to-open-a-bridge-virtual-account-for-usdc/), [USDC ACH/wire off-ramps](https://stablecoininsider.org/how-to-off-ramp-usdc-to-ach-or-wire/), and [USDC payroll](https://stablecoininsider.org/how-to-run-payroll-in-usdc/).

Operators choosing BVNK often want one embedded stack for wallets plus local spend. BVNK's [payments page](https://www.bvnk.com/payments) describes the broader Send/Receive surface around that wallet.

[Jesse Hemson-Struthers, BVNKStablecoin Insider Leaders profile on BVNK's founder and the firm's stablecoin infrastructure thesis.![](https://stablecoininsider.org/favicon.ico)Stablecoin Insider](https://stablecoininsider.org/jesse-hemson-struthers-bvnk/)

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

[Read Create cards docs ](https://docs.bvnk.com/bvnk/use-cases/cards/implement-cards/) 

## 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](https://docs.bvnk.com/bvnk/use-cases/cards/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.