Anyone actually tracking their payment decline rate?

Shopify Discussion
, , , ,
1

Anyone actually tracking their payment decline rate?

Just launched this month so my volume is tiny, but I went digging into the payments side out of curiosity and I’m not sure what I’m looking at. A chunk of attempts are failing at authorisation and some of them look like they were real customers who wanted to buy.

Two questions for people further along:

  1. Do you track this at all, or does anyone at your business own that number? I can’t tell if I’m worrying about something everyone ignores or missing something obvious.
  2. What’s a normal decline rate for a European store selling cross-border? I have no baseline to compare against.
2

Hi @Guidointoecommerce Welcome To Shopify Community So Tracking decline rate is genuinely worth doing early rather than dismissing it as normal noise, since a chunk of “failed” authorizations being real customers who wanted to buy means you’re losing sales silently without seeing it in your conversion funnel the way an abandoned cart would show up. For cross-border European stores specifically, decline rates tend to run higher than domestic-only stores because of 3D Secure/SCA requirements under EU regulations, banks sometimes decline cross-border transactions that don’t pass additional authentication smoothly, so a somewhat elevated rate compared to a single-country store isn’t automatically alarming. As a rough general benchmark, most healthy ecommerce stores sit somewhere in the low-to-mid single digits for decline rate, anything trending noticeably higher than that consistently is worth digging into (check if it’s concentrated on specific card types, countries, or payment methods, that pattern usually points to the actual cause faster than the raw percentage alone). Hope this helps solve your problem, and if it does, don’t forget to like and mark it as the solution. Thank you!

3

I would track it, but I would not use a single “normal decline rate” yet with a tiny sample.

Shopify now exposes Failed payment attempts and Payment authorization rate (successful payments divided by unique payment attempts) in Analytics. I’d use that authorization rate as the top-line metric, then segment the failures by destination country, payment method and the decline message.

For the first review:

  1. Open Orders → Abandoned checkouts and expand each payment event in the Timeline.
  2. Record only the non-sensitive fields: country, payment method, gateway, time and the message/decline category. Do not collect card details.
  3. Separate 3D Secure/authentication failures from issuer declines and repeated retries.
  4. Look for a cluster. One country, one payment method or one repeated message is much more actionable than the overall percentage.

Shopify notes that many issuer declines are generic, so a small cross-border store can look “bad” from only a few attempts. A stable benchmark becomes useful only after you have enough unique attempts and can compare like-for-like segments.

Are your failures concentrated in one country or payment method, or spread across everything?

4

Thanks, that’s more useful than anything I’ve found searching. And honest answer: too small a sample to see a cluster yet. Handful of failures, spread across a few countries, nothing I’d read anything into.

So let me ask you the thing I actually can’t work out. When you segment the failures — do you split soft declines from hard ones, and if so what do you do with the soft ones? A do_not_honor or an insufficient funds response is a completely different problem from an expired card, but Shopify surfaces them in the same bucket as far as I can tell.

And on the 3DS side: when authentication drops off rather than fails outright, do you count that as a decline or as abandonment? Feels like it lands in a gap between the two metrics and quietly disappears.

5

Yes — I would separate them, but by next action, because Shopify does not present the Admin events as a neat soft/hard taxonomy.

Retry or alternate-payment candidate

  • do_not_honor: a generic issuer refusal, not proof that the card is permanently bad. One customer-initiated retry, contacting the bank, or another payment method is more appropriate than repeated automatic retries.
  • insufficient_funds, call_issuer, or a processing error: retry later or use another method.

Customer must correct/replace the payment details

  • expired card, invalid number/expiry, incorrect CVC or postal code.

Stop or review rather than retry blindly

  • fraud/card-testing/high-risk, unsupported payment method, or merchant-account errors.

For 3DS I would keep two separate rows:

  • An explicit AUTHENTICATION_FAILED / AUTHENTICATION_REQUIRED or “3-D Secure authentication failed” payment event = 3DS failure, not an issuer decline.
  • The shopper starts the challenge but leaves before Shopify receives a rejected payment event = 3DS abandonment/drop-off. I would not force that into the decline metric. Keep a separate 3DS_STARTED_NO_RESULT category.

Shopify says an actual payment try is recorded in the abandoned-checkout Timeline. So if there is no final payment event, the cleanest operational treatment is abandonment; if your gateway portal shows a challenge was started, use that portal evidence to populate the separate 3DS-drop-off row.

Are you using Shopify Payments or a third-party gateway? That determines whether the provider portal can expose the missing 3DS state.

6

Shopify Payments, so no separate portal — which makes your point about the missing 3DS state exactly the problem. The evidence lives somewhere I can’t see.

Taxonomy by next action is a better frame than soft/hard, I’ll use that. Thanks.

One thing from my side, since it’s the bit I know: everyone stops at authorisation, but there’s a second leak at settlement. The FX conversion applied when your payout currency differs from your transaction currency never appears as a line item, it’s baked into the rate. On a cross-border store that’s often larger than the decline loss and nobody measures it.

Do you do this for clients, or is it your own store? Asking because it’s rare to find someone who separates 3DS drop-off from issuer declines, and I’d like to know how you got there.

7

Good catch on settlement FX — I would keep that as a second leakage layer, separate from authorization. Otherwise a store can improve its decline rate while still losing more at payout conversion.

I don’t run the store. I’m an independent ecommerce operations operator, and I use the same exception-workflow principle across checkout, catalog and migration QA: event → next action → owner → evidence → outcome. That is what led me to separate issuer declines, explicit 3DS failure and 3DS drop-off instead of forcing them into one rate.

