Every B2B payment program has an adverse payer population. Large enterprise buyers who push payment cost to their suppliers. Procurement teams with policies against paying card surcharges. Businesses where the AP team has no authority to change payment terms and no incentive to do so.
These counterparties won't accept payment fees. They won't pay for faster settlement. They won't change their payment behavior regardless of how the product is priced. The standard payment revenue model — charge the payer a transaction fee or surcharge — doesn't work against this population.
The solution is to stop trying to monetize the payer. The problem exists on the receiver side. That's where the revenue model needs to be designed.
Why the receiver has a problem
The adverse payer creates a specific set of problems for the receiver: payment timing that doesn't match working capital needs, payment terms extended beyond net 30 because the payer can, limited visibility into when payment will actually arrive, and reconciliation complexity when the payer doesn't include remittance data. All of these have costs. All of them are addressable at the payment layer — for a fee paid by the receiver, not the payer.
Three receiver-side revenue models
Early payment fee. The receiver gets paid before the invoice due date — and pays a fee for the working capital benefit. The payer's terms don't change. The receiver opts in. The program captures a percentage of the invoice amount as the early payment fee. For a receiver with $2M in monthly receivables from slow-paying buyers, even a 0.5% early payment fee generates $10,000/month in revenue — funded entirely by the receiver's working capital benefit, not the payer's behavior.
AR financing product. A step further: the program advances payment to the receiver before the payer settles. The payer's terms are unchanged. The receiver gets funds immediately and pays a financing rate. This is a credit product — it requires underwriting and capital — but it captures significantly higher revenue per transaction than a pure speed premium. The adverse payer's behavior becomes irrelevant to the receiver's cash position.
Speed fee paid by receiver. For payers who will pay early but charge for it (dynamic discounting), the receiver evaluates whether the cost of faster payment is worth the working capital benefit. The receiver pays the fee — voluntarily, because the alternative is waiting for payment under adverse terms. The program captures the spread between the cost of faster settlement and the fee charged to the receiver.
Designing the adverse payer model
The receiver-side revenue model has a different product design requirement than the payer-side model. The receiver needs to understand the working capital benefit clearly enough to make an opt-in decision. That means the product needs a cost-of-waiting calculator, a clear fee structure, and a frictionless enrollment flow.
Programs that have tried to add receiver-side revenue as an afterthought usually find that the enrollment friction is too high — because the product wasn't designed for receiver opt-in from the start. The workflow, the disclosures, the pricing display all need to be designed for the receiver's decision context.
This is a program design decision, not a feature addition. The product architecture for a program with a significant adverse payer population looks different from the architecture for a program where payers can be charged directly. Both are valid — but they need to be designed explicitly, not inherited by default.