Payment Infrastructure
Payment infrastructure is the product surface where orchestration, ledger, settlement and risk meet. These essays and case studies cover what it actually takes to ship and operate a multi-rail platform at scale.
Case studies
A regulated, multi-rail payments platform processing $1B+ annual GTV and 25M+ monthly transactions across pay-in, payout, wallets (DCB/IBFT), card acquiring (MPGS/MDES), settlement, FX and cross-border corridors, PCI DSS and ISO/IEC 27001 certified.
A multi-rail settlement and reconciliation engine, canonical double-entry ledger, three-way auto-reconciliation, exception management and corridor-aware payout windows. Closed the gap between treasury, finance and product at $1B+ GTV.
Essays · 17
SWIFT vs Card Rails vs Local Wallets: When to Use What
There is no universal best rail. There is the best rail for this corridor, this amount, this customer, this use case.
Layered Fraud Controls in the Payments Stack
No single fraud control survives a determined attacker. Layered controls do, and they do it without crushing conversion.
Why Local Payment Methods Are a Developer-Experience Problem
A merchant adopts a local payment method only if integrating it is as easy as integrating cards. Most LPM integrations fail that test.
Financial Controls Are Product Requirements, Not Compliance Afterthoughts
If your audit trail is reconstructed from logs, you do not have controls. You have archaeology.
Ledger Design for Multi-Rail Payments
The ledger is the source of truth for the entire platform. Most teams discover this after they have shipped the wrong one.
Hosted Checkout vs Direct Card Processing: A Product Maturity Guide (MPGS, MDES, 3DS)
Why hosted checkout is the right first step and the wrong last step, and what direct card processing actually demands from a product team.
Settlement Windows and Merchant Trust
Merchants do not churn because of fees. They churn because of settlement uncertainty.
Click to Pay (VCTP / MCTP): The Scheme-Led Checkout Standard, How It Actually Works
Click to Pay is the schemes' answer to Apple Pay and Google Pay — a scheme-owned consumer checkout standard that lifts authorisation rate and removes card-number entry. It works. It's just under-marketed. This is the operator-grade map.
CyberSource Architecture: The Visa-Owned Payment Gateway, How It Differs From MPGS
CyberSource is the gateway Visa wants you to standardise on. The product surface is broader than MPGS — Decision Manager and Flex Microform have no Mastercard equivalents — but the integration patterns and lifecycle traps are different in important ways.
EMV 3DS2: Step-Up Logic, Frictionless Flow and the Auth-Rate Optimisation Nobody Explains
3DS2 is the most consequential auth-rate lever most merchants don't touch. Default config gives you maximum step-up and minimum conversion. This is the operator's guide to the exemption logic that lifts auth rate without breaking compliance.
Payment Infrastructure Is Not Just APIs, It Is State, Trust and Failure Handling
APIs are the easy part. The hard part is what happens between the auth response and the bank statement.
Three-Way Reconciliation at Scale
Three-way reconciliation is the only model that survives multi-rail growth. Here is how to actually build it.
MDES + Network Tokenisation: How It Actually Works (and Why You Should Default to It)
Network tokens are the most under-explained product in payments. They are the difference between a 60% authorisation rate and a 90% authorisation rate on stored cards. Default to them. Build for them. Migrate to them.
MPGS Architecture: How MasterCard Payment Gateway Services Actually Works (and Where It Breaks)
MPGS is a payment gateway the way SAP is an ERP — vast, powerful, and indifferent to whether you understand it. The integration choices you make in the first sprint decide whether the platform scales for five years or rots for five.
Reconciliation Is Product Infrastructure, Not Back Office
If finance is your reconciliation system, you do not have one. A practitioner view from running multi-rail settlement at scale.
Virtual Card Accounts (VCA): The Quiet Backbone of B2B, Travel and Marketplace Payments
VCAs look like a card primitive. They are actually a control primitive. The product job is to decide which controls travel with the number, and which sit in the platform.
Open Banking Product Architecture: Aggregator vs Direct, AISP vs PISP, and Where the Value Actually Lives
Open banking is not a data product. It is a workflow product that happens to use bank data as its raw material. Teams that miss this build pretty dashboards and weak businesses.