Customers Say They Can't Pay on Your Site: How to Diagnose and Fix a Broken Checkout

When customers say they can't pay but checkout works for you, first check whether their payment attempt ever reached your payment provider. Look in your Stripe, PayPal, Shopify Payments or gateway dashboard: an attempt marked declined or blocked means the customer's bank or a fraud filter refused it. No attempt at all means your checkout breaks before payment, usually because of test-mode keys, a plugin or caching conflict, an SSL problem or a payment account that is disconnected or on hold.

For an online shop this is one of the most frustrating problems: you can't see the error, yet sales disappear at the very last step, right when the customer was ready to pay. The good news is that checkout problems almost always have a concrete, verifiable cause. Below is how to reproduce the problem, where to read the real error, how to tell the three kinds of failure apart, and what you can fix yourself.

Quick diagnosis: what the symptom usually means

Step 1: Reproduce it like a real customer

Most of the time, the reason "it works for you" is that you test differently than your customers do. Make your test as realistic as possible:

• Open the site on your phone, on mobile data, not on the office wifi.
• Use a private (incognito) window so saved logins, cookies and cached pages from old sessions don't hide the problem.
• Test in Chrome, Safari, and inside the Instagram or Facebook app if you get traffic from there. In-app browsers can handle pop-ups and redirects to the bank differently from a normal browser.
• Go all the way through with a real card, for a small amount, and refund it afterwards. Test mode uses test cards and never shows how a real bank behaves.
• If you can, try a card from a different bank than your own.

Then ask the customer for three things: a screenshot of the exact message, the approximate time they tried, and the device and browser they used (or whether they tapped a link inside a social app). With those, you can match their attempt in your dashboard instead of guessing.

If you manage to reproduce the block even once, you have won half the battle: you now have a concrete error to chase, not a vague story.

Step 2: Find the attempt in your payment dashboard

Your site shows you very little. The real reason is in your payment provider's account.

• Stripe: go to Transactions > Payments and filter by status. Payments declined while the customer was at checkout usually show as Incomplete, charges to saved cards as Failed; hover over the status badge to see the reason. Common codes are "insufficient_funds", "card_declined", "generic_decline", "do_not_honor", "expired_card", "incorrect_cvc" and "authentication_required".
• WooCommerce: open WooCommerce > Orders and look for orders marked Failed or Pending payment, then read the Order notes inside each order. For more detail, turn on logging in your payment plugin's settings and read the entries under WooCommerce > Status > Logs. Logging only records what happens after you switch it on, so place a test order afterwards, and switch it off again when you're done.
• Shopify: open the order or the abandoned checkout and read the payment events in its timeline.
• PayPal and other gateways: every provider has a transaction list with a status and a reason for each failed attempt.

How to read what you find: if you see many declines from different banks with different codes, your checkout is working and customers really are being refused by their banks. If you see no attempt at all, even though the customer says they pressed "Pay", the payment never left your site. Stripe notes that broken requests from a faulty integration usually don't appear in the Dashboard at all, which is exactly why an empty list points to your setup, not to the customer.

Don't expect the bank to tell you everything. According to Stripe's guide to card declines, issuers report most declines as generic and discuss the specific reason only with the cardholder. A "generic_decline" or "do_not_honor" usually means the customer has to call their bank or use another card.

Step 3: Work out which of the three failures you have

1. The bank declined the payment. The payment reached the customer's bank and the bank said no. Your site is fine. Typical reasons: not enough funds, a daily or online spending limit, card blocked for online or foreign payments, a mistyped card number, expiry date or CVC, a card issued in another country that the bank treats as higher risk, or the bank suspecting fraud after a large or unusual purchase.

A special case is 3-D Secure, the extra check where the customer approves the payment in their banking app or with a one-time code. Under the Strong Customer Authentication rules, in effect in the European Economic Area since 14 September 2019 (enforcement dates varied by country), most online card payments need it, and banks can decline payments that require it but don't get it. If the customer doesn't finish that step in time, the payment fails or stays incomplete. We cover the error codes and fixes in detail in why card payments fail: 3D Secure and SCA errors.

2. Your payment provider blocked it. Providers run their own fraud screening before the payment is sent to the bank. In Stripe, Radar blocks payments it scores as too risky or that match a rule you created, and the payment shows a message such as "Stripe blocked this charge as too risky." The bank never authorized anything. If you added strict rules at some point, for example after a wave of suspicious orders, check whether they now catch real customers. When one of your own rules blocks a legitimate customer, Stripe lets you add them to an allow list from the payment page, though that doesn't retry the payment.

