A REST API for virtual cards

Bot operators and automation engineers need a payment primitive that's as ephemeral and disposable as their compute. Manual card issuance through a dashboard doesn't scale; bank-issued virtual cards require KYC and rate-limit issuance to 1-2 per day. CryptoCardy exposes the full card lifecycle as a REST API, with no per-issuance approval, no identity verification, and a $1.50-per-card unit cost.

What the API does

• POST /api/v1/cards — issue a new card. Returns number, expiry, CVV, and the card-id.
• POST /api/v1/cards/:id/freeze / /unfreeze — toggle the card's authorisation state.
• DELETE /api/v1/cards/:id — close the card and refund unused balance to the account.
• POST /api/v1/cards/:id/topup — move funds from the account balance to the card balance.
• GET /api/v1/cards/:id/transactions — list authorisations and settlements.
• POST /api/v1/topups — create a deposit address, get back the QR + crypto amount.
• GET /api/v1/topups/:id — poll the deposit status (or use webhooks).

Full reference at /api-docs.

Authentication and rate limits

Bearer-token auth. Generate one or more API tokens from the dashboard's settings panel. Each token has its own scope (read-only, card-mgmt, full) and can be rotated or revoked independently.

Rate limit: 60 requests / minute on the read endpoints, 10 / minute on the write endpoints. If you need higher limits, contact support via the dashboard ticket system (requires at least one active card on the account).

Typical bot-fleet pattern

For a scraping fleet that needs disposable payment surfaces:

1. Top up the account balance once per week with enough crypto to cover the expected card issuance volume.
2. Each worker requests a card via the API at the moment it needs one — typically just before placing an order or signing up to a service.
3. The worker uses the card for the single intended transaction.
4. Once the transaction is recorded, the worker calls DELETE to close the card. Unused balance refunds to the account instantly.
5. The next worker repeats with a fresh card.

This pattern is the lowest-overhead way to give each worker an isolated payment surface. The $1.50 per-card cost is a fraction of the cost of any other approach.

Webhooks

Subscribe to lifecycle events through the webhooks panel:

• card.issued — fires when a card is created.
• card.authorised — every successful authorisation (transaction approved).
• card.declined — every declined authorisation with reason code.
• card.frozen / card.unfrozen / card.deleted
• topup.confirmed — when a crypto deposit credits the account.
• topup.cancelled — when a deposit expires unused.

Webhooks deliver HMAC-signed JSON to your endpoint. Replay protection via signed timestamps. Delivery retries 6 times with exponential backoff before giving up.

Recommended BIN per workload

• API spend on cloud / AI services — BIN 493847 (Visa Corporate).
• Scraping / signups — BIN 491653 (Visa Classic). Lower limits, but you don't need more for one-off card patterns.
• Programmatic ad buying — BIN 471938 (Visa Business).