Module 5

Building the Business Case

How to quantify ROI for payment optimisation, sell infrastructure changes internally, and get budget approved

---

Why Payment Infrastructure Changes Stall: The Three Conversations

Payment infrastructure improvements often stall not because they lack merit, but because different stakeholders speak different languages. The CFO wants cost reduction and working capital impact. The CTO wants technical debt elimination and operational reliability. The Board wants competitive positioning and growth enablement. The CFO does not care about code quality. The CTO does not care about basis points. The Board cares about both but needs translation into business impact.

Building a successful business case means having three separate conversations with three different stakeholders, each using their native language and business logic. This module teaches you how to structure and win each conversation.

A payment infrastructure project that cannot be explained to finance as ROI is not actually a business problem. It is an engineering preference.

Conversation One: The CFO Talk (Cost and Margin)

The CFO speaks in terms of cost per transaction, effective rate, total cost of ownership, and payback period. She cares about moving the effective rate from 2.7 percent to 2.4 percent. She cares about working capital freed up by faster settlement. She does not care about orchestration layers or reconciliation automation from a technical standpoint. She cares only about the financial impact.

Your pitch to the CFO: "We are currently paying an effective rate of 2.7 percent on 100 million in annual transaction volume. That is 2.7 million in annual costs. A single-processor consolidation or multi-processor routing strategy could reduce that to 2.4 percent through better auth rates and lower interchange. That is 300,000 in annual savings. Implementation costs are 150,000, so payback is six months. Additionally, faster settlement reduces our working capital requirement by 500,000, which improves free cash flow immediately."

The CFO speaks ROI and payback period. Give her both. She also thinks in terms of ongoing cost vs. one-time cost. One-time costs are investments. Ongoing costs need to be trimmed from budgets. Make this distinction clear in your proposal.

Conversation Two: The CTO Talk (Reliability and Technical Velocity)

The CTO speaks in terms of mean time to resolve (MTTR), technical debt, code complexity, and engineering hours spent on payments infrastructure. She cares about the fact that your current multi-processor setup requires 40 hours per week of engineering time on reconciliation, incident response, and vendor management. She wants to reduce that. She also cares about vendor lock-in and architectural flexibility. She does not care about basis points unless you translate that into engineering cost.

Your pitch to the CTO: "We spend 40 hours weekly on payments operations: reconciliation, incident response, and vendor management. A consolidation to a platform with built-in reconciliation and fallback routing would cut that to 10 hours weekly. That frees 30 hours per week (1,560 hours per year) for feature development. If we value engineering time at 150 per hour, that is 234,000 in productivity gains. Plus, having a single integration point reduces production incidents by 70 percent, lowering our MTTR from 4 hours to 30 minutes on average."

The CTO thinks in terms of engineering hours saved and system reliability. Give her both. She also cares about flexibility and architectural choices. If your proposal reduces flexibility (for example, switching from multi-processor to single-processor loses the ability to route selectively), flag that explicitly. She might accept the tradeoff if the reliability and operational savings are large enough, but do not surprise her.

Conversation Three: The Board Talk (Growth and Competitive Positioning)

The Board thinks in terms of market positioning, competitive advantage, and customer experience. It cares about the fact that competitors support local payment methods and we do not, which costs us conversion in Europe. It cares about the fact that a rival processor platform can settle funds to customers within 24 hours and we take three days, which affects seller retention in our marketplace. It does not care about the technical details. It cares about what this means for growth and customer satisfaction.

Your pitch to the Board: "Today we support card-only payments in Europe, which limits our conversion against competitors who support local methods. A multi-method strategy would increase checkout conversion by 8 percent, equivalent to 12 million in incremental annual revenue. Additionally, implementing real-time settlement for sellers would improve retention by 3 percent, saving 500,000 in monthly revenue churn. Total project cost is 500,000, payback is three weeks."

The Board thinks in terms of revenue impact, customer retention, and competitive positioning. Give her all three. She also thinks in terms of timeline to payback. A project with three-week payback gets approved quickly. A project with three-year payback gets scrutiny.

