Payment revenue forecasts are almost always wrong in the same direction
A platform builds a payment revenue model. It projects 80 basis points of take rate on $10M monthly volume — $960K annually. Twelve months later it's generating 22 basis points — $264K annually. The volume is there. The payment program is live. The economics aren't.
This miss — payment revenue forecasting below expectation — is so common that it deserves a structural explanation rather than treatment as a one-off forecasting error. The causes are predictable, and they are almost always architectural rather than volume-related.
Why forecasts miss: the five structural causes
1. The forecast used top-of-stack interchange, not net interchange. Most payment revenue models project against gross interchange rates — 175 bps for commercial cards, 150 bps for consumer debit. They don't model the middleware margin extraction (30–60% in BaaS programs), the card network assessments, and the processor fees that reduce gross interchange to net interchange. A forecast using 175 bps gross often realizes 60–90 bps net on a BaaS program.
2. The card mix assumption was wrong. Payment revenue models often assume a higher card percentage than the program actually achieves at launch. If the forecast assumed 70% card and the program launches at 40% (because ACH is cheaper for many B2B use cases), the interchange revenue is proportionally lower. Card mix optimization takes 12–24 months of active management.
3. VCard acceptance rate was assumed, not designed. AP programs that forecast $X in VCard interchange based on payment volume × assumed acceptance rate almost always miss because acceptance rate is not a given — it's the output of a supplier enablement program that takes years to build. Forecasting 40% VCard acceptance at launch is not wrong if you have the supplier enablement machine to achieve it. It is wrong if you think it happens automatically.
4. Fee structure was not designed before launch. Revenue forecasts that include "transaction fees" or "premium rail fees" as a revenue line require those fee structures to be designed, implemented, and customer-accepted before launch. Programs that launch with fee structures still under discussion typically miss the fee revenue line entirely in year one.
5. Float was not negotiated. Forecasts that include float yield as a revenue line require float to be negotiated with the sponsor bank before the program agreement is signed. Float that isn't in the contract doesn't appear in the revenue — regardless of what the average daily balance turns out to be.
How to build a payment revenue forecast that holds
A payment revenue forecast that will hold at 12 months models four things differently than most do.
First, model net interchange rather than gross — apply the BaaS or processor revenue share to gross interchange before projecting revenue. If you don't know the revenue share, that's the first thing to establish before building a forecast.
Second, phase the forecast by when each revenue stream is operational. VCard interchange doesn't appear in month one if the supplier enablement program is still being built. Monetized ACH doesn't appear until the product is launched and customers are using it.
Third, model VCard acceptance rate as a ramp — starting at launch acceptance (typically 5–10%) and reaching target acceptance at 18–24 months, not day one.
Fourth, only forecast fee and float revenue lines if the commercial agreements are already in place. "We'll negotiate float later" is a forecast assumption that should carry a heavy discount until the contract is signed.
If your payment revenue is running below forecast, the payments leakage calculator can help identify which gaps apply. Or talk with us directly.