---
title: "How to issue stablecoin-funded cards through an API: a developer's guide"
seoTitle: "How to issue stablecoin-funded cards through an API"
description: "Build vs. buy for stablecoin card issuing, the objects a card issuing API must expose, a step-by-step integration flow, and where KYC and KYB sit in it."
date: "2026-09-18"
updated: "2026-09-21"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How to issue a stablecoin-funded card through an API"
  steps:
    - name: "Get sandbox credentials from a card issuing provider"
      text: "Sign up with an issuing provider that supports stablecoin funding, get sandbox API keys, and confirm which card networks, card currencies, and cardholder countries its sponsor bank allows."
    - name: "Pass KYB for your business"
      text: "The provider and its sponsor bank verify your company, its registration, and its beneficial owners before approving the card program. Program approval defines limits, allowed countries, and card types."
    - name: "Create a cardholder and pass KYC"
      text: "Create a cardholder with name, date of birth, address, and a government ID number. Wait for an approved status before issuing a card; rejected or pending cardholders cannot receive one."
    - name: "Link a stablecoin funding source"
      text: "Attach the stablecoin balance that pays for purchases: a program wallet the provider holds, or your own wallet with an on-chain spending allowance. Record the network and token, such as USDC on Base or Solana."
    - name: "Issue a virtual card with spend controls"
      text: "Create a virtual card for the cardholder with spending limits, merchant category rules, and an expiry. Return the card details to the cardholder through the provider's PCI-compliant display component, never through your own servers."
    - name: "Handle the authorization webhook"
      text: "Implement a synchronous endpoint that receives each authorization request, verifies its signature, checks the available stablecoin balance in your ledger, places a hold, and returns approve or decline within the provider's deadline."
    - name: "Process clearing, reversals, and refunds"
      text: "Listen for clearing, reversal, and refund events, adjust holds to the final amounts, and post entries to your ledger. Key every event on its idempotency id so retries do not double-post."
    - name: "Go live with low limits"
      text: "Switch to production keys, issue a card to an internal cardholder with a small limit, and run a first live transaction end to end before raising limits."
faq:
  - q: "How do I issue a stablecoin-funded card through an API?"
    a: "Integrate with a card issuing provider that supports stablecoin funding: pass KYB for your business, create a cardholder and pass KYC, link a USDC or USDT funding source, issue a virtual card with spend controls, and implement the authorization webhook that approves or declines each purchase against the stablecoin balance. The provider and its sponsor bank handle the card network connection."
  - q: "What does a stablecoin card issuing API need to support?"
    a: "At minimum: cardholder creation with KYC status, card issuance with limits and merchant controls, a funding source tied to a stablecoin balance, a synchronous authorization webhook, and events for clearing, reversals, refunds, and disputes. Sandbox simulation of authorizations and declines is also needed to test the integration before production."
  - q: "Should I build card issuing in-house or use an API provider?"
    a: "Use an API provider unless card issuing is the core business and you have years and a large budget. Building in-house means signing a BIN sponsor bank, meeting card network requirements, reaching PCI DSS compliance for card data, building or licensing an authorization engine, and running an anti-money-laundering program. An API provider has already done that, leaving you the product, ledger, and user experience."
  - q: "How does KYC/KYB fit into an API-based card issuing flow?"
    a: "KYB runs once on your business before the program is approved, and KYC runs on every cardholder before a card can be issued. Sanctions screening repeats on cardholders and, for stablecoin funding, on wallet addresses, and transaction monitoring runs on every authorization. None of these can be skipped, because the sponsor bank carries the regulatory responsibility for every card on its BIN."
  - q: "What is the typical integration flow for issuing a stablecoin-backed card?"
    a: "Get sandbox keys, pass KYB, create and verify a cardholder, link a stablecoin funding source, issue a virtual card with limits, implement the authorization webhook, handle clearing and reversal events in your ledger, and go live with a small internal card first. Most of the engineering time goes into the authorization handler and the ledger, not the card creation calls."
---

*Reading time: about 8 minutes.*

**Summary:** API-based stablecoin card issuing means creating cardholders, cards, and spending decisions through a card issuing provider's REST API, while funding each purchase from a stablecoin balance such as USDC. The provider handles the network connection and the sponsor bank. Your code decides who gets a card, how it is funded, and which transactions to approve.

