How Card Issuing APIs Work: From Request to Transaction

For the user, issuing a card looks simple: tap a button, and a new card appears in the app, ready to make a payment or be added to a wallet. Behind that simple action sits a specific sequence of technical steps involving APIs, processors, issuers, card networks, authorization, clearing, and settlement.

The CardsPro team breaks down the complete flow: from the API request and card creation to authorization, webhooks, clearing, and settlement.

A card issuing API lets a company create and manage payment cards programmatically, without applying for a banking license or building processing infrastructure. The company calls an endpoint; the platform behind it returns a working card.

Several parties typically sit behind an issued card, even when the client interacts with only one API.
The issuing platform (CardsPro, Stripe Issuing, Marqeta, Lithic) exposes the API, handles card creation, and manages controls, limits, and webhooks. The issuing bank is the regulated financial institution that issues the card and provides access to the BIN used by the card program. The processor sits between the bank and the card networks, authorizing and routing transactions in real time. The card network — Visa or Mastercard — moves the transaction between the merchant's bank and the issuer and enforces network rules.

A platform like CardsPro gives the client access to this infrastructure through a single integration, without requiring separate technical integrations with each participant.

Card creation starts with a single API call that specifies the card type, spending limits, and the entity the card belongs to — a user, an employee, a project, or an ad account.
The request goes through validation before anything is created. The platform validates the request, account permissions, required cardholder data, and applicable program rules. If the request is valid, the system generates a card record: a BIN-prefixed card number (PAN), an expiration date, a CVV, and a set of controls tied to that specific card.

The BIN (Bank Identification Number) is the first six to eight digits of the card number. It identifies the issuing bank and determines which country and card network the card is associated with. CardsPro provides access to 20+ BINs across the US, UK, Hong Kong, Singapore, and Estonia, so a client can match card geography to a specific payment scenario — advertising, subscriptions, or cross-border spending.

Cards can be issued as virtual or physical. A virtual card is ready to use immediately after creation. A physical card requires production and delivery before it can be used. Through the CardsPro API, virtual card issuance costs up to $2.5 per card, and plastic card issuance costs up to $135 per card.

At creation, the client also defines card controls: spending limits, merchant category restrictions, freeze and unfreeze permissions, and expiration rules. These controls are stored against the card record and checked on every subsequent transaction.
The API response returns the card ID and card status. Sensitive credentials such as the PAN and CVV can be made available through PCI-compliant mechanisms, depending on the platform and integration. The client uses the card ID for all future operations: balance top-ups, limit changes, freezing, or closing the card.

Once a card exists, a transaction follows a fixed path through several parties, each of which has to approve or forward the request before it reaches the issuer.

The cardholder initiates a payment at a merchant — online or in person. The merchant sends the transaction to its acquirer, the bank or payment processor that handles the merchant's payment accounts. The acquirer routes the transaction to the relevant card network (Visa or Mastercard) based on the BIN. The network identifies the issuing bank from the BIN and forwards the transaction to the issuer processor, which evaluates it against the card's rules and balance in real time.

This entire round trip — from a card swipe or checkout click to an approve or decline response — typically completes within one to two seconds.

Authorization is the real-time decision to approve or decline a transaction. It happens before any money moves.

The authorization flow evaluates several conditions before returning an approval or decline:

• Balance check — does the card's available balance or credit line cover the transaction amount?
• Card status — is the card active, or has it been frozen, blocked, or expired?
• Spending limits — does the transaction fall within the per-transaction, daily, or monthly limit set on the card?
• MCC restrictions — is the merchant category code on the card's allowed or blocked list? A card configured only for SaaS subscriptions, for example, can be set to decline transactions at unrelated merchant types.
• Fraud and risk rules — does the transaction pattern match known fraud signals, such as an unusual location, a sudden spike in transaction velocity, or a mismatch between the card's typical use and the current merchant?

If all checks pass, the processor sends an approval code back through the network and acquirer to the merchant, and the transaction amount is placed on hold against the card's balance. If any check fails, the processor returns a decline, and no funds move.

Instead of continuously polling the issuing platform, the client's system can receive events as they occur through webhooks.

A webhook is an HTTP callback the issuing platform sends to a URL the client configures in advance. Each event carries a payload describing what happened: an authorization approval, a decline (with a reason code), a reversal, or a status change such as a card being frozen or a balance updated.

A client's product reflects real-world card activity without manual checks: updating a user's transaction history, triggering a low-balance alert, or reacting to a suspicious decline as soon as the corresponding event is received.

Authorization is not the final charge. It's a hold, and the amount that eventually settles can differ from the amount initially authorized.

Authorization happens at the moment of purchase, as described above. It confirms the card can cover the transaction and places a hold on the funds.

Clearing happens afterward, usually within one to three days, when the merchant's acquirer submits the finalized transaction details to the network for processing. This is the stage where the exact final amount is confirmed — which matters for transactions like hotel stays, car rentals, or restaurant bills with tips, where the authorized amount and the final charge are rarely identical.

Settlement is the actual movement of funds: the network debits the issuer and credits the acquirer, who in turn pays the merchant. Settlement finalizes what was only provisionally held during authorization.

Because these three stages happen at different times, a client's system needs to track a transaction through its full lifecycle rather than treating the initial authorization as the final record.

A media buying platform issues a virtual card for a new Meta Ads account:

1. Create card — the platform calls the API with a $500 monthly limit and an MCC restriction for advertising services. The API creates the card and returns its ID and status, while the card credentials are made available through the platform's secure mechanism.
2. Make payment — the card is used to pay a Meta Ads invoice.
3. Authorization — the issuer processor checks the balance, card status, limit, and MCC, then approves the transaction and places a hold on $500.
4. Webhook — the platform's system receives an authorization event in real time and updates the account's spending dashboard.
5. Clearing — Meta's acquirer submits the final transaction amount for processing, matching the authorized amount in this case.
6. Settlement — funds move from the issuing bank to Meta's acquirer, and the hold is converted into a finalized transaction on the card's statement.

CardsPro provides this entire flow — card creation, BIN infrastructure, authorization, webhooks, and settlement — through a single API. Clients don't need separate agreements with an issuing bank, a processor, and a network; CardsPro handles that layer while the client keeps its own product interface and business logic.

Integration can go live in 14 days for platforms that already have their infrastructure in place, with documented API methods covering card issuance, limits, balances, and transaction monitoring.

Teams building card issuing into a fintech product, media buying tool, or B2B platform can review the CardsPro API documentation to see the specific endpoints for card creation, controls, and webhook events.