Payment page not loading: find the blocked step

Most stores send card details to a payment provider rather than keeping them. The provider's fields arrive either as a separate page the shopper is sent to, or as a frame placed inside the store's own page, and each route depends on settings the store controls. When one setting is wrong, or the store sends the shopper to a staging address, the card box never appears. The shopper sees a flicker, an empty space or the same address step again. An owner testing on a desktop, with cookies and settings already in place, often sees a working payment step.

• After you press Pay, does the address bar move to the provider's domain, or stay on your site or a staging address?
• Does a popup-blocked notice appear, or does a new tab open and then close without a page?
• Does the console show a 'Refused to load' or 'Refused to frame' line that names the provider's domain?
• Does the console name an element the payment script could not find on the page?
• Does a private window on a phone show the card fields while your normal browser shows nothing?

A store reaches payment in one of three ways. It redirects the shopper to a page the provider hosts, opens that page in a new window, or places the provider's card fields inside its own page. A redirect breaks when the return or payment address points at the wrong host, such as a staging copy or an old domain. A new window breaks when the browser blocks it, which happens when the window opens after a delay instead of directly from the tap. A frame breaks when the store's own rules do not allow the provider's domain to load.

The first check is the address bar. A redirect that lands on the provider's domain worked. A page that stays on your domain with a blank space in the middle is a frame, and an address that never changes is usually a blocked window. Name the route before you read any further, because each route leaves its own evidence. Write down which route the store uses, since the fix for each one is different.

Frames and scripts from another domain only load if the store's content security policy lists that domain. When it does not, the browser refuses and writes a line to the console, such as a refused to load script or refused to frame message, and the line names the blocked domain. Read that line word for word, then compare the domain with the one the provider gave you. A common miss is a provider domain that changed, or a second domain the provider added for its fields that the store never allowed.

A different line means a different problem. A message about a missing element means the payment script loaded but the page has no place to draw the fields, which happens after a template change removes a container. A blank frame with no console message can mean the frame was blocked by a privacy setting that stops third-party cookies. Each message points to a different fix, so copy the exact text before you change any setting.

Mobile browsers block a window that opens after a delay, such as after a network call returns. If the store waits for its own server to create the payment session and then opens the provider's page, the tap has already ended by the time the window opens, and the browser refuses it. The shopper sees the button go grey, then nothing. Check the address bar for a blocked popup notice, and check whether the Network tab shows the session request finishing just before the window should open.

Checkout flow testing

A new provider domain, a staging address left in the settings or a stricter content policy can stop the payment step again after a release that touched nothing on the payment page. Rerun the same shopper on a phone and a laptop after each change, and read the console before the card fields should appear. Owners check each preview deploy this way, because a preview often has its own return address.