What a modern payment processor actually contains

Ask a founder to draw their payment processor on a whiteboard and you will usually see three boxes: checkout, "the processor", and a bank account. Ask an engineer who has shipped one to production and the whiteboard fills up fast — acquiring core, risk engine, ledger, settlement pipeline, dispute workflow, merchant lifecycle, reporting, and a surprising amount of glue code that reconciles all of it. Teams consistently underestimate how many subsystems sit behind a "simple" payment processor, and that underestimation is the single biggest source of blown timelines in fintech delivery.

Authorisation is the visible ten percent

Authorisation — the request-response exchange that returns approve or decline — is what most product teams picture when they say "the processor". It is also the part that off-the-shelf SDKs handle reasonably well, which is precisely why it feels deceptively simple. The other ninety percent is invisible until something breaks: routing logic that decides which acquirer or scheme path a transaction takes, fee calculation that has to reconcile against invoices months later, settlement windows that move real money across bank accounts, merchant lifecycle management that onboards and offboards thousands of businesses, dispute handling that touches legal and finance, and continuous reconciliation that catches the pennies nobody else notices until they become thousands of pounds.

Each of those invisible systems has its own failure modes, its own regulatory exposure, and its own team of specialists in a mature organisation. Building them as an afterthought — bolted onto an authorisation flow that was designed first — is how processors end up with brittle architecture that nobody wants to touch.

Decomposing into bounded contexts

At Pay Engineers we typically decompose processors into five clear bounded contexts: acquiring core, merchant domain, risk, finance, and partner connectivity. Each context owns its own data model, its own failure boundaries, and its own release cadence. That separation is what keeps scheme mandates and certification cycles manageable — when Visa or Mastercard issue a new mandate, you want to know exactly which bounded context absorbs the change, rather than tracing it through a monolith.

Acquiring core

This is where ISO 8583 or ISO 20022 messages are built, signed, routed and parsed. It talks to schemes, processors and issuers, and it needs to be the most defensively engineered part of the stack: strict timeouts, typed retries, and message logging that a QSA can audit without exposing cardholder data.

Merchant domain

Onboarding, KYB, risk tiers, pricing configuration, and the state machine that governs whether a merchant can even attempt a transaction. This context is where most operational tickets originate, so its admin tooling deserves as much design attention as the merchant-facing API.

Risk, finance and partner connectivity

Risk owns fraud scoring and case management. Finance owns the ledger, fee attribution and settlement. Partner connectivity owns the adapters to acquirers, schemes and banking partners — the layer that changes most often as you multi-home providers or expand corridors.

The data flows that decide your architecture

Before any UI mockup, three inputs should drive your architecture: corridor volumes (which countries and currencies you actually move money in), settlement currencies (how many currencies you must hold, convert and report on), and the partner stack you intend to certify against. A processor built for a single-currency, single-corridor SME market looks nothing like one built for a multi-currency marketplace with weekly payout obligations across a dozen countries.

These three inputs also determine your ledger design, your reconciliation cadence, and how much of your engineering budget goes into partner adapters versus product features. Get them wrong at the design stage and you will be rebuilding core data models eighteen months after launch — usually during a period of rapid growth, which is the worst possible time.

A practical build sequence

• Map corridors, currencies and expected volumes before writing a single line of acquiring code.
• Stand up the ledger and reconciliation pipeline in parallel with authorisation, not after it.
• Treat merchant lifecycle and KYB as a first-class product, not an admin afterthought.
• Design dispute and chargeback handling before your first live merchant, not after your first chargeback.
• Instrument every bounded context with business-level observability from day one.
• Certify against schemes and PCI DSS as a continuous programme, not a pre-launch scramble.

Where teams get it wrong

The most common failure pattern is optimising the authorisation path aggressively while treating settlement, reconciliation and dispute handling as "phase two". By the time phase two arrives, the business already depends on manual spreadsheets to close the books every month, and nobody wants to touch the code that "just works" — until it stops working at scale.

A processor is not a payment API with a database attached. It is a small, regulated bank-adjacent business wearing engineering clothes.

Staffing and governance around the contexts

Each bounded context eventually needs a distinct governance rhythm, not just distinct code. The acquiring core needs an owner who tracks scheme mandate calendars and certification renewal dates months in advance, because certification labs book up and mandates rarely move to accommodate a late start. The finance context needs an owner who can sit in the same room as external auditors and answer ledger questions without translation through engineering.

Underinvesting in this governance layer is how processors end up with technically sound bounded contexts that nobody can actually operate confidently — the code is well factored, but the organisational muscle to run scheme relationships, safeguarding reviews and reconciliation escalations simply does not exist yet. Budget for these operating roles at the same time you budget for the engineering build, not six months after go-live when the first mandate deadline is already looming.

Key takeaways

• Authorisation is the smallest, most visible part of a processor — and the easiest to get right.
• Bounded contexts (acquiring, merchant, risk, finance, connectivity) keep scheme changes and certifications manageable.
• Corridor volumes, settlement currencies and partner stack should drive architecture before UI decisions.
• Ledger, reconciliation and dispute handling deserve day-one investment, not phase-two treatment.
• Treat the processor as a regulated financial business first, and a software product second.