Start with a consistent denominator
Before comparing approval rates, agree what each number represents. A checkout visit, a submitted payment, an authentication attempt, and an authorisation request describe different stages. A change in the customer or transaction mix can also change an aggregate rate without explaining the underlying cause.
For an acceptance review, map the events your systems and providers record. Identify which stages can be joined and where evidence is missing. Keep repeated attempts visible so a retry is not mistaken for a new customer or a new sale.
Separate the reasons for failure
Review whether the customer left before submitting, authentication did not complete, a risk control blocked the attempt, or an issuer declined the authorisation. Those outcomes raise different questions and usually involve different owners.
Where data is available, examine patterns by market, method, provider, device, and recurring versus first-time payment. Ask providers to explain their decline categories and any limitations in the reporting. A code is a piece of evidence; it is not always a complete explanation.
Test with a balanced view of performance
A proposed change to authentication, routing, or risk rules needs more than an approval-rate target. Agree what will be observed for fraud, disputes, cost, and customer friction, as well as completed payments. Establish who can approve a change and when it should be stopped or reconsidered.
The consultancy output is a prioritised investigation and test plan: a question, the supporting evidence, the team or provider responsible, and a way to assess the result. That gives the business a more useful next step than a broad promise to improve acceptance.
Ask your team to explain the path from payment attempt to completion, with a consistent definition and owner for each failure category.
Further reading: Provider perspective: Stripe Radar