Before you launch or pay for traffic
Payment page credit card: what it must show
The buyer has picked the items and typed the address. Now the page asks for a card, and the buyer wants proof the page is safe before typing a number.
What should a payment page for credit card payments show?
A card payment page should load over a secure address, show the total and the card fields together, and load those fields from the payment provider so they appear within a few seconds. A wrong card number should show an error beside the number without clearing the other fields, and the total should not change between the address step and the card step. Before typing a number, a buyer looks for the lock in the address bar, a total that matches the cart, and fields that have actually appeared. A simulated test stops at the payment step and reports whether those fields appeared, and where a visitor stopped.
What this looks like in a report
“The card boxes have not appeared, just a gap under the total. The page does not show a lock here. Am I giving my card number to a real store? I am leaving.”
The fix. Load the card fields from the payment provider's own address, and show a loading message in their place until they appear. Serve the whole checkout over https, and fix any request on the payment page that still loads over http.
An illustration. Run a test to see your own.See a real sample report
The card boxes load from elsewhere, and a blank gap looks like a fake store
Many card forms are not part of your page. The payment provider draws the number, expiry and security code boxes inside its own frame, which the browser loads from another address. If that address is slow, blocked by a content blocker, or refused on a network that filters it, the buyer sees a blank gap under the total. The Pay button may still be active. A buyer who sees an empty space where the number goes assumes the store is not taking cards, or that the page might be fake, and leaves. You may never see this, because your own browser has loaded that frame many times.
- Does the address bar show a lock on the payment step, not only on the home page?
- Do the card number, expiry and security code boxes appear within a few seconds on a phone?
- Is the total on the payment step the same as the total before the card step?
- Does a wrong card number show an error beside that box, with the other fields still filled in?
- Can a buyer tell whose form the card goes into, from the words beside the boxes?
The three things a buyer checks before typing a number
A buyer deciding whether to type a card number runs a quick check, mostly without thinking about it. They look at the address bar for a lock, which tells them the connection is encrypted. They look at the total, to see that it matches the cart and the shipping they saw a step earlier. And they look for the card boxes, because a card field that never appears reads as a page that is not finished. A lock on the home page does not count. The buyer checks the payment step itself, after the address, because that is where the card goes.
A blocked card frame or a broken payment step
A blank card area can have two causes, and they need different fixes. If the boxes appear in a private window with no extensions, and not in your normal browser, something in your browser or a blocker is refusing the frame. If the boxes never appear in any window, the frame did not load at all, and the fault is on the page or at the provider's address. Mimiq's report records failed requests and script errors on each step, so check the payment step for a request to the provider. A request that failed points at the address or a blocker. A request that never appears points at the page code that should have asked for the frame.
A wrong card number should not clear the whole form
Many payment steps show one message, 'Payment failed', and wipe the card fields when a number is refused. The buyer then retypes the address, the name and the card, and some leave at the second attempt. The better version is narrow. The message sits beside the card number box, names the problem in plain words, such as 'Check the card number', and the expiry and name stay filled in. Wrong: a red banner at the top of the page saying the payment was declined. Right: a message under the number box saying the number has too few digits. The second version tells the buyer what to fix, and it does not suggest their bank refused them.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A new payment provider or a checkout update can blank the card fields again
A payment provider change, a new checkout plugin version or a new country on your shipping list can move the card frame or change which fields load. Rerun the same buyers on a phone and a laptop after each change, and read the payment step's screenshot before you publish. Each preview address can be checked first, so a blank card area never reaches a buyer who has already decided to pay.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Can the test check that my card payment goes through?
No. Visitors stop at the payment step, and they cannot pay with a real card, so the test never reaches a charge, a decline or a receipt. Place one real order with a card you own, refund it afterwards, and read the receipt and the email it sends. The test shows whether the fields appeared, not whether the money moved.
Does the test show whether my payment page is secure?
No. It cannot audit your server, your certificate or your payment setup, and it does not replace a security review. It can show whether a request on the payment step failed, and whether the browser logged a script error on that step. A security review is separate work, and it needs someone who can read your setup.
Should I show card logos next to the fields?
Show the card brands you accept, if your payment provider's terms allow it. The test shows whether the logos load and whether they cover the fields on a phone. It does not tell you whether buyers trust logos more than a plain page, and it cannot ask a buyer what they think.
Why does checkout work on my laptop but not on a phone?
A phone gives the card frame less space, and the on-screen keyboard can cover the fields or the Pay button. Test both. The report includes a screenshot of the step each phone visitor reached, so you can see whether the number box is covered, blank or out of reach.
Can the test enter a test card and submit the payment?
No. Visitors go up to the payment step and stop there, and they do not submit a card, real or test. If you want a full payment run, use your provider's own test mode on a staging address with its published test card numbers, and keep those runs in your own checks.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.