Payment Success Rate

A shopper clicks pay, the bank declines the first card attempt, and the shopper retries and succeeds. An attempt-based rate counts one failed and one successful attempt, while an order-based rate counts one paid order, so the two numbers describe different experiences.

Stripe documents acceptance analytics and Adyen explains why an acceptance rate alone can miss steps in a checkout, but their platform-specific metrics are examples, not a universal standard for every payment method or processor. Choose the stage first: authorisation, capture or a completed paid order, because a merchant may need all three views.

For an attempt-based measure, divide successful eligible attempts by total eligible attempts in the same period, after defining eligibility so that test transactions, duplicate network messages and customer-abandoned checkouts sit in separate categories. Suppose 9,400 of 10,000 eligible attempts succeed at the chosen stage; the rate is 94%.

A bank authorisation can later be reversed or never captured, so do not call it settled revenue without checking the later events, and reconcile processor events to orders and bank receipts because an accepted API response does not by itself prove cash arrived. Some payment methods follow different sequences from cards, so state which rails the dashboard covers.

Measure latency and failed callbacks as well, since a payment may succeed while the store fails to confirm the order, and check checkout errors before the gateway because a customer who never reaches a payment attempt is invisible in this metric. Separate customer retries from new orders, because high retry volume can make attempt success look worse even when many customers eventually pay, and track order-level paid conversion alongside attempt success to see the commercial outcome.

Segment by payment method, country, currency, issuer and device where sample size allows, since one aggregate can hide a route-specific failure. Declines may reflect insufficient funds, expired credentials, fraud controls, authentication failures or technical outages, so treat decline codes as clues, not complete knowledge of a customer's intent or a bank's decision.

A fraud rule may reduce acceptance while protecting the business, so do not remove a safeguard purely to lift one percentage, and look at disputes and chargebacks later because a high initial approval rate can be costly if risky payments are accepted. When retries are permitted, follow provider and network guidance, since repeated attempts without regard to rules can worsen results.

For subscriptions, distinguish recovered invoices from permanently lost customers, because a failed renewal is not immediately involuntary churn. Alert on sudden changes with enough context, because small denominators can make a single failure look like a crisis, and compare equivalent periods since a new market launch or seasonal traffic shift can alter payment-method mix.

Document any processor-routing change so a historical comparison can isolate the affected route, use safe authentication flows and current security requirements, and never ask customers to send card numbers by email or ordinary chat when a payment fails; provide an approved secure update route instead. Estimate the value of improvement using paid orders and contribution rather than approvals, test checkout changes against real customer outcomes and support data because a higher rate can coexist with more complaints, and report the numerator, denominator, stage and exclusions so another team can reproduce a figure that pinpoints friction without confusing an attempt, a customer order and cash collected.