Multiple customers can't get past payment on my online booking page — what should I check?

One customer with a declined card is normal — banks decline cards for all sorts of ordinary reasons, and there's nothing to fix on your side. But if several different customers, on different cards that work fine elsewhere, all fail at the payment step of your online booking checkout, that pattern usually points at something on your store's setup rather than at any one card. This article walks through what to check, in the order that finds the problem fastest, and is honest about which parts you can diagnose yourself and which only Stripe's own dashboard can answer.

This article is specifically about customers failing to pay during online checkout on your booking page. It is not about a staff member taking a payment over the phone or in person from the Back Office — that's covered by Payment error PAY016 — the customer's bank declined the card and Payment error PAY004 — Stripe refused the charge (and it wasn't a bank decline), and those error codes (PAY016, PAY004) don't appear anywhere in online checkout, so don't go looking for them there. It's also not about a booking that did get paid but shows as unpaid or gets auto-cancelled afterwards — that's a webhook delivery problem covered in Troubleshooting Stripe Webhook Issues for Online Bookings.

Step 1: Find out exactly what the customer saw

Online checkout shows a short on-screen message when something goes wrong, and what it says tells you which of the checks below to focus on. Ask the customer (or check with whoever reported it) exactly what the screen said. There are three distinct messages to look for, each with its own reference code:

• "This store's online payment isn't set up correctly... quote reference PAY-SETUP" — the checkout couldn't even start taking card details. This is never the customer's card; it's something wrong with your store's Stripe connection. Go straight to Step 2.
• "Payment could not be loaded... quote reference PAY-LOAD" — the secure card form itself failed to load in the customer's browser. This is usually the customer's environment (an ad blocker or content blocker stopping Stripe's script, a flaky connection, or a browser extension interfering) rather than your store's setup. It's worth asking if it happens on a different device or browser before assuming it's on your end.
• "Your payment could not be confirmed... quote reference PAY-CONFIRM" — the card form loaded and the customer submitted it, but confirmation never came back after a couple of minutes. This is almost always a stuck 3D Secure/bank verification step (see Step 5) rather than a setup problem.

If the customer instead saw a short message like "Payment error: Your card was declined" with no reference code, the payment step itself worked correctly and Stripe genuinely turned the card down — that's Step 4 territory, not a setup issue.

Step 2: Check your Stripe connection status in Back Office

Go to Settings > Payment Management > Payment Processors. With Stripe selected as your payment processor, you should see a small status indicator next to the Stripe heading:

• "Stripe Webhooks setup" (green) — your connection is fine; move on to Step 3.
• "Stripe Webhooks not setup" or "Stripe Webhooks need repairing" (red, with a Setup or Repair button) — this is a very likely explanation for every customer failing at payment. Online checkout requires a working webhook link to Stripe before it will even offer a customer the card form; when that link is broken, every single checkout attempt on your store fails the same way, regardless of the card used. Click the button shown to fix it yourself — it's a one-click self-serve action.

If you don't see this status indicator at all on your Payment Processors page, that isn't proof the connection is fine — contact support and ask them to check your Stripe webhook status directly, since the indicator isn't visible for every store yet.

Step 3: Check you're using live keys, not test keys

Still on the Payment Processors page, look at the Publishable key field under Stripe.

• If it starts with pk_test_, your store is in Stripe's test mode. Test mode never actually reaches a customer's bank — a real card will typically look like it's simply being declined, and it will happen for every customer, on every real card, consistently. If your store is meant to be live, switch to your live keys (starting pk_live_ and sk_live_) from your Stripe dashboard.
• If it starts with pk_live_, your store is correctly in live mode. But if a specific returning customer fails while new customers succeed, their saved Stripe record may have been created back when your store was still in test mode — see Troubleshooting - you can't mix live and test customers on Stripe and "No such customer" - Stripe setup for how to spot and fix that. It produces the same kind of "declined" appearance but only affects that one returning customer, not everyone.
  
  

Step 4: Check the actual payment attempt in your Stripe dashboard

This is the one place with full visibility into why a specific card failed — Back Office genuinely cannot see this detail, so don't try to diagnose an individual decline from BRM alone. Every payment BRM creates for an online booking is tagged in Stripe with the booking reference, so:

1. Log in to your Stripe dashboard and open Payments.
2. Search for the booking reference (or the customer's name/email) to find the specific attempt.
3. Open it and check the Outcome section. This is the part that matters: a genuine bank decline shows as Declined with a reason from the card issuer, while a payment Stripe's own fraud detection (Radar) stopped shows as Blocked. Both can look identical to the customer on screen — a generic "your card was declined" — so the Outcome field in Stripe is the only place that tells them apart.

If several genuinely different cards from different customers are all showing as Blocked rather than Declined, that points at your Stripe Radar risk settings being too aggressive for your business rather than anything wrong in BRM — that's a Stripe-side setting to review, not something BRM can adjust for you.

Step 5: If the payment seems to hang rather than fail outright

Some cards, especially European ones, require the customer to complete an extra verification step with their bank (3D Secure / Strong Customer Authentication) before a payment can complete. Checkout gives this step up to about two and a half minutes before treating it as stuck. If the customer closed the verification popup, their bank's verification page didn't load, or they simply gave up partway through, checkout will eventually reload the card form for them to try again, and only shows the PAY-CONFIRM message if that retry also doesn't settle. If a customer reports the payment step "just spinning" or "not responding," ask them to keep the tab open for a couple of minutes rather than closing it immediately — it's designed to recover on its own where possible.

What this rules out

If you've been through Steps 2 and 3 and both check out (webhook status green, keys correctly live), then BRM's side of the setup is working, and the failures genuinely are individual payment outcomes that only Stripe's dashboard (Step 4) can explain. It isn't something an operator can fix from BRM's settings alone at that point — the cause lives in Stripe's decision on each transaction.

When to contact BRM support

Get in touch if:

• The webhook status shows an error and clicking Repair/Setup doesn't clear it.
• You're confident your keys are live-mode, and Stripe's dashboard shows genuinely different customers on genuinely different cards all failing, with no shared reason.
• Customers keep seeing PAY-CONFIRM specifically, rather than it resolving after a page refresh.

Include: the exact on-screen message and reference code (if any) the customer saw, the affected booking reference(s), roughly when it happened, and whether it's every customer or a specific one.