Payment page stuck on processing: find the wait

The spinner tells the shopper that something is happening, and nothing on the screen says what. The page may be waiting for a shipping or tax figure before the card fields become active, or for the provider to confirm a card the shopper already sent. In both cases the page has no fallback, so the spinner never gives way to an error. The shopper cannot see the request that is hanging, so they wait, press the button again or leave. An owner whose session already holds those figures sees the fields become active at once, and never meets the wait.

• Does the spinner start before you enter any card number, or only after you press Pay?
• Does the Network tab show a request with no response, still pending after the spinner starts?
• Does a status address keep returning 404 or 401 while the spinner runs?
• Does a bank check open in a window or frame you cannot see on a phone?
• Does a reload end the spinner, and does the cart still hold the same items afterward?

A payment page often needs a shipping rate and a tax figure before it can lock the total. It can request them when the page opens or when the address changes, and it keeps the card fields disabled until both answer. If one answer never comes, the fields stay disabled and the Pay button keeps spinning. This is the wait a visitor can reach, because it happens before any card is sent. Read the Network tab for a request that stays pending, and note its address.

A quote that hangs for one country and answers for another points at the rule behind that country, not at the payment provider. Change the address to one that fails, then to one that works, and watch the pending request each time. The report lists failed or slow app requests on the step where they happened, so a quote that stalls should show up on the address step.

Checkout flow testing

Some card payments need an extra check with the shopper's bank, shown in a box over the page or in a separate window. On a phone that box can open behind the page, under the keyboard or off the screen, and the shopper sees only the spinner. The store waits for the provider to say the payment is complete, and the provider waits for the check. Nothing on the page times out, so the spinner keeps going.

The Network tab shows which side is waiting. If the provider's answer says an action is needed and the page never shows that action, the check is hidden. If the store keeps polling its own status address and gets 404 or 401 each time, the store cannot match the payment to an order, and a common cause is a session cookie dropped during a redirect. A simulated visitor cannot send a card, so it cannot reach this part. Check it in the provider's test mode with its published test card numbers.

Some stores finish an order only when the provider sends a confirmation to the store's server, usually called a webhook. If that message is blocked, delayed or rejected, the shopper's page waits for a result the server never recorded. The payment may still have gone through, which is why you check the provider's log before you tell anyone to try again. A shopper who retries can be charged twice if the store does not catch the duplicate.

Check the webhook delivery log in the provider's dashboard for the failed attempt, and the store's own log for the request that came in. A request missing from the store's log, with a delivered one in the provider's log, means the store's endpoint rejected or dropped it. Fix the endpoint first, then send a test event from the provider's dashboard to confirm the fix.

A new shipping rule, a changed tax service or a moved webhook address can bring the spinner back after a release that touched no payment code. Rerun the same shopper after each change, with a quote for each country, and check the pending requests in the Network tab. Owners also test behind a site password and check each preview deploy first.