---

ROI Frameworks for Payment Optimisation Projects

Different payment optimisation projects have different ROI drivers. Understanding which ROI lever to pull for your specific project determines what business case to build. Let's examine the major levers.

Authorisation Rate Improvement

Every one percent improvement in authorisation rate increases total transaction success by that amount. The value depends on your profit margin. For a $100 transaction at 30 percent margin ($30 profit), a one percent improvement represents $0.30. Across a million transactions, that is $300,000. For a payment processor itself, this translates directly to revenue. For a merchant, it translates to revenue.

Authorisation rate improvements come from several sources: multi-processor routing (moving transactions to processors with higher auth rates in specific corridors), local acquiring (5 to 15 percent higher auth rates than cross-border), payment method diversification (enabling lower-decline payment methods like wallets or bank transfers), and 3D Secure optimisation (reducing false positives).

To calculate auth rate improvement ROI: (Current auth rate - New auth rate) multiplied by annual transaction volume multiplied by average transaction value multiplied by profit margin equals annual revenue impact. For example: (92% - 94%) times 50 million transactions times $50 average value times 30% margin equals $150,000 in incremental annual revenue. If the project costs $100,000, payback is eight months.

False Decline Reduction

False declines are distinct from actual fraud. They are legitimate transactions blocked by overly aggressive fraud detection. False declines cost more than actual fraud because you lose both the transaction and the customer. A customer who has a purchase declined gets frustrated and may never return. The customer lifetime value loss is often much larger than the fraud risk avoided.

False decline reduction comes from improving fraud detection machine learning (better models mean fewer false positives), enabling 3D Secure to verify transactions (reducing friction for legitimate customers), or delegating fraud detection to a vendor with better training data.

To calculate false decline reduction ROI: (Current false decline rate - New false decline rate) multiplied by annual transaction volume multiplied by average transaction value multiplied by customer lifetime value loss per false decline equals annual impact. For a SaaS company with $50 monthly subscriptions and 24-month lifetime value ($1,200), a one percent improvement in false decline rate from 2 percent to 1 percent saves: 1% times 10 million transactions times 0.1 (assuming 10 percent of transactions are false declines) equals 100,000 lost customers. Times 1,200 lifetime value equals $120 million in customer value saved. Even if this math is off by a factor of 10, it is the dominant ROI driver.

Settlement Speed Gains

Settlement speed affects working capital. If your business receives payments from customers but settles funds to your processor or to sellers on T+2 (two days later), you have two days of negative working capital. That capital has to come from somewhere, typically an operating line of credit or cash reserves. Faster settlement frees working capital and reduces borrowing needs.

To calculate settlement speed ROI: (Current settlement days - New settlement days) multiplied by daily transaction volume multiplied by average transaction value multiplied by cost of capital (borrowing rate, typically 5 to 8 percent annually) equals annual interest savings. For example: (2 days - 0 days) times 500,000 transactions times $50 value equals $50 million in daily flow. Times 6 percent cost of capital equals $3 million in annual interest savings. If the project costs $500,000, payback is two months.

Chargeback Reduction

Chargebacks are the direct cost of payment fraud, buyer's remorse, or merchant error. A chargeback typically costs the merchant $100 to $500 in direct chargeback fees plus processing costs. If your chargeback rate is 0.5 percent and you process 100 million in annual transactions, that is 500,000 in chargebacks at average value $100 each, or $50 million in revenue generating chargebacks. At 0.3 percent average chargeback cost per transaction (fees plus dispute resolution), that is $300,000 in annual chargeback cost.

Chargeback reduction comes from better address verification (AVS), 3D Secure verification, or chargeback management services that automate dispute response. Reducing chargeback rate from 0.5 percent to 0.3 percent saves: 0.2% times 100 million transactions times average chargeback cost, which is $200,000 directly.

Interchange Optimisation

