Key points of this lesson, in order.
Measuring product success: SLAs, KPIs and the numbers that matter
What you will learn
Your objective. By the end of this lesson, you will be able to explain measuring product success: slas, kpis and the numbers that matter and apply it to a real banking scenario.
Why it matters. For a business analyst, the metrics are requirements.
Chapter objective: How a payments product is positioned, priced and measured
Key learning points
- Customer experience measurement
- Authorisation approval rate
- Continuous SLA measurement
- Monthly cost per payment
- Operations dashboard metrics
- Further reading and sources
Key terms
Authorisation: Approval by the issuer for a card transaction to proceed, confirming the card is valid and funds or credit are available.
Scheme fee: A fee charged by a card scheme to issuers and acquirers for using its network, rules and brand. Scheme fees cover processing, clearing, compliance and fraud services.
Exception: A payment that cannot be processed normally and needs manual handling, investigation or repair. Exceptions arise from missing data, failed screening, account errors or system faults.
Payment flow diagram showing Measuring product success: SLAs, KPIs and the numbers that matter.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Trace the card payment in this lesson through authorisation, clearing and settlement.
Use the four-party model and the stage timings in this lesson.
- What to do. State what happens at each stage, who pays whom, and when the merchant is actually credited.
Correct result. Authorisation holds the funds and returns a response code. Clearing sends the transaction in a batch file. Settlement moves the net amount between banks, and the acquirer credits the merchant after deducting interchange, scheme fees and its margin.
Why. A card payment is not one event. The customer sees it on Monday, the merchant gets it on Wednesday, and the difference is the clearing and settlement cycle.
Check your understanding
Practice question
Which of the following best describes measuring product success: slas, kpis and the numbers that matter?
Takeaway and next step
What to remember
A customer who makes one payment and never returns has had a bad experience, even if they never complained.
Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Go-to-market for a payment product: certification, pilot and launch".
Transcript and full text
Show transcript
A payment product is measured by the numbers that reflect the customer's experience, not by the numbers that are easy to collect. The most important metric is the straight-through processing rate, the percentage of payments that complete without manual intervention. A good retail payment product achieves an STP rate above 95 percent, and a good corporate product above 90 percent. Below 80 percent the operations team is drowning in exceptions, and the product is not working. The STP rate must be measured by corridor, by payment type, and by customer segment, because a single average hides the corridors that are failing. The authorisation rate is the equivalent metric for card payments. It is the percentage of authorisation requests that are approved, and it is the single most important number for a merchant. A one percent improvement in the authorisation rate is worth more than any fee reduction, because it is revenue the merchant would otherwise lose. The authorisation rate must be measured by issuer, by card type, and by channel, because the rate for a domestic debit card is very different from the rate for an international credit card, and the product team needs to know where the declines are happening. Service level agreements in payments are promises with penalties. A typical SLA for a payment service promises 99.9 percent availability, a maximum processing time of a defined number of seconds for an instant payment, and a maximum time to resolve an exception. The SLA must be measured continuously, and the measurement must be reported to the customer, not just kept internally. A product that promises 99.9 percent availability and delivers 99.5 percent has breached its SLA, and the customer is entitled to the service credit the contract promises. The cost per payment is the metric that decides whether the product makes money. It is the total cost of running the product divided by the number of payments, and it must include the scheme fee, the correspondent charge, the screening cost, the operations cost, and the technology cost. A product with a cost per payment of 50 pence that charges the customer 30 pence loses 20 pence on every payment, and no volume will fix it. The cost per payment must be calculated monthly, and the trend must be reported to the product owner. Customer metrics in payments are different from other products, because a payment customer who is unhappy does not complain, they leave. The net promoter score is less useful than the repeat usage rate, the percentage of customers who make a second payment, and the time to the second payment. A customer who makes one payment and never returns has had a bad experience, even if they never complained. The product team must track the repeat rate by segment, and must investigate the segments where it is low. The product dashboard is the tool that brings the metrics together. It must show the STP rate, the authorisation rate, the availability, the processing time, the exception rate, the cost per payment, and the repeat rate, each by corridor and by segment, and each with a trend and a target. The dashboard must be updated in real time, or at least daily, because a metric that is a month old is a history lesson, not a management tool. The requirements must state the metrics, the calculation, the source, and the refresh frequency for each one. For a business analyst, the metrics are requirements. Each metric needs a definition, a formula, a data source, a target, and an owner. The acceptance criteria must include a test where the metric is calculated by hand from the raw data and compared to the dashboard, to prove the dashboard is correct. Last reviewed 7 November 2026. Further reading: the Payment Systems Regulator market reviews; the European Central Bank payment statistics; the Bank for International Settlements payment statistics; the McKinsey Global Payments Report 2024.
A payment product is measured by the numbers that reflect the customer's experience, not by the numbers that are easy to collect. The most important metric is the straight-through processing rate, the percentage of payments that complete without manual intervention. A good retail payment product achieves an STP rate above 95 percent, and a good corporate product above 90 percent. Below 80 percent the operations team is drowning in exceptions, and the product is not working. The STP rate must be measured by corridor, by payment type, and by customer segment, because a single average hides the corridors that are failing.
The authorisation rate is the equivalent metric for card payments. It is the percentage of authorisation requests that are approved, and it is the single most important number for a merchant. A one percent improvement in the authorisation rate is worth more than any fee reduction, because it is revenue the merchant would otherwise lose. The authorisation rate must be measured by issuer, by card type, and by channel, because the rate for a domestic debit card is very different from the rate for an international credit card, and the product team needs to know where the declines are happening.
Service level agreements in payments are promises with penalties. A typical SLA for a payment service promises 99.9 percent availability, a maximum processing time of a defined number of seconds for an instant payment, and a maximum time to resolve an exception. The SLA must be measured continuously, and the measurement must be reported to the customer, not just kept internally. A product that promises 99.9 percent availability and delivers 99.5 percent has breached its SLA, and the customer is entitled to the service credit the contract promises.
The cost per payment is the metric that decides whether the product makes money. It is the total cost of running the product divided by the number of payments, and it must include the scheme fee, the correspondent charge, the screening cost, the operations cost, and the technology cost. A product with a cost per payment of 50 pence that charges the customer 30 pence loses 20 pence on every payment, and no volume will fix it. The cost per payment must be calculated monthly, and the trend must be reported to the product owner.
Customer metrics in payments are different from other products, because a payment customer who is unhappy does not complain, they leave. The net promoter score is less useful than the repeat usage rate, the percentage of customers who make a second payment, and the time to the second payment. A customer who makes one payment and never returns has had a bad experience, even if they never complained. The product team must track the repeat rate by segment, and must investigate the segments where it is low.
The product dashboard is the tool that brings the metrics together. It must show the STP rate, the authorisation rate, the availability, the processing time, the exception rate, the cost per payment, and the repeat rate, each by corridor and by segment, and each with a trend and a target. The dashboard must be updated in real time, or at least daily, because a metric that is a month old is a history lesson, not a management tool. The requirements must state the metrics, the calculation, the source, and the refresh frequency for each one.
For a business analyst, the metrics are requirements. Each metric needs a definition, a formula, a data source, a target, and an owner. The acceptance criteria must include a test where the metric is calculated by hand from the raw data and compared to the dashboard, to prove the dashboard is correct. Last reviewed 7 November 2026. Further reading: the Payment Systems Regulator market reviews; the European Central Bank payment statistics; the Bank for International Settlements payment statistics; the McKinsey Global Payments Report 2024.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.