How to give every team or project its own programmable virtual card

One shared company card for every subscription, ad account and trip is a support nightmare: when it is blocked, everything stops; when a charge looks wrong, nobody knows who made it. Splitting spend across dedicated cards fixes that, but only if creating and controlling cards is automatic.

With the KemyCard API, each card is an API object. Your product creates one per employee, campaign or supplier, loads exactly the budget it needs, and freezes it the moment the job is done.

Common setups

• Ad budgets: one card per client or per campaign, so each ad account has its own budget and its own statement.
• Software subscriptions: one card per tool, frozen when the subscription is cancelled, so a forgotten renewal is declined.
• Travel and field teams: a card per trip, loaded with the travel budget and frozen when the person is back.

How it works

1. Create the cardholder as a customer and verify their identity.
2. Issue the card with POST /v1/cards and its starting budget in amount.
3. Top up on approval. When a manager approves more budget in your tool, call POST /v1/cards/{code}/topup.
4. Freeze when done. POST /v1/cards/{code}/freeze blocks new payments; /unfreeze brings the card back.
5. Feed accounting. Each card.transaction webhook carries the payment, so you can attach receipts and categories in real time.

# Freeze a campaign card when the campaign ends
curl -X POST https://api.kemycard.com/v1/cards/CARD_CODE/freeze \
  -H "Authorization: Bearer sk_test_..."

# Pull its history for the client report
curl https://api.kemycard.com/v1/cards/CARD_CODE/transactions \
  -H "Authorization: Bearer sk_test_..."

Fees by plan

The free Découverte plan includes a monthly number of virtual cards, enough to try the model with one team. Paid plans have no monthly limit on cards.