Yes, I can turn this into a small fixed-scope paid review from a redacted export — no Shopify Admin access and no cardholder data. The output would be an action-based event taxonomy, a missing-state/FX exception sheet and a simple weekly owner checklist.

If that would be useful, roughly how many payment attempts and payout currencies would the first review need to cover?

8

Honestly, my own store is three weeks old, a handful of attempts and one payout currency. There’s nothing there worth reviewing yet, so I won’t waste your time on it.

But the reason I’m asking these questions is broader. I’m exploring whether there’s something to build here for European merchants in the €5–50M range, where declines, settlement FX and reserve terms all leak at once and nobody sees any of the three. My background is FX and payments; yours is clearly the operational side. Might be worth a proper conversation.

How many of these reviews have you actually sold, and what did the merchants react to most?

9

Zero — I haven’t sold this specific payments review yet, and I don’t want to imply a case study I don’t have.

I’m validating it from live merchant problems. The strongest response so far has not been to a “payments dashboard”; it has been to turning opaque events into a next-action exception view: issuer decline, 3DS failure, 3DS drop-off, owner, evidence and outcome. Your settlement-FX and reserve point adds the commercial layer that was missing from my first frame.

So your three-week store is not the right paid test, and I agree not to force it. But the €5–50M hypothesis is worth a proper conversation because it may be a different buyer and a different product: a reconciliation/control review for payments, finance and ecommerce ops, not a small-store decline report.

I’m open to comparing notes. The first thing I’d want to understand is: in the merchants you know, who is supposed to own all three leaks today — payments, finance, or ecommerce operations — and what do they currently receive as evidence?

10

I’d track it, especially once the store has enough volume for the pattern to mean something. A raw decline percentage is useful, but I’d want to know whether certain countries, payment methods, devices, or products are responsible for most of it before changing anything.

I tend to look at ecommerce data the same way with SEO. A dashboard can show you that something is wrong, but the useful part is knowing what actually deserves attention first. That’s one thing I’ve liked about SiteGuru. It doesn’t just dump a list of SEO issues on you, it helps prioritize what to work on.

For payment declines, I’d want that same approach. If 80% of the failed attempts are coming from one payment method or country, that’s a much more actionable finding than simply knowing your overall decline rate.

11

With a handful of attempts I would not read much into the rate yet, it only starts meaning something after a few hundred unique attempts. One thing nobody mentioned, on cross border EU a big share of card declines is better avoided than fixed, by offering local payment methods. Dutch customers expect iDEAL, Belgians Bancontact, Poles Przelewy24 or BLIK, and in Central Europe plenty of people still prefer bank transfer or COD over any card. Every order through a local method is a 3DS failure that never happened, in our experience that moves cross border conversion more than any decline analysis.

13

On the local payment methods point, that is the part of this thread I would act on first, and it has an awkward consequence for measuring any of the rest.

One correction to something assumed further up. The suggestion to open each abandoned checkout and record the country, method and decline message by hand is more work than it needs to be.

I went looking to confirm that Shopify does not expose this in a structured form and the schema says otherwise.

The Admin GraphQL API carries an OrderTransactionErrorCode on the order transaction, 47 values, and it is already close to the by-next-action split described above.

DO_NOT_HONOR, CALL_ISSUER, INSUFFICIENT_FUNDS and PROCESSING_ERROR sit apart from EXPIRED_CARD, INCORRECT_NUMBER, INVALID_CVC and INCORRECT_ZIP, and apart again from CARD_TESTING and FRAUD_SUSPECTED.

AUTHENTICATION_FAILED and AUTHENTICATION_REQUIRED are their own values, so a 3D Secure failure is already distinguishable from an issuer decline without inferring anything from a message string. It is a field to read rather than a taxonomy to build.

The 3DS drop-off is the real hole and it is worse than a reporting gap. There is no value in that enum for a shopper who starts the challenge and leaves, and there cannot be one. No transaction is created, so there is no row to carry an error code.

That state is missing from the data model, not from the reporting, which is why it does not appear however hard you look for it in Admin. On Shopify Payments there is no separate gateway portal to recover it from either, so for that setup the number does not exist anywhere rather than existing somewhere inconvenient.

Which is what makes the local methods argument hard to prove. Moving a Dutch buyer to iDEAL removes a 3DS challenge that would otherwise have had a chance to be abandoned.

The gain is real and the one measurement that would demonstrate it is the one that cannot be produced.

So it will not appear as fewer 3DS failures. It appears as authorisation rate rising with no matching fall in any decline code, and anyone watching the decline breakdown will see the improvement arrive from nowhere and attribute it to something else.

Worth knowing before that happens rather than after.

14

The “taxonomy by next action” point is what stands out here. An overall decline rate tells you something happened, but the useful part is knowing which failures deserve attention and what the next action should be.

I’m building VedaSuite around that broader idea for Shopify operations — surfacing evidence-backed exceptions, showing why they matter, and prioritizing what actually needs attention instead of adding another dashboard.

Payments aren’t a dedicated VedaSuite module today, so I wouldn’t claim we solve decline/FX leakage yet, but your example is a very good fit for the model: issuer decline vs 3DS failure vs drop-off vs settlement leakage, each with evidence and a different action.

If you were designing this for larger merchants, would you rank these primarily by estimated financial leakage or by how recoverable the issue is?