The Seven Layers of a Payment Stack: Acquiring, Orchestration, 3DS, Risk, Chargebacks, Treasury and BNPL

The Seven Layers of a Payment Stack: Acquiring, Orchestration, 3DS, Risk, Chargebacks, Treasury and BNPL

Most teams think payments means calling one API to collect money. A year later they discover seven coupled systems have grown around them: an acquirer, orchestration routing, 3DS authentication, risk decisions, chargeback handling, cross-currency treasury, and installment or credit terms. These layers are not vendor marketing constructs. Each one can fail on its own, be replaced on its own, and move revenue on its own.

Separating them pays off directly. Which layer a given incident belongs to, whether a new vendor fills a layer or fights an existing one, and what order to add layers in are all questions that stay permanently mis-answered without a layered mental model.

1. Why "just take payments" grows into a system

The starting point is usually simple: a merchant account that can initiate card transactions, in other words an acquirer. That first step is also what makes everything after it look smaller than it is.

The first source of complexity is failure rate. The same card can fail at one acquirer and succeed at another; authorization behaviour differs by region, card type and ticket size. The obvious response is to add a second acquirer and route by rule - which is where orchestration begins.

The second is compliance pressure. Strong customer authentication in Europe, regional rules on authentication, and scheme conditions for liability shift turned authentication from an option into a layer that must be designed explicitly.

The third is fraud and chargebacks. A successful authorization is not money in hand: clearing still happens afterwards, and cardholder disputes have their own window. Risk and chargeback handling therefore migrate from "the risk team's problem" into the payment stack.

The fourth is where the money goes. In cross-border business, acquiring proceeds often cannot land directly in the operating account and need conversion, pooling and allocation; platform businesses also have to split funds across sellers.

The fifth is conversion. Installments and buy-now-pay-later are not marketing plugins - they introduce a new party that carries credit risk and a new reconciliation basis.

Those five forces stack up into seven layers.

2. What each layer actually solves

2.1 Acquiring: whether the money can come in

The acquirer initiates authorization to the issuer on your behalf and carries clearing and scheme-level compliance obligations. Its capability boundary comes down to three things: whether it has local acquiring status, which schemes and local payment methods it covers, and what authorization approval rate it achieves.

The real price of this layer is not the percentage on a rate card but "per-transaction revenue as determined by rate and approval rate together". Two channels quoting the same rate can differ by more than ten percent in net revenue per transaction when approval rates differ by a few points.

The test: acquiring answers "can we accept", not "is the experience good". Assigning a conversion problem to this layer usually fixes the wrong thing.

2.2 Orchestration: which channel this attempt leaves through

Orchestration holds no funds and makes no risk decisions. It manages two things: routing and state. It distributes transactions across acquiring channels by amount, card type, geography and time of day; retries a timed-out attempt on another channel; and normalizes wildly different channel responses into a single order state.

Its real value is not saving on rates but turning "switch acquirer" from a project into a configuration change. That value has a precondition: payment credentials must be vaulted in the orchestration layer or an independent vault. If tokens stay with the original acquirer, orchestration is only a router, and switching channels still means every existing customer re-enters card details.

The test: with one acquirer you do not need orchestration; it becomes real when you have two or more and genuinely need rule-based dynamic routing.

2.3 Authentication: 3-D Secure and liability shift

3DS is a chain: merchant or acquirer to the 3DS Server, to the scheme Directory Server, to the issuer ACS, and back to the merchant. The merchant usually only touches the 3DS Server directly; the rest is decided by the acquiring bank, the scheme and the issuer.

The core trade-off in this layer is approval rate for liability. When authentication genuinely completes and the transaction meets the conditions, fraud chargeback liability shifts to the issuer; the cost is that some users abandon during a challenge. The frictionless share is decided jointly by the issuer's risk model and local regulatory exemptions - merchants can influence it but cannot decide it.

The test: 3DS is a compliance and liability tool, not a conversion tool. Treating it as "a way to raise approval rates" is a directional error.

2.4 Risk: whether this should be allowed

The risk layer decides before authorization: allow, block, or demand additional verification. It relies on device fingerprints, behavioural traces, account history, and consistency between address and card range.

One distinction matters: transaction-level risk answers "does this transaction look fraudulent", while identity-level risk answers "who is this person". The first suits guest checkout; the second suits businesses with accounts, because account-level signals accumulate across orders and the cold-start problem is fundamentally different.

