Module 1

Designing a Payment Architecture

The decision framework for choosing your payment rails, processor stack, and architectural model

---

The Architecture Audit: Where You Stand Now

Before you design, you need to understand your current state. Most organisations do not have a deliberate payment architecture. They have a history of decisions, each made in response to a specific problem at a specific time. A payment processor was chosen for a specific region. A gateway was added because the first one did not support a new payment method. Multiple reconciliation tools exist because each processor requires different connectors. You end up with a stack that is expensive, fragile, and coupled to vendors that no longer match your business.

The payment infrastructure audit is the diagnostic foundation. It answers: what are we paying today, what are we getting for it, where is it fragile, and what would we choose if we were starting today? This is not an academic exercise. Understanding your current state forces you to confront technical and commercial debt. A typical audit reveals 20 to 40 percent of transaction fees going to unnecessary hops, or to processors handling transaction types they are poorly suited for.

Architecture is not chosen at the outset. It is discovered through an honest assessment of what you have, what it costs you in money and engineering time, and what your business actually needs to grow.

The Payment Infrastructure Audit Checklist

• Transaction flows: Map every transaction type your business processes. This includes credit card online, debit online, wallets (Apple Pay, Google Pay), international cards, local payment methods (Sofortueberweisung, WeChat Pay, UPI), bank transfers, buy-now-pay-later, recurring billing. Most organisations process 8 to 15 different transaction types.
• Processor routing: Document which transaction types go to which processors. Do your credit card transactions go to three different gateways? Do you have a separate processor for wallets? For international transactions? The fragmentation matters.
• Cost breakdown: Itemise every charge. This includes per-transaction fees (basis points), flat fees, gateway fees, PCI compliance fees, reconciliation tools, monitoring tools, analytics platforms, and service level agreements. Sum these up as a percentage of transaction volume and as absolute annual cost.
• Geographic coverage: Document which payment methods you support in which regions. Do you have local acquiring for all major regions, or are you converting everything to card transactions? Are you acquiring in local currencies or converting at unfavourable rates?
• Reconciliation overhead: How long does it take to reconcile a day of transactions? Do you have automated reconciliation or manual processes? How much engineering time per month is spent on reconciliation problems?
• Integration burden: Document the number of distinct APIs you integrate with, the lines of code per integration, the testing burden, and the operational toil. Each processor requires different error handling, retry logic, and settlement accounting.
• Incident response: When a processor goes down or experiences latency, what happens to your payment flow? Is there fallback routing? How long until you detect the issue and how long to recover?
• Vendor lock-in risk: How dependent are you on any single processor? What would migration cost? How long would it take? Which vendors have you considered replacing?

Most organisations find this audit uncomfortable. It reveals inefficiency. It also reveals opportunity. An ecommerce company might discover they are paying 3.5 percent effective rate to a gateway that does not support their core transaction type, and could cut that to 1.8 percent by routing through a processor that specialises in that type. A marketplace might discover they are running five reconciliation processes when one unified processor would require one. A SaaS company might discover they are integrating with a recurring billing processor that lacks support for dunning, proration, and the complex renewal scenarios they are handling manually in a spreadsheet.

---

The Build vs. Buy vs. Orchestrate Decision Framework

Every organisation must make a strategic choice about what payments infrastructure to build versus what to buy or orchestrate. This is not a technical choice. It is a business choice. The answer depends on your company size, engineering capacity, transaction volume, geographic scope, and competitive advantage. There is no universal answer. The framework helps you decide given your constraints.

Buy: Managed Payment Orchestration Platforms

Buying means using a managed payments platform like Stripe, Adyen, Worldpay, or newer entrants like Pine or Spreedly. You delegate processor selection, global coverage, reconciliation, compliance, and operational support to the vendor. You integrate once. You accept that the vendor makes routing decisions on your behalf.

Buy is the right choice if you are small to mid-market (under $50 million in annual transaction volume), you have limited payments engineering capacity, and your transaction types are standard. The all-in cost is high (2.5 to 3.5 percent of transaction value typically), but the operational cost is low. You do not maintain integrations, reconciliation processes, or compliance monitoring.

The risk is that your business may outgrow the platform's flexibility. As you scale and your transaction mix becomes more diverse, you start bumping against the limits of what the platform can do. You cannot route specific transaction types to specific processors. You cannot optimise interchange for B2B transactions. You cannot negotiate unique terms with niche processors. At that point, the vendor is no longer a partner, it is a constraint.

Orchestrate: Multi-Processor Routing with Orchestration Middleware

Orchestration means maintaining relationships with multiple processors and using middleware to route transactions intelligently. This could be purpose-built platforms like Spreedly, SwitchPay, or BILL Payments, or a custom orchestration layer that you build. You maintain the vendor relationships, but you insulate your core payments infrastructure from processor-specific implementation details.