Interchange is the fee that card networks charge for processing transactions. It varies by transaction type, card type (debit vs. credit), and whether a transaction is domestic or cross-border. A typical credit card transaction carries 1.5 to 2.5 percent interchange. A debit transaction is 0.5 to 1 percent. A corporate card is 2.5 to 3 percent. Cross-border is 2.5 to 4 percent.

Interchange optimisation comes from several sources: moving eligible transactions to debit rails (lower interchange), using cards with lower interchange rates (corporate cards), or negotiating volume-based interchange reductions with processors or networks.

To calculate interchange optimisation ROI: assume 40 percent of your transactions are eligible to move from credit to debit. That saves 1 percent in interchange (difference between credit and debit). On 100 million in annual transaction volume, that is: 0.4 times 100 million times 0.01 equals $400,000 in savings. Often this requires enabling debit-specific payment methods or UI optimizations that steer customers toward debit. The project might cost $150,000, making payback four months.

Multi-Rail Routing Optimisation

Multi-rail means routing transactions across different payment rails and processors based on transaction characteristics. Card transactions might go through a card processor. ACH bank transfers through an ACH processor. Real-time payments through an RTP network. Each route has different costs, speeds, and conversion rates. Smart routing chooses the route that optimises for your specific business objective (lowest cost, fastest settlement, highest conversion, etc.).

To calculate multi-rail routing ROI: quantify the value of moving 20 percent of transactions (assume 20 million transactions) from expensive card rail to cheaper ACH rail, saving 1 percent in effective rate. That is 20 million times $50 times 0.01 equals $10 million in savings. Add conversion uplifts from expanding payment methods (5 percent of customers decline to pay with cards but pay easily with ACH or wallets), which adds 2.5 percent to transaction volume. The project costs $300,000, payback is less than a week.

---

Building a Payment Business Case Document: Structure and Content

A payment business case document has a specific structure that works across audiences. Follow this template and you will avoid the common pitfalls that cause projects to stall in review cycles.

Executive Summary (One Page)

The executive summary must be self-contained and answer three questions: what are we proposing, why do we care, and how much will it cost/save? Use this template: "We propose [specific change to payment infrastructure]. This change will [specific business outcome]. The investment is [cost] with payback in [timeline] and annual net impact of [annual savings/revenue]."

Example: "We propose consolidating from three card processors to two, with routing optimisation based on transaction characteristics. This change will reduce our effective payment rate from 2.7 percent to 2.4 percent and improve settlement speed from T+2 to next-business-day. The investment is $150,000 in integration and migration. Payback is six months. Annual net impact is $300,000 in cost savings plus $500,000 in working capital freed."

The executive summary needs to be written for multiple audiences. Do not bury technical details. Do not use payment jargon that only engineers understand. Use simple business language.

Current State Analysis (Two to Three Pages)

The current state analysis documents what you are doing today and what it costs. Include: list of current processors and payment methods, transaction volumes by processor, cost breakdown by processor (fees, integration maintenance, reconciliation tools), settlement timing by processor, reliability metrics (uptime, MTTR), and engineering hours spent on payments operations.

This section makes the problem visible. Many stakeholders do not know how much the company is currently spending on payments or what the operational burden is. Making it visible forces them to confront the status quo cost. Use tables and charts to make the complexity tangible. Show that you are paying three different processors to handle card transactions when one could handle most of them. Show that you spend 40 hours weekly on reconciliation. Show that settlement takes two to three days.

Proposed Changes (Two Pages)

The proposed changes section explains what you are changing and why. Do not describe the change at the technical level. Describe it in terms of business impact. Instead of "implement dynamic routing using processor selection rules," say "route transactions to the processor with the highest auth rate for that transaction type and geography, reducing false declines."

Include a "before and after" comparison table. Show current state on the left (current processor count, settlement timing, effective rate, auth rate, engineering hours), and proposed state on the right. The table makes the delta visible.

Financial Model (Two to Three Pages)

The financial model quantifies the impact. Use a year-by-year projection for three years. Year one typically shows large costs (implementation, migration, integration) and emerging benefits. Years two and three show benefit realisation as volume grows or opportunities are fully realised.

