After 9 years working on Shopify CRO, one diagnostic mistake I still see often is treating every reached-checkout-without-purchase session as a payment problem. It isn’t.
Here is the distinction I use.
Observable facts
• The customer reached checkout
• A payment attempt was or was not submitted
• Shopify recorded a decline, error, or completed order
• Device, market, shipping option, payment method, and timestamp
A hypothesis — not yet a fact
If someone reached checkout and did not purchase, possible causes include unexpected total cost, delivery timing, account requirements, payment friction, comparison shopping, or a simple interruption. “Payment failed” is only supported when there is an actual failed attempt or error event.
My diagnostic order is:
Split checkout exits into no payment attempt vs payment attempted but failed.
Segment both groups by device, market, payment method, new/returning customer, and discount use.
Review the customer behavior leading into checkout and the checkout events together.
Verify shipping, tax, discount, validation, login, and payment conditions before changing page design or adding urgency.
That first split matters. A store can have a healthy payment system and still lose buyers before they submit payment — or have a clear product page while one specific payment method fails.
What is the most common checkout pattern you are seeing: no payment attempt, a visible error, or a decline after submission?
Hi @Icey.Lane
This is a really good distinction. I’ve also seen cases where merchants assume there’s a payment issue when the customer actually drops off before completing the payment step.
Checking where the drop-off actually happens before changing the checkout experience can save a lot of unnecessary troubleshooting.
In my experience, unexpected shipping costs and delivery-related concerns are also common reasons customers leave before payment.
To your question, with the caveat that I come at this from provider documentation and decline data rather than from store analytics: the pattern I keep finding is that “decline after submission” is not a leaf node.
Your splits are all merchant side, device, market, method, new or returning, discount.
The decline branch has an issuer side dimension that never reaches a checkout report. The card networks return an instruction per transaction alongside the decline code, and the two do not always agree, so the same code can carry “retry later” on one charge and “do not try again” on another.
Grouped by code alone that difference disappears, and with it the difference between a card that will work tomorrow and one that never will.
The state I would add to your list: a payment that succeeded and was reversed afterwards.
A refund or a chargeback shows as a completed order on the day and is not revenue, and it never appears in a checkout funnel at all because by then the session is long closed.
Both of those move the fix off the checkout page, which is your underlying point rather than an argument with it.
Totally agree, and the data is split in two places.
Shopify’s abandoned checkouts gives you everyone who got far enough to leave an email. Your payment provider’s dashboard gives you every declined or failed attempt over the same window.
If you cross-reference the two, anyone in the first list who doesn’t appear in the second is your no-payment-attempt group. That’s the split you’re describing.
Definitely worth doing because the two groups need opposite responses. A decline is a retry and an alternate payment method. Never attempting is a cost or a trust problem further upstream.
The no-payment-attempt group is usually the one I’d investigate first. It’s easy to see a high checkout abandonment rate and immediately start blaming the payment gateway, when the customer may never have actually tried to pay. I’ve also found device and shipping option breakdowns useful here because a problem affecting one checkout path can disappear when you look at the overall conversion rate.
That issuer-side split is a useful addition. I’d keep a merchant-visible taxonomy rather than collapse everything into “payment failed”: no payment attempt; decline with a retryable instruction; decline that should not be retried; and an authorization that was later reversed.
The last state should stay separate from checkout drop-off because an order exists, but the revenue outcome can still change. For a practical reconciliation, compare abandoned checkouts, provider decline/instruction data, created orders, refunds and chargebacks in the same time window.
The fact is that these states can look similar in a headline funnel. The hypothesis about why a shopper left needs the step event plus the provider/order outcome.