Orchestration is the right choice if you have $50 million to $500 million in transaction volume, moderate payments engineering capacity, and a transaction mix that requires specialised processors. You integrate with the orchestration layer once. The layer handles routing, reconciliation, and processor abstraction. You gain control over which transactions route to which processors, and you can swap processors without rewriting your core payments code.

The operational cost is moderate (engineering time to maintain integrations with the orchestration layer and to build custom routing logic). The fees are lower than pure buy (1.8 to 2.8 percent typically), because you are managing your own processor relationships and negotiating volume-based terms. The risk is complexity. More processors means more reconciliation overhead, more error handling, more testing. The orchestration layer requires maintenance.

Build: Custom Payments Infrastructure

Building means engineering your own integration with multiple processors, managing your own reconciliation, and maintaining your own orchestration logic. You own everything. You control everything. This is also the highest risk and highest cost option if you do not have sustained payments expertise.

Build is only justified if you have annual transaction volume over $500 million, significant payments engineering capacity (10+ engineers dedicated to payments infrastructure), and transaction types that cannot be handled by existing platforms. Square, PayPal, Block, and Stripe all built their own infrastructure because their volume and specialised use cases justified the cost.

The operational cost is very high initially (months to years of engineering time to build a production-grade payments stack), but decreases as a percentage of transaction volume as you scale. The fees are lowest (1.0 to 1.5 percent possible), because you are negotiating directly with processors at enterprise scale and eliminating middlemen. The risk is maintenance burden and vendor concentration risk. You are now the vendor. If your systems go down, your business stops.

---

Reference Architectures for Four Business Types

Payment architecture is not one-size-fits-all. Different business models have different requirements. Understanding the reference architecture for your business model helps you avoid building for the wrong problem or missing critical infrastructure needs.

Direct-to-Consumer Ecommerce

DTC ecommerce businesses process high transaction volume, low transaction size, and a transaction mix dominated by credit and debit cards with secondary support for wallets. The critical success factors are conversion rate (minimising false declines), cost per transaction, and geographic expansion.

Reference architecture: single primary processor (like Stripe or Adyen) for domestic transactions, with a secondary processor for international high-velocity regions (Asia, Europe). Wallet support (Apple Pay, Google Pay) is critical because wallets convert 20 to 30 percent better than card-only flows. A reconciliation layer that provides real-time visibility into transaction status, settlement, and exceptions. Fraud detection focused on false decline minimisation because a $0.50 false decline on a $25 transaction destroys margin. Chargeback management because DTC merchants experience 0.5 to 1.5 percent chargeback rates due to high volume and lower friction purchase experience.

Cost structure: 2.2 to 2.9 percent effective rate typical for high-volume DTC, with leverage to negotiate lower rates at $10 million monthly volume. The main hidden cost is reconciliation tooling ($500 to $5,000 monthly depending on transaction volume and processor diversity).

Multi-Sided Marketplace

Marketplace businesses process transactions between buyers and sellers, with the platform capturing a commission. The critical requirements are split payments (routing portions of a transaction to multiple parties), separate settlement for sellers, tax calculation by jurisdiction, and fraud detection that works across both buyer and seller behaviour. A seller might be processing $100,000 monthly in transactions, but you need to settle them to a bank account, minus your commission, minus chargebacks, minus taxes.

Reference architecture: orchestration layer connecting multiple processors, because you need split payment capability that not all generic processors support. Stripe Connect, PayPal Commerce Platform, or custom-built orchestration. Separate ledgers for buyer funds and seller funds, with settlement processes that handle splits, reductions for chargebacks, and tax withholding. Fraud detection focused on seller identity verification (KYC) because seller fraud is often more damaging than buyer fraud. A dedicated provider like Sardine or Sift for marketplace-specific fraud and abuse patterns.

Cost structure: 2.5 to 3.8 percent effective rate typical, higher than ecommerce because of orchestration complexity and compliance overhead. Commission structure matters more than processor choice.

SaaS with Recurring Billing

SaaS businesses process recurring subscriptions, with complex use cases around dunning (retrying failed payments), proration (handling mid-cycle plan changes), usage-based billing, and seat scaling. The critical success factors are minimising involuntary churn from failed payments, supporting complex billing scenarios without engineering overhead, and maintaining compliance across jurisdictions (calculating sales tax, VAT, GST).

Reference architecture: billing and payment orchestration platform purpose-built for SaaS like Stripe Billing, Zuora, Chargify, or custom-built orchestration. These platforms handle the complexity of retrying failed payments across multiple payment methods, dunning letters, and downgrade scenarios. Direct integration with accounting systems to automate revenue recognition. Geographic compliance layer to handle tax calculation by jurisdiction. Do not underestimate this: tax complexity grows exponentially with international customer base.

