How to turn a payments change into a funded project, using numbers the people who sign can check.
What a payments business case has to prove
A payments business case is not a pitch. It is an argument that a specific change will move a specific number by more than it costs to make the change, and that the risk of not making it is real. The people who fund it have seen a hundred decks promising transformation. What they have rarely seen is a case that names the metric, shows the current baseline, and states honestly what could go wrong. That honesty is what gets it funded, because it signals you have done the work rather than the marketing.
Start from the number you are trying to move, not the technology you want to buy. A processor migration is not a goal. A two-point lift in authorization rate is a goal, and a processor migration might be one way to reach it. Lead with the outcome and the technology becomes a means the reader can evaluate, rather than a cost they have to justify.
The four numbers that carry almost every payments case
Most payments business cases rest on some combination of four levers, and naming which ones you are pulling makes the case legible. The first is authorization rate: the share of legitimate transactions that get approved. A single point of lift on a large volume is often the largest number on the page, and it is measurable before and after, which makes it credible.
The second is cost per transaction: interchange, scheme fees, processor markup, and gateway costs, read as a blended rate rather than a headline price. The third is fraud and loss: chargebacks, fraud write-offs, and the operational cost of fighting them. The fourth is operational cost: the engineering and finance hours spent on reconciliation, exceptions, and maintaining connections to systems that no longer fit. Every serious case quantifies at least one of these against a real baseline, and resists the temptation to claim all four at once.
Frame it for the person who signs, not the person who builds
The engineer who wants the migration and the executive who funds it are reading for different things. The executive is not evaluating the architecture. They are asking whether the number is real, whether the team can deliver it, and what happens to them if it fails. Write the case so those three questions are answered on the first page: the expected gain with its baseline, the confidence you have in delivering it, and the downside if the estimate is wrong.
Give a range, not a point estimate. A case that says a change will lift authorization by 1.5 to 2.5 points, with the assumptions behind each end of the range, reads as more trustworthy than one promising exactly two. Decision-makers fund ranges they can interrogate. They discount single numbers that arrive without their working shown.
The trap: modeling the upside and ignoring the switching cost
The most common way a payments business case fails is not that the upside was wrong. It is that the switching cost was never in the model. Migrating a processor, adding a rail, or re-routing traffic carries real costs that rarely appear on the optimistic page: the engineering time, the parallel-running period where you pay for two stacks, the reconciliation rework, the risk of a conversion dip during cutover, and the vendor exit terms. A case that hides these does not survive contact with a finance team that has been burned before.
Put the switching cost in the case yourself, before someone else finds it. A case that names its own risks and still clears the hurdle is far stronger than one that looks flawless until the first hard question. You are not trying to make the number as large as possible. You are trying to make it as defensible as possible.
A one-page structure you can defend
Keep the case to a page a reader can hold in their head. State the outcome metric and its current baseline. State the expected change as a range, with the mechanism that produces it. Total cost, including the switching cost and the parallel-run period. The payback period, and the sensitivity: what has to be true for the case to hold, and what breaks it. Then the honest downside, and what you would do if the estimate came in low.
If you can fill that page with numbers you can source rather than numbers you hope for, you have a business case. If you cannot fill it yet, you have found the measurement work that has to come first, which is itself a useful result. Either way you leave the exercise knowing something you did not know before, which is more than most decks deliver.