Squarespace not accepting payment: why it refuses

The payment step draws its options from the store's settings, not from what the shopper wants to use. A method that is switched off, or not yet set up for the shopper's currency, does not appear. Your own test often misses this, because you already know which method you expected to see, and you may pay with a saved card that skips the screen a stranger would meet. A shopper who wanted a different method has no way to ask the store, so they leave.

• Open the payment step on a phone and on a laptop. Does each one list the same methods?
• Compare the methods on screen with the ones switched on in the payment settings.
• Check that the store's currency matches the currency shown in the total.
• Note the exact message after pressing pay. Is it a refusal, an error or a spinner?
• Make one small real order on your own card and refund it, to confirm a method takes money.

A payment step is only as full as the store's settings allow. Each method has to be switched on, connected to a provider, and valid for the currency and country the shopper is in. If one of those is not true, the method is absent from the screen, and nothing tells the shopper why. Check the list on the screen against the list in your settings, one line at a time. A gap between the two is the fault, and it is a setting you can change the same day.

Two things hide a missing method from the owner. A method that worked a few weeks ago may have been switched off by a change made somewhere else, such as a new currency. And a payment you make with your own saved card may skip a method that a stranger would have to use. The only reliable check is the screen a stranger sees, on the device they use.

A refusal means the provider or the shopper's bank turned the card down. A refusal can come from the shopper's own bank, which you cannot fix, or from a setting in your store or provider that blocks the card or the country, which you can change. An error that says something went wrong can mean the request did not finish reaching the provider, so the card may not have been checked at all. A spinner that never stops means the page is still waiting on something, and it can end with no message whatsoever.

Write down the exact words that appear after pressing pay, and what the screen showed just before. A decline with a bank's wording usually points away from the store. A vague error after a long spinner points at the store's connection to its provider, which needs the provider's setup checked. A spinner with no message is usually a page fault, and it belongs to whoever maintains the store's code, so send them the step and the time it happened.

A simulated visitor can reach the payment step, look at the methods on screen, and report what it sees. It can tell you a method is missing and the step where the shopper stopped. It cannot pay with a real card, so it cannot tell you whether a real card would be accepted. That last check needs a real order, placed with a card you own and refunded afterward, or a test mode your payment provider offers for the store. Use the simulated test to find the gap, then the real order to confirm the fix.

Switching currency, provider or country, or adding a new method, can remove a payment option for every shopper at once. Rerun the same simulated shoppers to the payment step after each change, on a laptop and on a phone, and compare the methods on screen with the settings. Keep a written list of the methods you expect to see, so the next check starts from that list rather than from memory.