Payment programs consistently undercharge. Not by a small margin — by enough that the difference between current pricing and defensible pricing is often the difference between a profitable payments business and one that covers costs on a good month.
The root cause is almost always the same: fees were never designed. They were copied from a competitor, accepted from a vendor's rate sheet, or set by whoever answered the "what should we charge?" question fastest in a product meeting. None of those methods produce a fee structure that captures the actual value the program delivers.
Designing a fee structure requires a different approach — one that starts with value quantification, not market comparison.
Why competitor benchmarking produces the wrong answer
The instinct to benchmark competitors is understandable. If similar programs charge $1.50 per ACH transaction, starting at $1.50 feels safe. The problem is that competitor pricing reflects their cost structure, their volume economics, their customer mix, and their willingness to compete on price — none of which are necessarily relevant to your program.
Benchmarking also anchors the pricing conversation at the market floor rather than the value ceiling. The programs setting prices against what competitors charge are pricing against the commodity. The programs pricing against the value they deliver are pricing against a different reference point entirely — and capturing significantly more margin.
Competitor benchmarks belong in the fee design process, but as a sanity check at the end, not a starting point. They answer "is this defensible against competitive alternatives?" They don't answer "are we capturing the value we're delivering?"
The value quantification methodology
Fee design starts by quantifying what the program eliminates or enables for the customer. For each product or feature, the question is: what does this replace, what does it cost the customer today, and what is the customer's cost of not having it?
For a B2B payment program, an ACH transaction replaces a check. The all-in cost of a check — printing, mailing, reconciliation labor, return mail handling, payment tracking — is typically $8–$15 per check in a mid-market AP operation. A $1.50 ACH transaction fee against an $8–$15 check cost represents 10–20% of the value delivered. That's a lot of margin left for the buyer even at $3.00 or $4.00 per transaction. The fee design question isn't "is $1.50 competitive?" — it's "what fraction of the value we're delivering should we capture?"
For a same-day payment delivery tier, the value is the working capital benefit of same-day versus next-day settlement for the receiver. For a $200,000 invoice payment, one day of working capital at a 5% cost of capital is worth roughly $27. A $2.00 same-day premium captures less than 8% of the value delivered. That's not a pricing floor — it's well below where a defensible premium could sit.
The three fee structure models — and when each fits
Per-transaction fees. The simplest model and the most common default. Works well when transactions are homogeneous in size and the value delivered is consistent per transaction. Breaks down for programs where transaction size varies significantly — a flat $2.00 fee on a $500 transaction is 40bps; on a $50,000 transaction it's 0.4bps. The same fee captures very different fractions of value depending on transaction size.
Basis point fees. A percentage of transaction value aligns the fee with the economic scale of the transaction. Common in card programs (interchange is already expressed in bps) and in programs with large B2B transactions where flat fees would be a rounding error. The design question is which tier structure — flat bps, tiered by volume, or capped — matches the program's customer economics and cost structure.
Subscription tiers with included transaction allowances. Bundles a set of capabilities and transaction volume into a monthly fee. Works well when the value is in the platform capabilities (reconciliation, reporting, workflow automation) rather than purely in the transaction execution. Produces more predictable revenue, reduces per-transaction price sensitivity, and often captures more total value per customer than per-transaction pricing alone. The risk: customers who use far more volume than the tier includes create margin compression at the top of the customer base.
Most programs benefit from a hybrid: subscription tiers for platform access plus per-transaction or bps fees for transaction execution, with speed tiers priced separately. The subscription captures the platform value; the transaction fee captures the execution value; the speed premium captures the delivery value. Each fee element is anchored to a distinct value the program delivers.
What "willingness to pay" actually tells you
Willingness to pay research — asking customers or potential customers what they'd pay — systematically underestimates real willingness to pay. Buyers always anchor low when asked directly. The more useful measure is revealed willingness to pay: what do buyers actually do when prices change?
For programs without transaction history to analyze, the proxy is churn behavior at different price points in comparable programs. For programs with existing customers, a structured price increase test on a segment of the customer base — with a measurement of churn, objection rate, and revenue impact — is the most reliable way to find the price ceiling. Programs that have never run a price test are almost certainly leaving margin on the table because they've priced to avoid a conversation they've never had.
The fee structure elements most programs are missing
Beyond the transaction fee, three fee elements appear in well-designed programs and are absent from most:
Speed tier pricing. Standard delivery at the base price; same-day and instant delivery at a premium. The premium is priced against the receiver's working capital value, not against the rail cost difference. Covered in detail in the payment speed post.
Data and reporting fees. Enhanced remittance data, ERP integration feeds, custom reporting formats, and exception management workflows are all worth charging for separately from transaction execution. Programs that include all of these in the base transaction fee are delivering significant value without capturing any of it.
Exception and remediation fees. Returns, reversals, and manual exception handling cost the program real money in labor and operational overhead. Pricing exceptions separately — a return fee, a reversal fee, a manual exception handling fee — both captures the cost recovery and creates a pricing signal that incentivizes customers toward cleaner payment practices that reduce program costs.
The repricing conversation most programs avoid
Programs that launched with underdeveloped fee structures face a harder problem than programs that design them correctly from the start: repricing existing customers. The conversation is difficult but not impossible, and avoiding it indefinitely is more expensive than having it.
The most effective approach frames repricing around value added rather than cost recovery — "we've added same-day delivery, ERP integration, and enhanced remittance capabilities; the new fee structure reflects those additions" rather than "our costs have increased." The programs that reframe repricing as a product upgrade rather than a price increase convert a larger fraction of the customer base without churning the accounts that matter.
The programs that wait to have this conversation until the economics force it — when the business needs the revenue to survive — have the least negotiating room and the worst customer experience. Designing fees correctly from the beginning eliminates the repricing problem entirely.