Ecommerce payment gateways fail under holiday traffic: How to test before Black Friday breaks your checkout

Payments usually fail at peak because of slow or timed-out gateway calls, rate-limit (429) errors, retries that charge a customer twice, 3D Secure friction, or webhook handlers that cannot keep up. To prepare, check your provider’s limits, make sure retries use idempotency keys, test every payment method with real test orders, and reconcile gateway payments against store orders throughout Black Friday.

Black Friday falls on 27 November and Cyber Monday on 30 November, about three weeks away. A checkout can look healthy right up to the moment a customer clicks Place Order, because the payment step depends on systems your store does not control: the payment gateway, the fraud checks, the customer’s bank, and the webhook that tells your store the payment worked. Providers do not publish how those systems perform on peak days, so there is no promised number to plan around. What you can plan around is the part you do control: how your store waits for the gateway, how it retries, whether a retry can charge someone twice, how your webhook endpoint copes with a spike, and whether anyone notices when payments and orders stop matching.

The stakes are real even outside peak events. In Baymard’s survey of US online shoppers, 17% of those who abandoned a purchase cited website errors or crashes and 10% a declined card, which shows how little tolerance shoppers have for a payment step that fails.

This guide explains how a payment moves through checkout, what typically breaks under holiday traffic, which parts merchants and agencies can control, how to test before the sale, how to prevent double charges and “paid but no order” cases, and what to do when payments start failing on the day.

How does a payment move through your checkout?

A single click on Place Order sets off a chain of steps, and any of them can be the one that fails:

Step	What happens	What can go wrong
1	The customer clicks Place Order	The page gives no feedback, so the customer clicks again or refreshes
2	Your store or its payment extension asks the gateway to create or confirm a payment	The call is slow, times out, or is rate-limited
3	Fraud and risk checks run	Extra processing time, or a decline you cannot see in your own admin
4	3D Secure runs if the bank requires it	The bank’s step is slow, blocked by your page, or abandoned by the customer
5	The gateway responds	Your store never receives the response, and does not know if the customer was charged
6	Your store creates or updates the order	The order is not created even though the money was taken
7	The gateway sends a webhook confirming the result	Your endpoint is slow, returns an error, or processes the same event twice
8	The confirmation email goes out	The order exists but the customer is not told

Why do payment gateways fail under holiday traffic?

Not every failure is the gateway’s fault, and the difference decides what you can fix. Here is how the failures look from the customer’s side and what controls each one:

Failure	What the customer sees	Business impact	Main control
Slow or timed-out gateway call	A spinner, or a generic error after a wait	Abandonment, uncertain payment status	A sensible timeout, a clear message, provider coordination
Rate limit (HTTP 429)	The payment method fails	Rejected transactions	Headroom check, backoff, early contact with the provider
Retry without idempotency	Charged twice	Refunds, support load, chargeback risk	One idempotency key per payment attempt
3D Secure friction	A bank page, then a failed or abandoned payment	Lost conversion	Test every 3DS scenario, allow the 3DS frame
Webhook delay, failure, or duplicate	Charged but no confirmation	Order and payment mismatch	Quick 2xx response, queue processing, reconciliation
Front-end failure	The Pay button does nothing, or the form is blank	Lost orders with no gateway involved	Monitor checkout scripts and JavaScript errors

Slow or timed-out payment calls

When checkout asks the gateway to authorise a payment, it waits for the answer. If that call becomes slow or times out at peak, the customer sees a spinner or an error, and your store may not know whether the payment went through. How slow depends on your provider, the endpoint, the fraud rules, your network path, and demand across everyone using that provider. No universal figure applies, so treat any claim of a fixed peak latency as a guess. What you decide is how long your checkout waits and what it tells the customer when the wait ends.

Rate limits and 429 errors

Payment APIs cap how many requests an account can send. Stripe’s rate limits are a useful example: in live mode the global limit is 100 requests per second per account, most individual endpoints are capped at 25 requests per second, and there is a default limit of 50 requests in progress at once. A request over a limit returns 429 Too Many Requests with a header that says which limit was hit. Stripe also says it tries to set the limits high enough that legitimate payment traffic does not exceed them, so for most merchants a 429 at peak points to something else on the same account: closely spaced requests from reporting, sync, or migration jobs, or long-running requests. Other providers have their own limits, so do not assume these numbers apply to yours.