This guide is for developers and technical founders deciding whether to build or integrate. It covers what each path requires, the objects any issuing API has to expose, and an integration flow you can follow as a checklist.

One note on scope. The endpoints and payloads below are a generic shape shared by most issuing APIs, not one provider's reference. Names change between providers. The objects and their order do not. For the concepts behind the card itself, read [what stablecoin card issuing is](/resources/more/what-is-stablecoin-card-issuing).

## Should you build card issuing in-house or use an API?

Building means becoming the issuer's technology and compliance partner yourself. Buying means integrating one that already is.

| Requirement | Build in-house | Integrate an issuing API |
|---|---|---|
| Sponsor bank | Negotiate and sign a BIN sponsorship agreement | Provided; you are approved under the provider's program |
| Card network | Meet Visa or Mastercard program and certification requirements | Provided |
| Card data security | PCI DSS compliance for storing and processing card numbers | Provider's vault; you never touch the full card number |
| Authorization engine | Build or license an issuer processor | Provided; you answer a webhook |
| Compliance program | Written AML program, KYC, monitoring, filings, under the sponsor's oversight | Shared: the provider runs most checks, you own your program's policies |
| Disputes and chargebacks | Build dispute operations | Provider workflow plus API events |
| Time to first card | Typically a year or more | Sandbox in a day; production after program approval |

Build only if card issuing is the product and you have the capital and patience for bank and network negotiations. Everyone else integrates, and spends the saved time on the ledger and UX, which is where programs actually differ.

## What does a stablecoin card issuing API need to expose?

A usable issuing API has seven objects. If a provider is missing one, you will end up building it.

| Object | What it does | Fields to look for |
|---|---|---|
| Cardholder | The verified person or business the card belongs to | KYC status, country, rejection reasons |
| Funding source | The stablecoin balance that pays for purchases | Token, network, wallet address, custody model |
| Card | A virtual or physical card | Status, limits, merchant category rules, expiry |
| Authorization request | A real-time question from the network: approve this? | Amount, currency, merchant, MCC, deadline |
| Transaction | The lifecycle after approval | Clearing amount, reversals, refunds, FX rate |
| Dispute | A cardholder challenge to a transaction | Reason code, deadline, evidence |
| Webhook endpoint | Where events are delivered | Signing secret, retry policy, event types |

Two questions separate stablecoin-native providers from traditional ones bolted onto a wallet:

- **When does conversion happen?** Just in time at authorization, so balances stay in USDC, or ahead of time into a fiat card balance.
- **Who holds the stablecoins?** A custodial program wallet, or your own wallet with an on-chain spending allowance the provider can draw from.

## Integration flow, step by step

### 1. Get sandbox credentials

Sign up, get sandbox keys, and before writing code ask for three lists: supported card currencies, cardholder countries the sponsor bank accepts, and stablecoins and networks the funding source supports. These decide your product more than any endpoint.

### 2. Pass KYB for your business

The provider and its sponsor bank verify your company before approving the program: registration, beneficial owners, business model, and expected volumes. The approval sets your limits and card types. Plan for this to take longer than the code.

### 3. Create a cardholder and pass KYC

```bash
POST /v1/cardholders
Content-Type: application/json
Idempotency-Key: 1c9f...

{
  "type": "individual",
  "first_name": "Ana",
  "last_name": "Souza",
  "date_of_birth": "1994-03-12",
  "country": "BR",
  "tax_id": "000.000.000-00",
  "address": { "line1": "...", "city": "Recife", "postal_code": "..." }
}
```

The response comes back with a status such as `pending`. Wait for `approved` on a webhook before issuing a card. Treat `rejected` as final and show a clear message.

### 4. Link a stablecoin funding source

```bash
POST /v1/funding-sources
Content-Type: application/json

{
  "type": "stablecoin_wallet",
  "token": "USDC",
  "network": "base",
  "address": "0x..."
}
```

In a custodial model you deposit USDC to an address the provider gives you. In an allowance model you approve a spending limit on-chain from your own wallet, and the provider pulls only what settles.

### 5. Issue a virtual card

