Alex runs a small design agency. On his way to work he taps his HSBC debit card at Arabica for a cappuccino. Later, one of his teammates pays for their monthly Figma subscription using a virtual corporate card that Alex created.

Both transactions feel instant and effortless. The card touches the terminal, the terminal beeps, and life moves on. But under the surface, each swipe or tap triggers a rapid sequence of checks and handoffs across multiple systems that need to be correct every single time.

Before we explore the flow, it helps to understand who is actually involved in a typical transaction.

The players behind every card payment

Card payments only look simple because several independent parties communicate and coordinate within a fraction of seconds. Here are the key participants.

• The cardholder: This is the person making the payment. In our example: Alex at Arabica, or his teammate using their virtual card to pay for Figma.
• The merchant: The business accepting the payment, like Arabica, Figma, or Uber.
• The payment terminal and merchant processor: The hardware and payment provider used by the merchant. Arabica’s terminal connects to its processor, which might be someone like Stripe.
• The card network: The scheme that routes transactions; Visa and Mastercard for example.
• The issuer: The bank or institution that issued the card to the customer. For Alex’s debit card, this could be HSBC. For his team’s virtual corporate cards, it may be Stitch.
• The ledger

Behind the issuer’s front door are systems that maintain balances, check spending rules, detect fraud, and make fast approve or decline decisions. These systems determine whether a transaction is safe, allowed, and within limits.

Think of these players as a relay team. The moment Alex taps his card, the baton starts moving.

Here is what happens next.

1. The transaction request begins

When Alex taps his card on the Arabica terminal, the terminal retrieves the card’s tokenized data using near field communication.

If he had swiped, the terminal would read the magnetic stripe. If he had inserted the chip, it would perform an EMV exchange.

The terminal packages this information with the purchase amount, merchant ID, and timestamp, then sends it to Arabica’s processor. If Arabica uses Stripe, for instance, Stripe receives the request and formats it into an authorization message.

Example: If Alex bought a four dollar cappuccino, the processor will include that amount, the Arabica store number, and the token associated with his HSBC card.

2. The network decides where the request should go

Once the processor forwards the request, the card network takes over. If Alex is using a Visa card, Visa determines which issuer should receive the authorization message.

This routing step must be flawless. If the network misroutes a request, the issuer cannot respond. Networks also run early checks such as validating that the merchant is allowed to accept this type of card. For example, if someone tries to use a corporate fuel card at an online gaming site, the network may block it before it travels further.

Example: When Alex’s teammate pays for Figma using a virtual Mastercard, the request is routed to the institution that issued that specific virtual card, not to the bank behind Alex’s personal debit card.

3. The issuer verifies identity, balance, and risk

The issuer receives the request and decides whether to approve or decline. This step involves several systems working together quickly.

• Identity verification: The issuer checks the token and maps it to the actual card or account. For tap payments at Arabica, the token hides sensitive data. The issuer confirms it is valid and issued under HSBC.
• Balance or credit limit checks: The issuer checks whether Alex has enough funds for the four dollar purchase. For the Figma payment, the issuer checks the spending limit assigned to the specific virtual card used by his teammate.
• Risk and rule checks: Modern issuers run transactions through decisioning engines that evaluate patterns, merchant category, location, and historical behavior. If Alex suddenly made ten identical Arabica purchases in one minute, the issuer might step in.

Example: If Alex’s teammate tries to use the virtual card to pay for personal clothing, the issuer’s rules may decline it because the card is restricted to software and business tools.

All these checks happen while Alex is picking up his coffee.

4. The approval travels back to the merchant

Once the issuer decides, it sends the response back through the same path. Visa or Mastercard receive it, the processor receives it next, and finally the terminal at Arabica displays the result.

Approved. Declined.

Example: If the Figma subscription is due on the first of the month and the virtual card has enough limit remaining, the issuer approves the recurring charge. Figma’s billing system receives the approval just like the Arabica terminal does.

5. The money settles

Authorization is only the promise. Settlement is the actual movement of funds.

At the end of the day, Arabica submits its approved transactions to its acquirer, which then works with the networks to pull funds from the issuer. It may take one to two business days for Arabica to receive the money in its bank account.

Example: Alex sees four dollars deducted from his HSBC balance immediately, but HSBC will only send those funds to Arabica’s acquiring bank later in the settlement cycle.

Why all of this matters

For any financial institution, understanding this flow highlights a simple truth. Every step depends on fast communication between systems that were not always designed to work together. Many teams still rely on separate providers for issuing, ledgering, fraud checks, card controls, and transaction routing. Each handoff creates delay, complexity, and room for error.

Fragmentation slows approvals, complicates compliance, makes debugging painful, and increases the risk of inconsistent customer experiences. A small mismatch between the ledger and the issuer. A routing rule that sits in a different system. Any of these can turn a perfectly valid transaction into a decline or force teams into manual investigation.

That is why more institutions globally are shifting toward unified platforms, like Stitch, that bring issuing, ledgering, and controls into one environment. When everything sits on a connected foundation, approvals become faster, rules become easier to manage, and new card products reach customers sooner. The entire experience feels cleaner and more predictable for both builders and cardholders.

‍