Cost structure: 2.0 to 3.2 percent effective rate, but the real value is in reducing involuntary churn. A SaaS business that reduces failed payment churn from 5 percent to 2 percent through proper dunning recovers vastly more revenue than it spends on platform fees. The hidden cost is compliance. If you operate internationally, you need to understand VAT, GST, and sales tax in each jurisdiction.

Embedded Finance (Payments as a Feature)

Embedded finance businesses integrate payments into their platform to provide payment capability to their end customers or users. Examples include invoicing platforms that need to accept payments from customers, HR platforms that process payroll, accounting software that needs to move money, or commerce platforms that need to provide payments to sellers. The critical requirements are simplified integration (your users should not care that payments are embedded), high reliability (your business depends on it working), and often, lower cost structure because you have volume leverage.

Reference architecture: payment processor with strong embedded finance APIs, or orchestration layer if you serve multiple processor needs. Stripe Connect is built for this use case. A single integration that handles multiple payment types and routes them to the right processor. Reconciliation should be fully automated with web hooks triggering real-time settlement notifications to your platform. Support for local payment methods is critical because embedded finance platforms typically serve global users. Compliance is critical: if your users process BNPL or ACH transfers, you inherit regulatory responsibilities.

Cost structure: 1.5 to 2.8 percent effective rate, with volume leverage because you are aggregating many end-user transactions through a single platform account. The main cost beyond processor fees is compliance and fraud monitoring.

---

The Key Architectural Decisions

Single PSP vs. Multi-PSP

A single payment service provider (PSP) is simpler operationally but creates vendor lock-in and limits your ability to optimise cost and capability per transaction type. You have one integration, one reconciliation process, and one vendor relationship. When the vendor innovates (launches a new payment method), you get it. When the vendor degrades (downtime, latency, poor customer service), you have no fallback.

Multi-PSP splits your transaction flow across multiple vendors. This reduces vendor lock-in, but increases operational complexity. You have to reconcile across multiple systems, handle different error codes, manage different settlement schedules, and build orchestration logic to route transactions intelligently. The cost-benefit analysis depends on your transaction volume and margin structure. If you process $10 million annually in transactions at 2.5 percent effective rate, that is $250,000 per year in payment fees. A 0.3 percent reduction through better routing pays for significant operational overhead. If you process $100 million annually, a 0.2 percent reduction justifies the complexity.

A practical approach: start with a single PSP if you are under $10 million annual transaction volume. Migrate to multi-PSP once you have the volume and the specific use cases that justify it.

Gateway-Led vs. Acquirer-Led

A gateway-led model means your primary relationship is with a payment gateway (Stripe, Adyen, Square), which handles processor selection, acquiring, and merchant services. You integrate with the gateway, and the gateway manages processor relationships on your behalf. You have a single integration point and simplified operations. You also have limited control over processor selection and cost optimisation.

An acquirer-led model means your primary relationship is with a payment acquirer or processor, and you integrate directly with them or use a thin orchestration layer. You have more control over cost and capability but higher operational complexity. You also negotiate processor terms directly, which means volume leverage matters. Worldpay, FIS, Global Payments operate this model.

Gateway-led is better for most businesses under $100 million transaction volume. It offers simplicity and predictability. Acquirer-led makes sense once you have significant volume and specific requirements that generic gateways do not handle well.

Card-Only vs. Multi-Rail

Card-only architectures accept only credit and debit cards (and potentially wallets like Apple Pay, which use card rails underneath). They are the simplest architecturally and integrate with existing payment processors easily. The downside is that card-only limits addressable market. In developed markets, 70 to 80 percent of online transactions are cards or card-adjacent (wallets). In developing markets, card penetration is much lower. Bank transfers, local payment methods, and cash alternatives are more common.

Multi-rail architectures support multiple payment methods: cards, bank transfers (ACH, SEPA, real-time payments), wallets, buy-now-pay-later, crypto, and local payment methods. Multi-rail conversion rates are typically 3 to 8 percent higher than card-only in international markets, but the operational complexity increases significantly. Each payment method requires separate integration, separate reconciliation, separate compliance review.

The decision depends on geography. If you sell exclusively in North America or Western Europe, card-only works. If you sell to customers anywhere, multi-rail is necessary for competitive conversion rates.

---

Common Architectural Mistakes and How to Avoid Them

Over-Engineering for Day One

Early-stage companies often over-engineer their payment architecture before they understand their transaction mix or volume. They build multi-processor orchestration when a single processor would serve them fine. They implement sophisticated fraud detection when they have 10 transactions per day. They hire a VP of payments when they do not yet have product-market fit. This is premature optimisation. It delays launch. It creates technical debt that is worse than the operational debt of using a less-than-optimal processor.

Start with a single payments platform that handles your initial use case well. You can optimize later. Stripe, Adyen, and Square are good start points because they handle a wide range of transaction types, provide strong developer experience, and have no volume minimums.

