Payment Processing Architecture: Gateway, Processor, Acquirer, Network and Issuer Explained

What are the six layers of a payment processing architecture?

Six: the merchant experience the customer interacts with, payment data capture, authorization routing, risk and authentication, clearing and settlement, and merchant funding and reconciliation. Each layer has a distinct job, a distinct failure mode and a distinct set of participants. Reading a payment stack this way is more useful than the usual five-box diagram, because one company can sit in several layers and one layer can involve several companies.

The layers are ordered by when they act, not by importance. Layers 1 and 2 happen at the moment of sale. Layers 3 and 4 happen in the seconds around approval and in practice interleave. Layers 5 and 6 happen after the customer has gone, on a schedule measured in banking days rather than milliseconds.

This model is descriptive, not a standard. It exists because merchants are sold a bundle and then have to debug one layer inside it: a checkout that never posts, a decline that came from somewhere, a deposit that does not match a batch. Naming the layer narrows the question to something a support conversation can actually answer.

Which entity acts in which layer?

The gateway acts in layers 2, 3 and 4: it captures card data, formats and routes the authorization request, and usually hosts the merchant's fraud rules and 3-D Secure integration. The processor acts in 3 and 5. The acquirer acts in 3, 5 and 6, and carries the merchant's liability. The card network acts in 3, 4 and 5. The issuer acts in 3, 4, 5 and 6.

Read down instead of across and the picture sharpens. Layer 1 belongs almost entirely to the merchant and the software the merchant bought — POS, e-commerce platform, invoicing tool. Layer 2 belongs to whoever's code touches raw card data: the terminal, the gateway's hosted fields, a token service. Layer 3 is the only layer where all five entities are present at once. Layer 4 is shared between the merchant's own rules, the network's directory and the issuer's decision. Layers 5 and 6 belong to the processor, acquirer, network and issuer, and the merchant sees them only as reports and deposits.

Two definitions cause most of the confusion. The acquirer is the financial institution that holds the merchant account, is a member of the card networks, and is on the hook if the merchant cannot fund its own refunds and chargebacks. The processor is the operator that moves the messages and files on the acquirer's behalf. A processor without an acquiring licence works under a sponsoring acquirer, which is why a merchant agreement often names a bank the merchant has never spoken to.

What happens, in order, when a card is charged?

The customer acts in layer 1. The card data is captured and immediately replaced by a token in layer 2. Layer 4 may authenticate the cardholder before anything is authorized. Layer 3 carries an authorization request from gateway to processor to acquirer to network to issuer, and returns an approval or a decline. Layer 5 clears the captured transaction and sets settlement positions. Layer 6 funds the merchant.

For an e-commerce sale the order matters. Authentication runs before authorization, so the result it produces travels inside the authorization request. Reverse the two and the request arrives with no evidence the cardholder was ever checked, which is the difference between a merchant-liable and an issuer-liable chargeback months later.

Approval is a hold, not a transfer. The issuer sets funds aside against the cardholder's credit line or account balance and returns a response code; nothing has moved. Capture — immediate for most retail, later for ship-when-ready e-commerce — is what tells the acquirer to collect. Card-present debit in Canada takes a different path through the same layer: an Interac Debit transaction is authorized against a deposit account over Interac's own network rather than over a credit card network.

Clearing then submits the captured records as a batch. The network applies interchange and calculates what each issuer owes each acquirer; settlement moves those net positions between institutions. Only after that does the acquirer pay the merchant, which is why money arrives shaped by a funding schedule rather than as a copy of each individual sale.

Where does tokenization sit, and why does it change the data-capture layer?

Tokenization sits in layer 2, at the moment of capture. The card number is exchanged for a reference that is worthless to anyone who steals it, and everything downstream — order records, subscription billing, the merchant's own database — carries the reference instead. That changes the layer because the question of who touched the card number now has a much shorter answer, and PCI DSS is written about exactly that question.

There are two kinds of token and they are not interchangeable. A gateway token is a reference held in one provider's vault: it works with that provider, and moving away means a vault migration. A network token is issued through the card networks' token services and is tied to the underlying card, which is why it can be kept current when the card is reissued.

