Build or Buy for Each Payment Layer: The Test Is Who Carries It When Things Break

Build or Buy for Each Payment Layer: The Test Is Who Carries It When Things Break

A payment stack runs to about seven layers, and each one has to answer build or buy. Most teams decide with a cost table: how many engineering months to build versus what the subscription costs, then pick the cheaper number.

That arithmetic leaves out the single most important line item: who carries it when things break. Cost deferred is still cost, and in architecture decisions it usually comes due during an incident.

1. Three decision questions

Question one: who carries the liability. Licensing, clearing and dispute adjudication can only be carried by a licensed institution. Building those in-house is not a compliance option, at any price.

Question two: is this layer your differentiator. If your payment experience will not differ from a competitor's because of it, the layer is infrastructure and buying beats building. Conversely, the account model, the pricing model and the reconciliation basis are what let you run certain businesses at all; outsourcing them means handing over the difference.

Question three: does this layer change faster than you ship. Acquirer and scheme rule changes, and shifting regional regulatory positions, move faster than most teams' release cadence. A layer you cannot keep up with should be bought.

If any one question points to "buy", the decision is largely made. Only three "build" answers justify the investment.

2. A layer-by-layer verdict

Acquiring: must buy. Acquiring status is a licence and clearing-network admission; there is no build option. What you can build is the choice of which acquirers to use and how to combine them.

Orchestration: depends on acquirer count and routing complexity. Unnecessary with one acquirer; worthwhile with two or more and routing rules that change. Decide who holds the tokens before you go live, or orchestration is just a forwarder.

Authentication (3DS): buy the service, keep the policy. A 3DS Server is a standardized service and rarely worth building, but the policy - which transactions request frictionless, which must be challenged, which exemption family applies where - must stay in-house, because that is exactly where approval rate and liability are traded off.

Risk: buy the engine, keep the rules and thresholds. Building the engine and the signal library is extremely expensive and needs continuous data feeding. Business rules, allowlists, thresholds and the manual review queue must be yours, because they are business judgement, not technical capability.

Chargebacks: buy the representment service, keep the evidence. Submissions and reason-code templates can be outsourced; evidence - delivery confirmation, service records, communication trails, login and action logs - can only be kept in your production systems. A vendor can organise the evidence; it cannot invent it.

Treasury: must buy accounts and clearing, but build the ledger. Collection accounts, FX and clearing rails are licensed activities. Your own refundable-balance ledger, pending-settlement detail and split ledger must be built in-house, because they are business facts: third-party APIs provide statements, not your business basis.

Installments and BNPL: buy. Credit risk sits with a licensed party; building it means becoming a bank.

Reconciliation: build. This is the rare layer that should be built, because reconciliation is fundamentally about aligning your own business basis with external statements, and nobody knows your basis better than you. Tools can supply statement downloads and diffing; attributing the difference always lands on the business side.

State machine and idempotency: always build. This is not a product layer but the foundation running through all of them. No outsourced option will define for you what counts as success, what counts as failure, and how to decide on a retry. Without it, even excellent external services produce duplicate charges or corrupted state.

3. Three common mistakes in building

Mistake one: building the "obviously simple" adapter layer. A middle layer forwarding transactions to two acquirers really is simple on day one. But each acquirer needs an adapter, and authentication schemes, error taxonomies, refund endpoints and settlement file formats all differ; every acquirer API version forces a matching change. Adapter maintenance is a recurring cost, not a one-off build cost.

Mistake two: building a risk model without label data. A risk model needs the label "was this ultimately fraud", and that label only comes from chargeback outcomes and manual review decisions. A new business has too few labels for the first several months, and a self-built model usually underperforms a vendor's general model plus a handful of hard rules.

Mistake three: building a ledger on someone else's basis. Some teams use the settlement statement a provider supplies as their ledger. It looks efficient, and the price arrives when the business changes - adding splits, partial refunds or multi-currency settlement - and the data structure simply has nowhere to put the new facts, forcing a rebuild.

4. Four things to keep in-house no matter how much you outsource

Whatever is outsourced, these four must live in your systems and be treated as first-class:

State machine and idempotency keys. Define one state transition model and one de-duplication basis. External responses are inputs to a state change, never the state change itself.

Refundable balance ledger. After every transaction, refund and partial refund, you must maintain how much of that transaction remains refundable. Relying only on a provider query for the refundable amount breaks across channels and across time.

Raw record retention. The normalized format a provider returns is easy to read, but investigation requires reaching the original request and original response. Store the raw data and make it traceable by order number.

Decision log. Why risk blocked it, why authentication challenged it, why routing chose that channel - all three decisions must sit on one traceable timeline. Otherwise, when a dispute arrives, you can neither explain it nor change it.

5. Recommendations by stage

Just launched, single market: buy acquiring, the risk engine and authentication; build the state machine, idempotency and reconciliation. Fixed cost is lowest and no structural debt is created.

Going cross-border, two or more acquirers: add orchestration and settle token custody at the same time; move risk from "vendor defaults" to "own rules". The classic error at this stage is buying orchestration first and thinking about credential ownership later.

Platform business: you must build the ledger and split ledger; the outside world supplies accounts and clearing only. The complexity here is not technical - it is the compliance and reconciliation consequences of handling money that is not yours.

For where each layer sits see the seven layers of a payment stack; for orchestration specifics see whether to add a payment orchestration layer; for state machine and idempotency design see order numbers and idempotency design; for building reconciliation see automating payment reconciliation. More payment options are listed under the payment category.

Source: 16IDC original. Licensing and clearing boundaries follow local regulation and the terms of the licensed institutions involved.