3. Your checkout broke before payment. Nothing reached the provider. Signs: the pay button does nothing, the card fields never load, the page reloads endlessly, a blank page, or a technical error such as "error 500". The problem is on your side, and the next section lists where to look.

Step 4: Check the usual suspects on your site

• Test keys or test mode left on. Many shops go live while still using the processor's test keys or with a "test mode" or "sandbox" box ticked. Real cards then fail or nothing is charged. Make sure live keys are in place everywhere; our payments go-live checklist walks through the switch.
• Payment account disconnected or on hold. If the provider needs more verification documents, has paused the account or the connection was revoked, checkout may say the store can't accept payments or simply hide the payment methods. Check your provider's dashboard and the email inbox the account is registered to for warnings.
• Expired or broken SSL certificate. Without a valid HTTPS connection customers see a security warning, and payment fields often won't load. Check that the checkout page itself opens over https:// without any browser warning, not just the homepage.
• A plugin, theme or update conflict. On WordPress/WooCommerce, a new plugin or an update can break the payment page. If it worked and suddenly stopped, ask what changed last. The standard test, ideally on a staging copy, is to disable every plugin except WooCommerce and your payment plugin, then re-enable them one at a time; switching temporarily to a default theme such as Storefront or Twenty Twenty-Five rules out the theme.
• Caching and optimization. WooCommerce's own documentation says the cart, checkout and My Account pages must be excluded from caching, because they show data specific to each customer. A cached checkout page, or a speed plugin that bundles and delays scripts, can leave the pay button dead or the card fields empty.
• Site address mismatch. On WordPress, if the WordPress Address (URL) and Site Address (URL) in Settings > General don't match exactly (for example one with "www" and one without, or http and https), the checkout's background requests fail and the page can spin forever.
• Missing shipping options. If no delivery method covers the customer's country or postal code, they never reach the payment step and will say "I can't pay".
• Overly strict form fields. A field that rejects spaces in a phone number or won't accept a foreign postal code blocks perfectly valid customers.
• An outdated payment integration. Old plugins or custom code that don't support Strong Customer Authentication can see high decline rates from European banks. Update the payment plugin and check that it is still maintained.
• An outage at the provider. Rare, but it happens. Every major provider has a public status page; check it before you start taking your site apart.

When the customer was charged but the order says unpaid

This one looks like a site problem and a bank problem at the same time. Usually the payment did succeed, but your site never got the confirmation. Payment providers tell your store "this order is paid" through a notification sent to a URL on your site, called a webhook (older PayPal setups use IPN). If that URL is wrong, blocked by a firewall or security plugin, or the plugin was reconfigured, orders stay in Pending payment even though the money arrived.

Before you ask the customer to pay again, check the provider dashboard for a successful payment with their email or amount. If it's there, mark the order as paid manually, then fix the notification settings so it doesn't happen again.

A related case: when a provider's fraud filter blocks a payment, the customer may still see the amount "pending" in their banking app. That is a temporary authorization, not a charge, and Stripe says the card issuer typically removes it within a few days.

What to tell a customer whose payment failed

A short, calm reply keeps the sale more often than silence. Something like: "Sorry about that. Please check the card number, expiry date and security code, or try a different card. If it's declined again, your bank can tell you the exact reason. You can also pay by bank transfer or PayPal, and we'll hold your order in the meantime."

• Don't ask them to try the same card again and again. Card issuers can treat repeated attempts as a fraud signal and decline even more.
• Point them to their bank for "declined" messages: only the bank can see why it refused.
• Always have a second way to pay. A wallet such as Apple Pay or Google Pay, PayPal, a bank transfer, a payment link or cash on delivery recovers orders a single card form would lose.

When to fix it yourself and when to ask for help

You can handle plenty on your own: switching to live keys, renewing SSL, disabling a plugin that broke the page, excluding checkout from cache, adding a shipping zone or adding an alternative payment method. These are common-sense fixes that don't need a developer.

But if the payment breaks before it reaches the provider and you can't see why, if it's a recurring technical error, if webhooks keep failing, or if the payment integration needs rebuilding, it's time for someone who does this every day. Every day with a broken checkout means orders you don't get back.

At MPO Web Studio, a small web studio in Cluj-Napoca, we work remotely and can check a checkout quickly. We'll tell you honestly whether it's something small you can fix yourself or something worth handing over, with clear pricing upfront. If you'd like a second pair of eyes on your problem, send us a WhatsApp message and we'll look at it together.