The practical effect on scope: if the card number is captured inside a hosted field or an encrypting terminal and never reaches the merchant's servers, those servers sit outside the cardholder data environment and a lighter self-assessment questionnaire applies. Outside is not the same as exempt. Staff handling, device security and every place a card number can still be written on paper or read aloud over a phone remain the merchant's responsibility.

Where does 3-D Secure sit in the risk and authentication layer?

EMV 3-D Secure is layer 4, and it runs before layer 3. Three components do the work: a 3DS Server on the merchant or gateway side, a Directory Server operated by the card network, and an Access Control Server operated by the issuer. The merchant's request reaches the network's directory, the directory routes it to the issuer, and the issuer decides whether it already knows enough to trust this cardholder.

Most authentications finish without the customer noticing. In a frictionless flow the issuer decides on the data it was sent — device, history, transaction context — and returns a result. In a challenge flow the issuer asks the cardholder to confirm, typically in a banking app. The merchant does not choose which happens; the issuer does, on the risk it sees.

Authentication answers a different question than authorization. Authentication asks whether this is the cardholder; authorization asks whether the issuer will pay. They are put to the same issuer moments apart, and an authenticated transaction can still be declined for funds, limits or the issuer's own fraud model. What authentication changes is who carries the loss if the transaction is later disputed as fraud: under the networks' rules an authenticated transaction generally moves that liability from the merchant to the issuer, with the specifics varying by network and region.

How do clearing, settlement and merchant funding differ?

Clearing is the exchange of transaction records between acquirer and issuer through the network, and it is where interchange is applied. Settlement is the movement of net funds between those institutions to satisfy the positions clearing calculated. Merchant funding is the separate, later step where the acquirer pays the merchant. Three distinct events with three distinct sets of participants, and only the third one appears in the merchant's bank account.

Funding also comes in two shapes, and the difference is reconciliation rather than cost. Take a day's batch of $50,000 carrying $1,200 in fees — both figures are illustrative. Gross funding deposits $50,000 and bills the $1,200 separately, usually monthly. Net funding deposits $48,800. The gross deposit ties to the batch total with no arithmetic, which is why finance teams tend to ask for it; the net deposit ties to nothing until someone rebuilds the fee side to prove it.

In Canada the final leg is a domestic bank transfer, not a card network movement. The acquirer's payment to the merchant travels over the payment systems Payments Canada operates, which is why merchant funding follows Canadian banking days and holidays rather than the card networks' own calendar.

Which layer is a decline or a failed payment coming from?

Work down the layers in order and the answer usually appears in one step. If the customer never reached a payment attempt, it is layer 1. If the card form failed or no token was created, layer 2. If an authentication challenge failed or was abandoned, layer 4. If a response code came back, layer 3 delivered it and the issuer wrote it. If the sale exists but the money does not, the problem is in layers 5 and 6.

The distinction that saves the most time is between a decline and an error. A decline is a successful round trip with an unwelcome answer: the message reached the issuer and came back. An error means the message never completed the trip, which points at layers 2 and 3 — a malformed request, a credential problem, a timeout — and gets fixed by different people than a decline does.

Response codes are written by the issuer, not by the gateway or the processor, which is why a flat decline cannot be argued away by the merchant's provider. What a provider can do is keep the request well-formed, retry appropriately, and make sure authentication results and the correct card-present or card-not-present indicators are actually present in the message, since a missing indicator can turn an approvable transaction into a declined one.

Why does one company often occupy several of these layers?

Because the layers are functions, not companies. A provider that markets itself as a payment gateway may also be the processor and, under a sponsoring bank, hold the acquiring relationship. A payment facilitator goes further and places the merchant under its own acquiring account instead of opening a separate one for each merchant. None of that is a problem in itself. Not knowing which of them is true of your provider is.

The bundle is usually good for the merchant: fewer contracts, one support path, one reconciliation report and one place to ask why a transaction behaved oddly. The cost is that layer boundaries become invisible exactly when you need to see them — during a migration, in an argument about who caused an outage, or when deciding whether stored card data can move to a new provider.

Two questions recover most of the map. Which layers does this provider operate itself, and which does it resell? And who is the acquirer named in my agreement? The first tells you where a fix has to come from and how many parties a hard problem will involve. The second tells you who actually holds your merchant account and, if you leave, whose vault your tokens are sitting in.