```bash
POST /v1/cards
Content-Type: application/json

{
  "cardholder_id": "ch_...",
  "funding_source_id": "fs_...",
  "type": "virtual",
  "currency": "USD",
  "limits": [{ "amount": 200000, "interval": "monthly" }],
  "blocked_mccs": ["7995"]
}
```

Amounts are in minor units, so `200000` is USD 2,000.00. MCC 7995 is gambling. Show the card number to the cardholder through the provider's embedded, PCI-compliant display component. Never proxy the full card number through your own backend, or you inherit PCI scope.

### 6. Handle the authorization webhook

This is the heart of the integration. On each purchase the provider calls your endpoint and waits a few seconds for an answer. If you do not answer in time, the provider applies a default decision you configure.

```ts
app.post('/webhooks/card-authorization', async (req, res) => {
  const event = verifySignature(req) // provider-specific HMAC check; reject if invalid
  const { authorization_id, card_id, amount, currency, merchant } = event

  if (await ledger.seen(authorization_id))
    return res.json(await ledger.decisionFor(authorization_id))

  const card = await cards.get(card_id)
  const available = await ledger.availableUsdc(card.accountId)
  const needed = await quotes.toUsdcMinorUnits(amount, currency)

  if (needed > available)
    return res.json({ decision: 'decline', reason: 'insufficient_funds' })

  await ledger.hold(card.accountId, authorization_id, needed)
  return res.json({ decision: 'approve' })
})
```

Three rules make this handler reliable:

- **Read from your ledger, not the blockchain.** An on-chain balance query is too slow for an authorization deadline. Keep a ledger that updates on deposit and settlement events.
- **Be idempotent.** Providers retry. Key on the authorization id and return the same decision.
- **Decide your timeout default deliberately.** Decline on timeout is safer. Approve on timeout is friendlier and needs a buffer.

### 7. Process clearing, reversals, and refunds

The authorized amount is not the final amount. Listen for clearing events and adjust the hold, release holds on reversals, and credit refunds. Post each event to your ledger once, keyed on its id.

### 8. Settle the funding side

At settlement the provider draws the stablecoins that cover the day's cleared purchases and pays the network, in fiat or in USDC where the network supports it. Reconcile the draw against your ledger daily.

If your treasury starts in a bank account, you need a way into stablecoins first. BlindPay [virtual USD accounts](/virtual-accounts) accept ACH and wire deposits and convert them to USDC or USDT in a linked wallet, and the [stablecoin API integration guide](/resources/more/how-to-integrate-a-stablecoin-api) walks through those calls with real endpoints.

### 9. Go live with low limits

Switch to production keys, issue one card to an internal cardholder with a USD 50 limit, and buy something real. Check every event landed in the ledger. Then raise limits.

## Where does KYC and KYB sit in the flow?

Compliance is not a step. It is four checkpoints.

| Checkpoint | Check | Why it cannot be skipped |
|---|---|---|
| Program approval | KYB on your company and its beneficial owners | The sponsor bank must know who runs the program |
| Cardholder creation | KYC on each cardholder, sanctions screening | A card is an account; account opening requires identification |
| Funding | Wallet address screening | Stablecoin funds from a sanctioned address taint the program |
| Every authorization | Transaction monitoring, velocity and merchant rules | The sponsor bank's AML program covers every transaction on its BIN |

The sponsor bank carries the regulatory responsibility for every card on its BIN, and US sanctions compliance is strict liability. A provider that lets you skip a checkpoint is putting its bank relationship, and your program, at risk. The [compliance guide](/resources/more/stablecoin-card-issuing-compliance) covers what each check involves and how it differs by country.

## Testing checklist before production

- Approve, decline for insufficient funds, and decline on a blocked MCC
- Webhook timeout and the configured default decision
- Duplicate webhook delivery
- Partial clearing below the authorized amount, and clearing above it (tips)
- Full reversal and a refund days later
- Cardholder KYC rejection
- Funding source running low mid-month

## What to read next

Finish the series with the [compliance guide for stablecoin card issuing](/resources/more/stablecoin-card-issuing-compliance). If your recipients need money in a bank account rather than on a card, the [stablecoin API integration guide](/resources/more/how-to-integrate-a-stablecoin-api) covers local-currency payouts over Pix, SPEI, ACH, SEPA, and SWIFT (POBO/COBO).

*This article is for general information only and is not legal, tax, or financial advice.*