Squarespace test payment: check it before launch

A store owner testing a payment usually has an account, a saved address and a browser that autofills the address. Saved details skip the steps a new shopper has to fill in, so the owner never sees the rate a new address gets or the tax line a new region adds. Most providers draw the card fields in their own frame, so a slow load can look like a broken store. A test from your own browser can pass while a shopper in a new region sees an empty total or a pay button that stays grey. Only a test that starts from nothing shows that.

• Start signed out, in a private window, with no saved address.
• Use a shipping address in a region you rarely ship to, and note each rate offered.
• Watch the card fields appear before you type, and note how long they take on a phone.
• Compare the total on the payment step with the total in your store admin afterwards.
• Check the confirmation email from a real test order arrives with the same totals.

A Squarespace store takes payments through the providers the owner connected, and which ones a shopper sees depends on the settings and on the shopper's country. The same store can show two options to one shopper and one to another, which makes a single test from your own address a weak check. Before any payment, list the providers you expect to show, the countries they cover and the currency each one uses.

Then confirm the mode. Most providers have a test mode with its own keys or dashboard, and a payment made there does not move real money. The provider's dashboard is the place to confirm the mode, not the checkout page, which can look the same in both. After one test payment, the dashboard should show the attempt. If it does not, the attempt never reached the provider, and the fault sits before the card step.

The card number, expiry date and security code are usually drawn by the provider inside a frame that sits within your checkout. A store owner cannot restyle that frame or fix a slow load inside it. A visitor with a privacy setting or a blocker that stops the frame sees an empty box, while the total and the pay button may still look ready. The step screenshot in a simulated run shows that empty box, which tells you the frame never appeared.

The fix lives in two places: the provider's allowed sites or domains setting, if it has one, and any embed code you added to the store yourself. Test the step on a phone from a new address, then again on a laptop with a blocker turned on. If the box appears on one and not the other, the cause is the visitor's browser setting, and you decide whether that edge case is worth accepting.

The total a shopper sees on the payment step is the last number they compare with what they expected. Shipping rates, tax and discount codes can each move it, and a new address can change all three. A total that drops or rises after the address is entered reads to a shopper as a surprise, and a shopper who meets a surprise at the last step often stops. Compare the total at the cart, after the address, and on the payment step.

Adding a shipping region, switching providers or editing the checkout each changes which fields and options a shopper sees. Rerun the same simulated shoppers from a new address after each of those changes, and compare the payment step screen with the one you approved. Keep the test order and its admin total in the same place, so a change in one shows up next to the other.