Payment Attempt

A payment attempt is one try at getting a payment through. It covers every outcome: the ones that work, the ones the bank turns down, and the ones that fail on a technical error before anyone gets an answer. Counting only the wins hides the shape of the problem. A business that looks at attempts rather than sales can see how much trade it loses between the point where a shopper decides to buy and the point where money moves.

The measure has grown more useful as checkouts have grown busier. A single order often involves several attempts. A card is declined, so the shopper reaches for another. A network check times out and the page retries on its own. A saved card fails and the customer types the details in by hand. Each of those is a separate logged transaction in the records, even though the customer lived through one purchase. Reading the run of rows, not each row alone, is what turns a raw log into something anyone can act on.

Orders And Attempts Are Different Counts

An order is a business event. An attempt is a technical one. The ratio between them is a health measure worth watching on its own. Where a typical order takes 1.1 attempts the checkout is behaving. Where it takes 1.8, something specific is wrong, and the cause is usually narrow: one card type, one market, one acquirer, one kind of device. Averages bury all of that, so cutting the data by decline code, country and card product is what brings it back into view.

Four Ways An Attempt Ends

An approval means the bank has agreed the amount. A soft decline asks for another try with more detail, often an identity check. A hard decline says do not ask again, and repeating it wastes an attempt and can draw the bank's attention. The fourth outcome does the real damage, because it is no answer at all. A gateway timeout leaves the payment in an unknown state, and how a business handles that case separates a sturdy checkout from one that sometimes charges people twice.

Retry Rules Built On Reasons, Not Counts

Trying a failed payment again is normal and often sensible. Doing it without reading the reason is not. A card reported lost will not start working because it was asked four more times, and repeated requests against the same card can look like card testing to the bank. Scheme rules cap how often a request may be repeated, and the caps differ by network. So a retry policy needs a rule per decline reason, not one blanket setting. Payments sitting in a queued transaction state deserve the same care.

Where An Identity Check Costs Attempts

Challenging a payment adds a step, and a share of shoppers walk away at that step. That is a real trade, not a flaw in the design. The technical standards let some lower risk payments skip the full check, and one route rests on risk analysis of each payment, which applies where a firm's fraud rate sits under a set level. The figures and conditions are written into the rules, are revised from time to time, and differ outside the UK and the EU. The version in force locally is the one to work from.

Stored Cards Fail With Nobody Watching

Repeat billing leaks money quietly. When a saved card fails there is no shopper on the page to reach for another one, so the attempt has to be planned instead of prompted. Timing carries real weight here, and a retry on payday lands better than one at midnight on the same date. Card details also go stale between charges. An unscheduled credential on file flag tells the bank the customer agreed to this kind of charge, which helps the request read as expected rather than odd.

Counting It Honestly

Attempts per order shows friction. Approval rate per attempt shows how banks are behaving. First-attempt success shows how good the opening request was. Those three move on their own, and a shift in one can flatter another, so watching a single number is how teams talk themselves into the wrong fix. Add conversion rate to the same view, since a checkout that challenges less often will approve fewer payments in raw count while selling more. The bounce rate on the payment step rounds the picture out. A baseline set before any change is what lets you tell a real gain from week-to-week noise.

Timing After The Answer

Speed shapes how many attempts a shopper is willing to make, and it has a legal edge once money is moving. UK payment rules set out how fast a payment must reach the receiving firm, and regulation 86 gives the standard timetable. Those timings sit after approval, not during it, and they still shape whether the customer believes the payment worked.

Making The Numbers Useful

Log every attempt with the reason, the route and the time, all tied to one order reference. Build the retry policy from decline codes, not a fixed count. Handle the no-answer case with a status check rather than a blind retry. Test other routes on a share of traffic instead of picking one on a hunch, which is what smart routing is designed to help with. And look hard at the checkout itself, because a large share of failed attempts are caused before a bank is ever asked. This guide to reducing abandonment at the payment step covers that ground.

‍