The same page recommends retrying rate-limited calls on an exponential backoff schedule with some randomness, so retries do not arrive in a wave. For a large increase in limits Stripe asks for at least six weeks’ notice, which is more than the time left before Black Friday, so open the conversation now if you expect a big spike.

Retries that charge a customer twice

When a payment call times out, two things retry: the customer, who clicks again, and your own code or extension, which may resend the request. If the first request had already succeeded at the gateway, a second one without protection becomes a second charge. This is the failure that does the most damage to customer trust, and the prevention section below explains the fix.

3D Secure and bank authentication

When the card issuer requires it, the customer is sent through 3D Secure. The issuer decides whether that is a frictionless check or a challenge, and your preference cannot guarantee either outcome. The step can open in a modal, an iframe, or a redirect to the bank, and the customer returns to the return_url you set. If your site uses a content security policy, it must allow the 3D Secure frame, which for Stripe means the js.stripe.com and hooks.stripe.com origins plus the origin of the return URL. A failed authentication sends the payment back to needing a new payment method, so the customer must try again.

Webhooks that arrive late, twice, or not at all

Many payment results reach your store through webhooks, for example when the customer’s bank confirms a payment after the browser has moved on. Stripe’s guidance is that your endpoint should return a 2xx response quickly, before any complex logic, and process events through an asynchronous queue, because a large spike in deliveries can overwhelm endpoint hosts. In live mode Stripe retries a failed delivery for up to three days with exponential backoff, events can arrive more than once and out of order, and you can resend events manually. In a sandbox it retries only three times over a few hours, so you cannot reproduce the live behaviour there.

That changes how to read a “charged but no order” report. It is rarely the provider losing the message. It is usually your endpoint being too slow, returning an error, or handling the same event twice without noticing.

Failures that are not the gateway at all

Before blaming the gateway, rule out the storefront. A JavaScript error, a theme or extension conflict, a content security policy that blocks the payment script, an address validation rule, or an inventory check can stop a payment from ever being sent. Those failures look the same to the customer, and they are fixed in your own code and settings.

Which payment failures can you control, and which belong to your provider?

Layer	Shopify (hosted checkout)	Magento, Adobe Commerce, WooCommerce
Gateway timeouts and retries	Managed by the platform and your payment provider. You cannot set them	Set in your payment extension and its settings. Check what it does after a timeout
Idempotency on retries	Handled in the platform’s checkout	Depends on the extension, so ask the vendor
Payment methods offered	You choose which methods to enable	You choose, and each adds scripts and integration points
Webhook endpoint capacity	Not your concern for the core checkout, but apps and integrations you run have their own endpoints	Your server, so size it for a spike and use a queue
Fallback payment method	Offer a second method from a different provider if you can	Same, configured in your extensions
Monitoring	Checkout drop-off, errors from apps, scripts on checkout	The same, plus application logs and server health

How do you test the payment path before Black Friday?

Why standard load tests miss payment failures

A typical load test loads pages, fills carts, and stops before payment, so it never touches the part that fails first. Pointing the test at the real payment path is not the answer either. Stripe generally discourages load testing against a sandbox, because sandbox limits are lower than live ones and, in a sandbox, the call to the payment gateway is mocked, which gives a very different latency profile. It recommends building your integration so that calls to the provider can be mocked in a load test, with delays based on the durations of real live calls. Do not aim load tests at a live gateway without your provider’s agreement.

This is work for your agency or developers. As a merchant, your part is to ask whether the integration can run against a mocked gateway, and to run the real test orders below at a quiet time.

The test orders to run now

1. Place an order with every payment method you offer, on desktop and on a phone, at a low-traffic hour.
2. Use a card that declines, and read the message a customer would see.
3. Run each 3D Secure scenario in the table below.
4. Click Pay twice in quick succession, then refresh mid-payment, and confirm you end up with one charge and one order.
5. Repeat on a slow connection, because slow responses trigger impatient clicks.
6. For each test order, compare the store order, the provider dashboard, and the confirmation email.
7. On staging, pause your webhook endpoint for a while, then restart it, and confirm the order still completes once the provider retries.

