A B2B Payment Menu
The question isn't which rail. It’s what purpose.
The easiest B2B payment to send is also the oldest. A check requires nothing more than the information on a supplier’s invoice. Every electronic alternative requires more effort, ranging from credentials that must be exchanged, to systems that need to be integrated, to questions about which payment methods the other party accepts. In digitizing payment methods, we’ve made them more complicated, not simpler. More friction means lower adoption.
What would the perfect payment look like?
Honestly, there’s no one perfect payment. It depends on the circumstances. And yet, as an industry, we keep debating the wrong question. We argue about rails, such as ACH versus RTP versus wire versus card (and more recently versus stablecoins), when we should be asking fundamentally, what does this payment need to do, and what is that outcome worth?
Most B2B transactions are scheduled, so speed isn’t usually important. However, there are instances when a buyer needs to pay at the last minute or a supplier wants to accelerate funds availability. Each of those situations can be (and are being) monetized.
The vast majority of B2B transactions are initiated by the buyer, who sends money to suppliers via check, ACH, wire, or RTP. Typically the buyer can’t send the payment if they don’t have the funds, with the exception of checks, which can bounce. However, when a supplier initiates the transaction, either by debiting their buyer via ACH or initiating a card payment, the transaction can fail, or the buyer may subsequently reverse it. This is problematic for the supplier.
When a business buyer pays for something, they provide information to the supplier explaining what they’re paying for, usually in the form of a list of invoices and the amounts paid. If the buyer is short-paying an invoice, they also provide an explanation, such as wrong price, wrong quantity, poor quality, or missing goods. Once upon a time that explanation went into an envelope with a check. When we digitize payments, the explanation is generally separated from the funds and delivered via email. Sometimes a supplier visits a portal hosted by their customer’s bank or AP provider to obtain the remittance data. The bifurcation of the data and the money, and the hassle of applying incoming funds to open receivables, is a profound challenge in B2B payments.
Most B2B transactions are between trusted counterparties. The supplier has already delivered goods or services and furnished an invoice with 30-, 45-, or 60-day terms. But risk mitigation is still necessary. The buyer wants to ensure they’re paying a legitimate company, for a legitimate invoice, with payment credentials that genuinely belong to the supplier. The supplier wants to know their payment won’t be misdirected, and that the credentials provided (if the supplier initiates the transaction) do indeed belong to their customer. B2B transactions are much larger than consumer transactions, so even a single misdirected payment can have material consequences.
Yet, the cost of a transaction has nothing to do with its value to the buyer or supplier on either side. We price by rail when we should price by value. This is a fundamental challenge.
What would it look like if we got it right? I created a menu of different options for different circumstances, each priced to reflect what it delivers. I’m not specifying how the money moves. And that’s the point.
Basic Credit
This is essentially ACH credit. It reaches any bank account, settles overnight as scheduled by the buyer, and carries basic information in a reference field. The buyer can’t send if they don’t have funds, so the supplier has good funds. All account credentials are tokenized. Cost is a flat fee of pennies to 50 cents depending on volume, paid by both buyer and supplier, though providers may offer bundles or subsidize.
Enhanced Credit
This is a variation of ACH+, but at scale. It settles the same day, on the invoice due date, and delivers data in a format the supplier can process automatically. The buyer can’t send if they don’t have funds, so the supplier has good funds. Credentials are tokenized. Cost is ad valorem, 25-35 basis points with a cap, paid by the supplier, who benefits from timeliness and data that enables automation.
Guaranteed Debit
This is what payment service providers are currently charging SMBs. It reaches any bank account, settles the same day, and because it’s initiated on behalf of the supplier, the data is logically tied to the invoice. The difference from other tiers is that the provider guarantees the funds. Credentials are tokenized. Cost is ad valorem, 60-100 basis points with a cap depending on volume, paid by the supplier, who is paying for the assurance of good funds.
Accelerated
This is essentially dynamic discounting. It’s widely available through an open-loop network or federated model, with timing at the supplier’s discretion, earlier than the invoice due date. The buyer can’t send if they don’t have funds, so the supplier has good funds. Data is logically tied to the invoice. Cost is ad valorem on a sliding scale depending on how close the payment is to the date the invoice was furnished, paid by the supplier, who is paying for accelerated funds availability.
Last Minute
This is for the buyer who needs to pay immediately. It reaches any bank account, settles in real time, and the buyer can’t send if they don’t have funds, so the supplier has good funds. Data depends on whether this rides on basic or enhanced credit. Credentials are tokenized. Cost is ad valorem, 25-35 basis points with a cap, paid by the buyer, who is paying a premium for just-in-time payment.
Of course, this framework assumes domestic transactions. Cross-border and cross-currency payments add another layer of complexity as well as another layer of opportunity. FX spreads alone can be significant. But that’s a menu for another day.
What does your ideal B2B payment menu look like? I’d love to hear your thoughts in the comments.
Great framing, Erin. The “battle of the rails” has indeed become a distraction from focusing on why we want or need certain payment features in the first place.
Where I get nervous is value-based pricing. When something covers credit risk, pricing should be commensurate with the risk being covered. But for speed, richer data, or cleaner remittance delivery, pricing by payment value risks slowing the very evolution of payment products we need.
The healthy parts of the economy do not price on the value created for the receiver. They price on cost, plus a margin shaped by scarcity, differentiation, competitive design, and sometimes marketing. Nobody wants a bottle of water priced by how dehydrated I am.
It is the commingling of payment services and credit risk mitigation that got us into out-of-control card economics in the first place.