Under-Investing in Observability

Many organisations treat payments infrastructure like a black box. They have no real-time visibility into settlement status, exception rates, or failure patterns. When a customer says "my payment failed," they have no data to debug the issue. When fraud spikes, they do not know why. When a processor experiences latency, they do not detect it immediately.

Invest in observability from day one. This means: real-time dashboards tracking transaction success rates, settlement status, and exception rates by processor and payment method. Alerting on anomalies (sudden spike in failures, latency increase, unusual transaction volume). Structured logging that captures full request-response payloads (scrubbed of PII) so you can debug issues. This investment typically requires 1 to 2 weeks of engineering time and pays for itself through faster incident response and better visibility into cost.

Coupling Too Tightly to Vendor Implementation Details

A subtle mistake: letting processor-specific implementation details leak into your core application logic. You check processor-specific error codes in your payment handler. You use processor-specific webhook formats directly. You rely on processor-specific settlement timing assumptions. When you eventually need to migrate to a different processor, you discover hundreds of places in your codebase that assume processor X's behaviour.

Build an abstraction layer between your application and your processor. Define your own payment lifecycle (created, processing, succeeded, failed) and map processor-specific states to your abstraction. Define your own webhook format and translate from processor-specific formats. This abstraction costs engineering time upfront but pays dividends when you need to swap processors or add a secondary processor without rewriting your application.

Forgetting About Reconciliation Until You Have to

Reconciliation is unglamorous infrastructure work. It does not generate revenue. It is easy to deprioritise. Many organisations discover too late that their payment reconciliation is manual, slow, and error-prone. They have a spreadsheet somewhere with transactions that do not match up. They have no idea why.

Build reconciliation infrastructure before you need it. Use processor webhooks to capture transaction events in your system. Match webhook events against your order database. Alert on mismatches. Automate settlement accounting. This requires 2 to 4 weeks of engineering time but eliminates entire categories of operational incidents.

Ignoring Compliance Until You Have a Problem

Payment compliance is complex and changes frequently. PCI compliance, regulatory compliance around KYC, AML, OFAC screening, and jurisdiction-specific requirements. Many organisations defer these until they grow to size or until a processor audit catches them off guard. By that point, remediation is expensive.

Understand your compliance requirements for your business model. If you are a marketplace, you need to understand seller onboarding requirements and AML screening. If you are international, you need to understand where your customers live and what licencing you need. If you process high-value transactions, you need KYC verification. Plan for this in your architecture.

---

The Payments Architect's Toolkit: Monitoring and Measurement

Optimal payment architecture depends on measuring what matters. Most organisations do not measure enough. Here is what you need to monitor, measure, and optimise.

Cost Metrics

• Effective rate: Total payment fees (including processor fees, gateway fees, compliance fees, and reconciliation tooling) divided by total transaction volume. This is your true cost of accepting payments. Most businesses do not know this number precisely.
• Cost by payment method: Not all payment methods have the same cost. Card transactions cost different than wallet transactions. International cards cost more than domestic. Knowing the cost by method lets you optimise routing.
• Cost by processor: If you use multiple processors, understand the true cost including integration maintenance overhead. A processor might have lower per-transaction fees but requires more engineering maintenance.
• Cost by geography: International transactions are more expensive than domestic. Understanding the cost by geography informs pricing and customer acquisition strategy.

Reliability Metrics

• Success rate: Percentage of payment attempts that result in a successful charge. This varies by payment method, geography, and processor. Track this separately for each.
• Latency percentiles: How long does a payment take from request to authorisation? Track p50, p95, and p99 latency. Latency above 5 seconds degrades user experience noticeably.
• Processor uptime: If you use multiple processors, track uptime for each. This informs your fallback routing decisions.
• Exception rate: What percentage of transactions result in exceptions, errors, or manual interventions? Track this by processor and error category.

Risk Metrics

• Fraud rate: Percentage of legitimate charges that get disputed or identified as fraud. Track this by business segment and payment method.
• False decline rate: Percentage of legitimate transactions that get declined. This is often a larger problem than actual fraud.
• Chargeback rate: Number of chargebacks as a percentage of transactions. Industry varies widely. Card-heavy businesses see 0.1 to 0.5 percent. High-risk categories see higher.

Operational Metrics

• Mean time to detect (MTTD): How quickly do you detect a processor outage or degradation? Manually monitoring dashboards is slow. Automated alerting is fast.
• Mean time to resolve (MTTR): How long from detection to resolution? If you have fallback routing, MTTR should be minutes. If you do not, it is hours.
• Reconciliation lag: How quickly do you reconcile processor settlements against your order database? Ideal is real-time. Many organisations take days.
• Engineering overhead: Hours per month spent on payment-related operational tasks, debugging, and maintenance. This is hard to measure but critical context when deciding between orchestration approaches.