3D Secure scenario	What to check
The bank approves without a challenge	The payment completes and the order is created, with no extra step for the customer
The customer completes a challenge	The customer returns to the correct return_url and sees the order confirmation
The authentication fails	The customer is asked to try another payment method, and no order is created
The customer abandons the challenge	No duplicate charge, and the order does not stay stuck as paid
Authentication succeeds, then the card is declined	The decline message is clear, and no order is created
Mobile browser or in-app browser	The challenge displays and the customer can return to checkout
Strict content security policy	The 3D Secure frame is allowed to load

Stripe publishes test cards for these cases, for example 4000000000003220 for a payment that always requires 3D Secure 2 authentication, and 4000008400001629 for one that is declined after authentication. Other providers have their own test cards, so use theirs.

What an agency can simulate in a load test

• A mocked gateway that responds with realistic delays, and occasionally times out or returns errors, to exercise your retry and timeout paths
• Bursts of webhook deliveries against your endpoint, including duplicates and out-of-order events
• Repeated submissions of the same order, to confirm only one charge and one order are created
• Background jobs running at peak volume, since they share the same API account and its limits

How do you prevent duplicate charges and “paid but no order” cases?

Use one idempotency key for each payment attempt

Idempotency lets a request be repeated safely. Stripe’s documentation on idempotent requests explains that if a connection error occurs, you can repeat a request with the same key without creating a second object. Stripe saves the status code and body of the first request made with a key, and returns that saved response for retries, including error responses. Keys can be up to 255 characters, should be random enough not to collide (Stripe suggests V4 UUIDs), and should not contain personal data such as an email address. Keys can be removed after at least 24 hours, and sending different parameters with an existing key returns an error.

• Create the key when the customer starts a payment attempt, and reuse that same key for every retry of that attempt.
• Do not generate a new key automatically after a timeout, or the retry becomes a second payment.
• If you use a payment extension, ask the vendor in writing whether it sends idempotency keys on retries.

Stop double submissions on the page

A payment form that gives no sign of activity for a few seconds invites a second click. Show a processing state immediately, disable the Pay button after the first click, and tell the customer not to refresh the page. These are small changes, and they remove a common source of duplicate attempts before the gateway is involved.

Reconcile gateway payments against store orders

Reconciliation is the most reliable way to find payments and orders that disagree. Compare successful payments in your provider dashboard with orders in your store, then act on each mismatch:

What you find	Likely cause	What to do
Payment succeeded, no order in the store	Webhook endpoint slow or failing, or order creation failed	Check the provider’s event deliveries, resend the event or create the order, and email the customer
Two payments for one order	A retry or double click without idempotency	Refund the duplicate and check which step created it
Order shows pending, payment succeeded	Webhook delay or an unprocessed event	Confirm the payment, then update or complete the order before shipping
Order shows paid, no payment at the provider	A wrong or stale status in the store, or a bug in the handler	Do not ship until the payment is confirmed at the provider

Run it daily in normal weeks and several times a day through Black Friday and Cyber Monday. Do not rely on webhooks arriving in a particular order, because providers such as Stripe do not guarantee it.

What should you ask your payment provider before Black Friday?

Ask in writing, and ask now rather than during the sale:

1. What request limits apply to my account, and how close does my busiest day come to them?
2. Do I have background jobs, syncs, or reports that use the same account and could eat into my headroom?
3. How do I request a higher limit, and how much notice do you need?
4. What is your retry window for webhooks, and where can I see failed deliveries?
5. What is your policy on load testing, and how do you recommend I simulate peak traffic?
6. Where is your status page, and who do I contact during the Black Friday weekend?
7. Does the extension I use send idempotency keys, and does it check payment status before retrying?

What should you monitor on Black Friday itself?

Set thresholds against your own baseline rather than a universal number, because every store’s normal looks different. Investigate when any of these rises materially above its recent normal range:

• Drop-off at the payment step, compared with cart and shipping, while traffic sources and device mix stay stable
• Failed payments, declines, and authentication failures in the provider dashboard
• Webhook deliveries marked failed or pending, and your endpoint’s response time
• Payment and checkout errors in your application logs
• Duplicate charges, and orders that stay pending after a successful payment
• Your provider’s status page, and support tickets mentioning payments