Structure the model with clear rows: implementation cost (one-time), ongoing operational cost (annual), processor fee savings (annual), working capital freed (one-time), and revenue uplift from conversion improvements (annual). Sum to show annual net impact and cumulative three-year impact.

Example structure:

Implementation Timeline (One Page)

The implementation timeline shows when work happens and when benefits realise. Typical timeline for processor consolidation: Month one to two, set up new processor and run parallel processing. Month three to four, migrate customer base. Month five, shut down old processor. Benefits start realising in month five (full payoff of new processor fees) and accelerate in month six as settlement timing improvements take effect.

Include key milestones and go/no-go decision points. If parallel processing reveals auth rate degradation or other problems, you might decide to stay with the old processor or extend the parallel period. Build in flexibility.

Risk Assessment (One to Two Pages)

Every payment project has risks. Identify them explicitly, score them (probability and impact), and describe mitigation. Common risks include: new processor has lower auth rates than expected (mitigate with extended parallel period and performance guarantees in contract), settlement delays from migration (mitigate with staggered customer migration), integration complexity exceeds estimates (mitigate with external vendor help), customer confusion during migration (mitigate with clear communication plan).

Risk assessment builds credibility. It shows you have thought through what could go wrong and have plans to handle it. Do not pretend projects have no risk. They do. Acknowledging risk makes your proposal more believable, not less.

---

Handling Objections: The Three Most Common Arguments Against Change

Your business case will encounter resistance. Understanding the most common objections and how to counter them saves time and increases your success rate.

Objection One: "Payments is Working Fine. Why Change?"

The objection is usually accurate. Payments probably is working fine in the sense that transactions are processing and customers are not complaining loudly. But "working" does not mean "optimal." The response is to make the hidden costs visible.

Counter: "Payments is working from a user perspective, but our effective rate is 2.7 percent, which is above market. Our settlement takes two to three days, which ties up working capital. We spend 40 hours weekly on reconciliation and incident response. The status quo is working, but it is expensive. A one percent improvement in effective rate adds $100,000 to margin. That is real money, not theoretical."

Quantify the status quo cost and compare it to the change cost. The status quo always has a cost. You are not comparing change to no cost. You are comparing change cost to status quo cost. Make that clear.

Objection Two: "Too Risky to Change. What if Something Breaks?"

The objection reflects real concern about payment continuity. Payment systems are the lifeblood of the business. A payment outage is a revenue outage. The response is to show that you have thought through risk mitigation and that the benefit justifies the risk.

Counter: "We understand the risk. That is why we have designed the migration in phases. Phase one is parallel processing with the new processor while we keep the old one active. We run both for 30 days and monitor auth rates and settlement. If anything is degraded, we stop. Phase two is staged customer migration, not a flag day cutover. We move 10 percent of customers per week, monitoring closely. Phase three is sunset of the old processor after 60 days of all-new-processor operation. At each phase, we have go/no-go decisions. The risk is managed."

Phased migration is lower risk than big-bang migration. Show that you have structured the project for risk management, with go/no-go decision points. This converts the risk concern into risk mitigation planning.

Objection Three: "We Do Not Have the Team to Handle This. Too Complex."

The objection is often from the CTO, worried about engineering bandwidth. The response is to separate project delivery from ongoing operations, and to propose external help for implementation.

Counter: "We understand the team is at capacity. That is why we propose bringing in [specific vendor or consulting firm] to run the implementation. They handle the integration and migration. Our team provides oversight and testing, not the full engineering lift. Post-implementation, our team picks up operational support, but we have built in automation to reduce ongoing burden. Net result: 40 hours per week of operational time frees up, which more than offsets the project capacity cost."

Propose external help for one-time implementation cost. Show the ongoing operational relief. Most CTOs will accept external help if it frees internal resources long-term.

---

Getting Budget Approved: The Minimum Viable Business Case

