Skip to content
Last updated

How card payments work

Background, not instructions. You can integrate successfully without reading it, but the vocabulary here turns up in responses and support conversations.

The parties

Cardholder

Your application

Gateway

Processor

Card network

Issuing bank

Cardholder

Your application

Gateway

Processor

Card network

Issuing bank

PartyDoes
CardholderPresents a card
MerchantSells the thing. Your customer, or you
GatewayTakes an API request and turns it into a processor message. This is us
ProcessorConnects to the card networks. TSYS, for cards
Card networkVisa, Mastercard, Amex, Discover. Routes to the issuer
Issuing bankHolds the cardholder's account and decides approve or decline
Acquiring bankHolds the merchant's account and receives the funds

You talk to the gateway and nothing else. No direct connection to a processor, a network, or a bank is needed.

Authorization, then settlement

A card payment is two events, usually hours apart.

Authorization asks the issuer to reserve funds. It is synchronous — the answer comes back in the API response, and it is where an approval or a decline happens.

Settlement actually moves the money. Transactions gather in a batch, the batch closes on a schedule, and the acquirer funds the merchant a day or two later.

That gap is why is_settled is false on a transaction you just approved, and why a void and a refund are different operations. See Transaction lifecycle.

What the gateway does for you

One integrationCard and ACH through one API, rather than one per processor
TokenizationA payment token instead of storing card numbers
Normalized responsesThe same transaction object whichever processor handled it
SettlementBatching and close, with reporting to reconcile against

Next steps