Payment Gap: Rails Aren’t Enough
Many crypto infrastructure companies that build enterprise payment products are excellent at the wrong thing.
They understand every technical detail of a blockchain transaction: the routing, the finality, the gas optimization, the chain selection. The API is robust, and the settlement is fast. But when the first serious enterprise conversation happens, the customer's questions land in a place nobody prepared for. They aren't about the technology; They're about what happens when something goes wrong.
Who gets notified, in what format, on which channel? What’s the SLA? If a payment gets lost, what's the retry logic and who controls it? How does the exception surface in the payer's system? What does the beneficiary's operations team see, and what action does it trigger? What’s the escalation process and when does a human need to intervene?
The crypto team often concludes the customer is being difficult or stuck in legacy thinking. In fact, the customer isn't failing to understand the technology; the technology is failing to understand payments.
This distinction matters more than almost anything else in how a stablecoin payment product gets built. Not because the transaction layer isn't important, but because the teams treating it as the finished product are losing deals to teams who understood payments first and built accordingly.
A payment is not (just) a transaction
In crypto, the atomic unit of thinking is the blockchain transaction. It has addresses, a payload, a signature, a fee, and a finality state. When the transaction moves from the mempool into a new block on the blockchain, the job is done. Clean start and finish, and technically satisfying.
In payments, the atomic unit is something different. It's the payment cycle: a sequence that begins before money moves and ends well after it does.
Here's what that cycle actually looks like for a typical B2B cross-border payment:
Purchase agreement: The buyer agrees to buy goods or services from a seller, and issues a formal document (usually a standard purchase order) that includes prices, delivery terms, and payment timeline.
Invoice issuance and approval: After delivery, the seller sends an invoice to the buyer to request payment. The invoice includes amount owed, payment terms (e.g. all due in 30 days), due date, and payment instructions (e.g. seller’s bank and bank account number). Someone from the finance department on the buyer’s side will verify the invoice details (delivery status, pricing, available budget) and approve the payment.
Initiation: The buyer uses their internal banking or treasury management platform to initiate the payment. This instruction carries structured data: amount, currency, beneficiary (seller) details, payment purpose, reference codes that connect the payment to an invoice or purchase order.
Clearing: Financial institutions validate payment instructions, confirm account details, and route the transaction through the appropriate payment network. This stage also often includes compliance and risk checks such as AML screening, sanctions screening, fraud detection, KYC verification, and transaction monitoring.
Settlement: The money moves. A cross-border payment doesn't travel directly from the payer's bank to the beneficiary's bank; it hops through a chain of intermediaries, each maintaining nostro and vostro accounts that pre-fund the next leg of the journey. In stablecoin payments, in theory, all of this collapses into a single on-chain transaction that settles in seconds without intermediaries. This is where crypto is genuinely better: faster, cheaper, and always-on.
Reconciliation: Finance departments on both sides need to match the payment to the corresponding obligation. This is where crypto integrations can fall short. Blockchain transactions are originally designed to carry minimal structured metadata. Traditional payment systems carry rich, standardized reference data, and translating on-chain finality into ledger-ready confirmation is unglamorous work that is completely invisible when it's done well, but catastrophic when it isn't.
Exception handling: Something always goes wrong at scale. Beneficiary address mismatches, duplicate detection, or any compliance flags can trigger a Request for Information (RFI) that can take anywhere from hours to day to resolve. Each exception needs a deterministic resolution path: not an ad hoc support ticket, but a defined operational workflow that can be executed consistently and audited reliably.
The transaction is steps four and five. Building for payments means building for all seven.
Why traditional payments are so complicated
When crypto teams encounter the traditional payment journey for the first time, the reaction is usually: why is this so complicated? Why are there so many intermediaries? Why does a cross-border payment still take days?
These are fair questions, but they have answers that are worth exploring before dismissing the structure as legacy inertia.
The correspondent banking rail (SWIFT, nostro/vostro accounts, intermediary banks) exists because cross-border payments require trust between parties that don't have direct relationships. The intermediaries are trust proxies. They are slow and expensive, but they carry something valuable: legal accountability, dispute resolution, and the ability to reverse or recall payments when something goes wrong.
ISO 20022, the messaging standard that went live on SWIFT in 2023 and governs most modern payment infrastructure, looks like bureaucratic overengineering until you understand what it's trying to do and improve upon. It is a common language for payment data (in XML - this alone should tell you how slow the traditional payment world moves) that lets a payment instruction generated in Tokyo carry enough structured information to be processed correctly in Frankfurt without a human in the middle (which happens often with the older MT format). The verbosity is the feature.
PSPs (payment service providers) exist because most businesses can’t (and don't want to) deal with every payment rail. They want a single point of contact that handles multiple rails, multiple currencies, multiple compliance jurisdictions, and presents a consistent interface regardless of what's happening underneath. The orchestration logic predates stablecoins by decades. No merchants want to handle stablecoins separately if they can avoid it.
Understanding why these structures exist is not an argument for leaving them untouched. It helps us know which parts are genuinely replaceable, and which parts solve real problems that any replacement will need to solve differently.
The vertical trap
Here's the mistake that crypto infrastructure companies make most often.
They build a general-purpose stablecoin payment API to support multiple chains, multiple stablecoins, on/off ramps, and even comprehensive compliance tooling. Even the integration is straightforward. But then they discover that enterprise buyers don't want general-purpose infrastructure.
Enterprise buyers want solutions for specific pain points. A payroll platform disbursing contractor payments across Southeast Asia wants to know how the platform handles payroll-designated transfers to individual recipients in markets with strict labor and tax regulations. A gaming platform paying out tournament winnings to players across the same region wants to know how it handles burst disbursements to individuals in markets with capital controls. While a crypto infrastructure company's answer to both questions is usually: "we can support all of that,” it sounds like to the buyers: "we haven't thought specifically about your problem."
This is not an argument against building horizontal infrastructure. Robust liquidity and compliance layers are the prerequisite for everything else; you cannot build credible vertical surfaces on a weak foundation. But horizontal infrastructure is invisible to an enterprise buyer until it's surfaced through something specific to their context.
Consider a Chinese gaming company with a flagship IP, a competitive circuit, and a growing player base across Southeast Asia. Tournament prize payouts go to individual winners across a dozen jurisdictions, many without corporate bank accounts, all expecting funds within hours of a match result. In-game revenue collected internationally needs to navigate SAFE reporting requirements and capital controls before repatriation. Several Southeast Asian regulators treat gaming-adjacent payouts as a specific payment category with enhanced monitoring obligations. None of this appears in a general-purpose API's documentation, because none of it was anticipated when the API was designed.
Depth beats breadth in enterprise payments. The right long-term architecture is horizontal infrastructure with vertical surfaces: a common underlying platform with specific integrations, workflows, and documentation oriented toward targeted corridors and verticals. The horizontal layer makes it scalable, but the vertical layer makes it sellable. Both are necessary.
PSPs as the real decision maker
There is a further implication that changes how a payment product should be designed.
The endpoints of a stablecoin payment (sender and receiver) is usually not the right integration target. End customers want payment capability embedded in the software they already use, such as their ERP or their payments platform. In most cases, they don’t want the overhead of onboarding a new vendor relationship with a stablecoin infrastructure provider, especially one involving crypto and the internal scrutiny it brings. They want their existing vendor to add stablecoin capability for them.
This means the actual buying decision maker is the PSP: the business that currently serves the end customer and needs to add stablecoin rails to its existing product without rebuilding its core platform.
Building for PSPs is a fundamentally different product philosophy than building for endpoints. The PSP's questions are more about integration architecture, and less about payment mechanics. Can it be embedded in our existing flow without significantly changing our UI? How does it handle our existing reconciliation format? Does it support our compliance data model (which implies no direct crypto exposure) or will we need to transform data at the boundary? What does the failure mode look like and who handles exception resolution?
PSPs with vertical focus, such as a payroll-specific PSP or a marketplace payout provider, add another layer. They have domain-specific compliance requirements, data models, and operational workflows that a horizontal stablecoin API does not natively support. The platform that has already done the work of understanding those requirements, and built the integration surfaces to match them, is not competing on price. It is competing on fit.
What this means for how to build
Design for the payment cycle. Every feature decision should be evaluated against all seven steps, not just step five. Reconciliation output formats, exception handling workflows, reference data preservation, settlement confirmation structure: these should be part of MVP and not phase 2 features. They are what enterprise buyers are actually evaluating when they run a pilot. A fast, cheap transaction engine that leaves the rest of the cycle as the customer's integration problem is the single most common reason crypto payment pitches don't convert to production contracts.
Build the horizontal foundation and surface it vertically. The stablecoin layer (multi-chain routing, liquidity management, compliance primitives, settlement execution) is the foundation that makes vertical surfaces possible. But the distance between those two things is where enterprise deals are won and lost. A gaming platform's payment requirement is very different from a trade finance platform: Tournament payouts to individuals across jurisdictions with capital controls require different KYC logic, liquidity prefunding, compliance data outputs, and reconciliation structures than a corporate treasury transfer between Singapore and Hong Kong. The platform built for specific requirements competes on fit, not features.
Build for PSP integration architecture. The interfaces that matter most are not the ones end customers see. They are the ones PSPs use to embed stablecoin capability into their existing stack without disrupting the product their customers already depend on. This means APIs designed around PSP data models, not crypto-native abstractions. Compliance data outputs should arrive in formats PSP compliance teams can use directly without further transformation. Error codes and exception states that map to the operational workflows PSPs already have, not new ones they'll need to build. When a vertically focused PSP evaluates a stablecoin infrastructure partner, they want integration that fits their operations.
Treat compliance data as a product output, not a byproduct. The data flowing out of the platform will be seen by PSP compliance teams, their banking partners, and their regulators. If that data is unstructured, incomplete, or requires transformation before it's usable, it creates an integration problem that sits permanently between the platform and production deployment. Every compliance output should be designed with the same intentionality as the API itself.
The stablecoin rails are necessary, but not sufficient. No serious enterprise buyer will evaluate a platform that hasn't. But what closes deals is everything wrapped around the transaction: the data structures, the integration surfaces, the exception workflows, the compliance outputs, the vertical depth that tells a buyer you understand their specific problem and have already built for it.
That is what "rails aren't enough" actually means in practice. The transaction layer matters, but the teams who understood payments first and built the full cycle accordingly will win. Build for the payment, and the transaction will take care of itself.
.png)