The test: risk and 3DS interfere with each other. A transaction blocked by risk never reaches 3DS, and a user who fails a 3DS challenge may be recorded as anomalous by risk. Both layers must share one decision log, or thresholds can never be tuned to a stable point.

2.5 Chargebacks: the second battle after a successful payment

A chargeback is a dispute the cardholder raises with the issuer. It has its own deadlines, evidence requirements and cost structure. This layer has to obtain evidence inside the deadline, organize it by reason code, submit representment, track the outcome, and book the loss correctly when it fails.

The test: chargeback cost is not only the refunded amount but also fixed dispute fees and manual labour; when the chargeback ratio runs high, acquirers may add collateral or terminate the relationship outright. Outcomes are decided by friendly-fraud share and evidence retention, not by clever argumentation.

2.6 Treasury: where the money goes once it arrives

This layer handles currency, pooling, conversion, payouts and splits. In cross-border business it often affects cash flow more than acquiring does; in platform business it decides whose account the money lands in and who issues the invoice.

The test: authorization and settlement are two different moments, and the exposure between them is managed here. Holds and rolling reserves also live here, so book balance and withdrawable balance must be modelled separately - otherwise reconciliation never closes and nobody can say how much cash actually exists.

2.7 Installments and BNPL: who carries the credit risk

BNPL introduces a new party that carries risk. For a merchant the decision test is not "will this lift average order value" but three questions: who absorbs consumer default, how installment plans are adjusted on refunds, and whether the merchant discount is covered by incremental gross margin.

The test: some models carry no credit risk and only occupy the cardholder's existing limit, while others fund the purchase and absorb default. The onboarding requirements, discount rates and settlement timing differ so much that the two cannot be compared on one rate sheet.

3. Not every business needs seven layers

Three dimensions decide whether to add a layer: whether transaction volume supports its fixed cost; whether current failure or chargeback losses already exceed that cost; and whether a structural problem exists - multiple entities, multiple currencies, multiple sellers - that point fixes cannot solve.

A small single-market business needs acquiring plus basic risk, and nothing more. Rolling out all seven layers at once will let fixed cost and operational complexity break the team long before the benefits arrive.

4. Three reference stacks

Light stack: one acquirer, its built-in risk, and its hosted checkout page. Suited to single-market, single-currency businesses with modest volume. It onboards fast and keeps card data scope minimal; the downside is that switching acquirers means rebuilding, and existing customers must re-authorize. See independent store payment architecture for the overall shape.

Growth stack: two acquirers, an orchestration layer, independent risk and a 3DS service. Suited to teams with cross-border demand that already care about approval rates and chargeback ratios. The precondition is token custody in the orchestration layer, otherwise orchestration is decoration. For concrete optimisation paths see payment success rate optimisation.

Platform stack: the growth stack plus treasury (splits, multi-currency, reserve modelling) and installments. Suited to marketplaces, platform SaaS and businesses that collect on behalf of customers. Its complexity comes from "the money is not yours" rather than from technology; see aggregated payments and split settlement for the split model.

5. Four mistakes that repeat when layering

Mistake one: buying orchestration before deciding who holds credentials. If tokens stay with the old acquirer, orchestration can only route, and every existing customer must re-enter card details on a switch - renewal rates drop measurably during the transition.

Mistake two: using risk blocks to patch gaps in 3DS. The two roles differ; substituting one for the other produces challenges that never happen for the transactions that need them and blocks on transactions that should pass, and both metrics get worse. See 3-D Secure 2 authentication for the division of labour and the interface between them.

Mistake three: treating chargeback handling as a support workflow. Chargebacks have deadlines and evidence formats; miss the deadline and the right to represent is gone. It must be a system with a state machine and countdowns, not a ticket queue. See chargeback reason codes and evidence.

Mistake four: comparing headline rates instead of total cost. Total cost should be written as revenue determined by rate and approval rate, minus chargeback losses, reserve carrying cost and per-layer subscriptions. Comparing rate percentages alone almost guarantees the wrong choice. See payment gateway rate comparison for how each layer is priced.

For the card data compliance boundary across these layers see PCI DSS compliance in practice; for the execution order when replacing a single channel see payment gateway migration. More payment options are listed under the payment category.

Source: 16IDC original. Layer capability boundaries, scheme rules and compliance requirements follow the relevant provider documentation and local regulation.