What do you do when payments start failing?

Agree this before the sale, with a named owner for each step:

1. Work out the scope: one payment method, one device type, or all payments?
2. Check your provider’s status page and your dashboard for failed payments and failed webhooks.
3. Offer a fallback: promote a working payment method, or hide the failing one while you investigate.
4. Tell customers what to do. A short message such as “don’t refresh, your confirmation email will follow” prevents duplicate attempts.
5. Consider pausing campaigns that send traffic into a failing checkout.
6. When it clears, reconcile payments and orders, refund duplicates, complete missing orders, and write down what you learned.

Spotting checkout failures while payments are degrading with AuditIQ

Gateway trouble shows up in your store as customers dropping out and errors piling up. AuditIQ helps you see those symptoms early:

• User Experience Monitoring: shows where customers drop off in checkout, with frustration signals and device, browser, and session context, so a jump at the payment step stands out from your usual pattern.
• Log Monitoring: reads your application logs for PHP errors, database failures, and payment exceptions, tracks errors in checkout flows and gateway integrations, and flags error spikes and new error types. It applies to Magento, Adobe Commerce, and WooCommerce stores.
• CSP Monitoring: logs every content security policy violation with the blocked resource, the page, and the directive, which shows up a policy that blocks a payment script or a 3D Secure frame.
• Uptime Monitoring: checks your store continuously from multiple locations, records HTTP error codes and response time trends, and alerts you by portal, email, or Slack.

AuditIQ does not measure your payment provider’s internal latency, place test orders, or reconcile payments with orders. Keep the provider dashboard, its status page, and your reconciliation routine in place, and use monitoring to see the storefront side of a payment problem quickly.

Beyond checkout, AuditIQ is a 360° eCommerce monitoring platform purpose-built for Magento, Adobe Commerce, and Shopify stores. It continuously monitors every critical layer of a store — performance, infrastructure, SEO, security, user experience, configuration, and code quality — from a single, unified dashboard, so a payment problem does not quietly turn into lost holiday revenue.

Start monitoring your store for free today and see checkout drop-offs and payment errors as they begin.

Others also read

• 3D Secure payment failures in eCommerce: How to detect, diagnose and fix lost orders
• Why your store still slows down on Black Friday even after passing every load test
• Why is your payment form blank on Magento? A practical guide to CSP errors and how to fix them

Frequently asked questions

1. Will my payment provider share its Black Friday capacity plans?

Providers rarely publish peak latency, so ask your account manager or support team directly and get the answer in writing. Stripe’s own documentation, for example, invites you to contact support if you expect an event to push you over your limits.

2. How do I prevent duplicate charges when a payment times out?

Use one idempotency key per payment attempt and reuse it for every retry, so the provider recognises the retry and returns the original result. Check the payment status before repeating a request, and make sure your payment extension does the same.

3. Can I load-test my payment gateway directly?

Do not aim load tests at a live gateway without your provider’s agreement. Stripe generally discourages sandbox load tests because sandbox limits are lower and the gateway call is mocked, and suggests mocking calls to the provider with realistic delays instead. Ask your own provider for its policy.

4. Why was a customer charged but no order was created?

The usual causes are an order that failed to be created after a successful payment, or a webhook your endpoint answered slowly, with an error, or twice. Check the provider’s event deliveries, resend the event if needed, and reconcile payments against orders. Providers such as Stripe retry failed live webhooks for up to three days, so the event can often be recovered.

5. What can I do on Shopify, where I cannot change gateway settings?

Focus on what you control: which payment methods you offer, which apps and customisations run on checkout, a fallback method from a second provider, and monitoring for drop-off and errors. Ask your payment provider about its status page and escalation contacts before the sale.

6. Should I have a backup payment method for Black Friday?

Yes. Offering at least two payment methods, ideally from different providers, gives customers a path to pay if one degrades. Test the fallback as carefully as the primary, and remember that each added method brings its own scripts and integration points.

7. What payment-step drop-off should trigger an alert?

There is no universal threshold. AuditIQ suggests investigating a material increase in payment-step drop-off over a short rolling window, calibrated to your own baseline, traffic volume, and payment mix.