Not all business cases need to be lengthy. Often a minimum viable business case (a few pages with key numbers) is sufficient to unblock a decision. The key is to include the three things decision makers care about: payback period, annual net impact, and risk score.

Minimum viable business case template: one-page executive summary (what, why, cost, payback), one-page current state (what we spend today), one-page proposed state with financial impact (before/after comparison and annual net benefit), and one-page risk and timeline (when benefits realise, what could go wrong). Total: four pages.

This can get approval in committee meetings and move projects from "interesting idea" to "funded project." Longer business cases are useful for complex decisions, but do not assume longer is always better. Sometimes conciseness is what unblocks decisions.

---

Payment Business Case Case Studies: What Good Looks Like

Three real examples of successful payment business cases, anonymised for confidentiality.

Example One: SaaS Company, Recurring Billing Optimisation

Problem: Involuntary churn from failed payments was 5 percent annually (losing $500,000 in revenue). Current setup used a basic processor without dunning (automated retry) capability. Current effective rate was 3.2 percent. Business case proposed switching to Stripe Billing or Zuora with sophisticated dunning, multi-method retry, and international compliance.

Financial impact: dunning reduces involuntary churn from 5 percent to 2 percent, saving $1.5 million annually. Effective rate improves from 3.2 percent to 2.8 percent on growing volume (saves $50,000 annually on base volume, scales as volume grows). Implementation cost $100,000. Payback: one month. The project was approved immediately.

Example Two: Marketplace, Multi-Processor Consolidation

Problem: Marketplace was using five processors to support different payment methods and geographies. Integration and reconciliation overhead was 60 hours weekly. Effective rate was 2.9 percent (high for a platform). Business case proposed consolidating to two processors with multi-method support through orchestration.

Financial impact: effective rate improves from 2.9 percent to 2.4 percent on $200 million in annual volume, saving $1 million annually. Engineering time reduces from 60 hours to 20 hours weekly, freeing 2,080 hours per year (worth $312,000 at fully-loaded engineering cost). Implementation cost $500,000. Payback: four months. Approved by both CFO and CTO.

Example Three: Ecommerce, International Expansion with Local Payment Methods

Problem: Company was card-only globally, which limited conversion in Europe (iDEAL, Bancontact) and APAC (local methods and wallets). Current conversion was 2 percent. Adding local payment methods was expected to increase conversion to 2.7 percent. Business case proposed adding 8 local payment methods across 6 major markets.

Financial impact: conversion uplift of 0.7 percent on $50 million in current volume equals $350,000 in incremental revenue per year. Effective rate improves 0.15 percent (local methods typically have better rates), saving $75,000 annually. Implementation cost $400,000. Payback: 16 months. Approved because incremental revenue exceeded cost within two years.

---

Common Financial Modeling Mistakes to Avoid

Payment business cases often fail because of modeling errors. Avoid these common pitfalls.

Overstating Implementation Cost Savings

Many proposals claim that engineering time will be cut to zero, or that all current processor fees will be eliminated. Neither is true. New processors have their own quirks and support needs. New implementations always require some ongoing maintenance. Model conservatively. If you think time will be cut by 50 percent, assume 30 percent in the business case. Better to surprise upside than to promise savings that do not materialise.

Forgetting to Account for Velocity Growth

Business cases often assume static transaction volume. But volume typically grows. If you are a high-growth company, transaction volume might double in year two. That doubles the benefit of a 0.1 percent effective rate reduction. Include volume growth assumptions in the financial model, even if they are conservative.

Not Including Ongoing Operational Cost

A business case that shows implementation cost but not ongoing operational cost is incomplete. New systems have support costs, maintenance costs, compliance costs. Model these explicitly. They reduce net benefit and should be part of the ROI calculation.

Confusing One-Time and Recurring Benefits

Working capital freed is a one-time benefit. Processor fee savings is recurring. Discount rates and payback calculations need to reflect this distinction. A $500,000 one-time working capital benefit is valuable but should not be projected as $500,000 benefit in perpetuity.