How Crypto Card APIs Work
A crypto card API works in two loops. The funding loop converts an on-chain stablecoin deposit into a spendable fiat balance held against your account. The spending loop runs every time a card is used: the merchant requests an authorization, the issuer checks your balance and the card's limits in real time, approves or declines within roughly a second, and later settles the funds. Your API calls create cards and set the rules; the issuer enforces them on every transaction.
Loop one: funding the balance
Nothing can be issued against an empty balance, so the first loop is treasury. You send stablecoins — USDT is the common case — to the deposit address on your account. Once the transfer has the required on-chain confirmations, the balance becomes spendable.
That balance is shared. It is not locked to a single card, which is what makes programmatic issuance practical: you top up once, then allocate spend across every card your software creates. Funding on-chain typically clears in minutes rather than the days a cross-border wire can take.
Loop two, step one: issuing the card
Your server makes an authenticated REST call to create a card, passing the parameters that matter to your business — a label, a spending limit, and the network to issue on. Roughly 60 seconds later the card exists and the API returns its identifiers.
Requests are authenticated with a per-account API key generated in dashboard Settings. That key belongs on your server only. The full endpoint reference, with parameters and live examples, sits inside your dashboard so it always matches the version your account is on.
Loop two, step three: settlement
An approval is a promise, not a payment. The authorization reserves the amount and reduces your available balance immediately, but the merchant is not paid yet.
Settlement follows, usually within a couple of days, when the merchant's batch clears and money actually moves. This gap explains behaviour that otherwise looks like a bug: a pending charge that disappears when a merchant never captures it, a hotel pre-authorization for more than the final bill, or a refund that takes days to reappear.
Closing the loop with webhooks
Polling an API to discover that a card was used is slow and wasteful. Webhooks invert it: the platform calls your server the moment something happens, so your product can react while the event is still relevant.
- A card was authorized — update the user's spend in your own UI immediately.
- A transaction was declined — surface the actual reason instead of a generic error.
- A card was frozen or closed — keep your database in sync with reality.
- A deposit confirmed — release the budget that was waiting on funds.
Where your code fits in
The issuer enforces the rules, but your software writes them. That division is the whole point of an issuing API: you express business policy as card state, and the network enforces it on every transaction without your servers being in the payment path.
- Set a per-card limit so a single vendor can never exceed its budget.
- Freeze a card instantly when your risk logic sees something wrong.
- Close a card when a customer churns or a campaign ends.
- Issue a replacement card without touching the underlying balance.
Frequently asked questions
Is the crypto converted at the moment of purchase?
What happens if the balance runs out mid-month?
How fast is issuance in practice?
Do I ever handle the full card number?
Can a declined authorization be retried?
See the flow with a real card
Fund a balance with USDT, issue a card through the API, and watch the authorization arrive on your webhook endpoint.
Explore Kripicard
Discover our complete suite of crypto virtual card solutions and services