Test payment form: does the card box load?

A hosted card form is not part of your page. The provider draws the card fields inside a frame that loads from its own domain, and your page holds only a placeholder. If that frame is blocked by a security rule or a script blocker, the visitor sees an empty gray box. The Pay button may stay disabled, because it waits for the frame to report that the card is complete. The owner has a saved card in their own browser and never sees the empty box. A stranger has no saved card, and leaves at the first gray bar.

• Does the card box show its fields on a phone and a laptop? A gray bar means the frame did not load.
• Open the Console and look for a refused frame or script that names the payment provider's domain.
• Press Pay once, then again. Does the button disable after the first press, or can a second payment start?
• Compare the total above the box with any amount the provider's box shows. A mismatch stops the visitor before any card is typed.

The visitor types a card number into a field that does not belong to your site. The provider's frame holds it, and your page only learns that the card is complete. Two things stop that frame from loading: a security policy on your site that does not list the provider as a source for frames, and a script blocker or a browser setting that refuses the provider's domain. Either one leaves the same empty box, so the visitor cannot tell which rule is at fault.

The Console names the cause. A refused frame or a blocked script shows the provider's domain in the message, and that domain tells you which rule to change. Turn on a tracker blocker in a private window and load the payment step again. If the fields disappear, the blocker is the cause, and a visitor with the same blocker will see the same gray bar.

The Pay button has two jobs that can conflict. It has to stay disabled until the form is valid, and it has to disable itself the moment it is pressed, so a second press does not start a second payment attempt. A button that stays enabled after the first press can send two requests. A button that never enables waits on a state change that never comes, often because the frame reported an error that your page does not read.

The amount is the other stop. The page shows a total above the box, and the provider's box may show an amount of its own, set by your server. If the two differ, the visitor sees two prices on one screen and leaves. Check the button's disabled state after one press in the Elements panel, and compare the two amounts with a screenshot taken at the same step.

The test ends at the payment step. A visitor cannot pay with a real card, so the run does not go on to the bank's verification page or back to your site afterwards. That return is where a session can be lost: a cookie set with a strict same-site rule is not sent when another site sends the visitor back, so the order page can say no order was found. A simulated run cannot reproduce that trip, and it will not show the problem.

Check the return by hand, in your provider's test mode, on a staging address, with the test card numbers the provider publishes. Confirm that the confirmation page loads after a successful test payment, and that a refused test payment leaves the visitor on the payment step with a message they can read. Write down the screen the visitor lands on after the return, and whether an order number appears on it.

Every new security header, fraud check or script can stop the card frame from loading. Run the payment step after each change, on a phone and a laptop, and again on every preview. A paid run can use a site password on a protected preview, but it still stops at the payment step, so the bank return needs your own test mode.