Secure payment forms best practices: card fields

A padlock in the address bar means the connection to the page is encrypted. It does not say who else runs code on that page. A checkout often loads a tag manager, a chat box and a discount script, and any of them can read a field you built yourself. A card box from your payment provider sits in a frame served from the provider's own address, so the digits never reach your page. A stranger on a phone meets the gap when that frame loads late, or when a blocked script leaves the space empty.

• The padlock shows on every step of the checkout, including the payment step itself.
• The card number, expiry and security code come from your provider, or carry autocomplete names.
• No image, script or stylesheet on the payment step loads from a plain http address.
• Each third-party script on the payment step is listed, and the step needs it.
• A declined card keeps the name and address filled in, with the message beside the card field.

Three setups cover most stores, and they behave differently on a phone. In the first, your own inputs collect the number and post it to your server, so the digits pass through your code, your logs and every script on the page. In the second, the provider serves the card fields inside its own frame, and your page only receives a token that stands in for the card. The mixed setup breaks quietly: the provider's frame is on the page, but your own script also reads the number field before the frame gets it. Check which one you run by looking at where the number field is served from.

The wrong version is a field named cardNumber with no autocomplete value. A browser then cannot tell it is a card field, so autofill offers a shipping field or a saved login instead, and a buyer who expects their saved card gets nothing. The right version uses the autocomplete values cc-number, cc-exp and cc-csc, or the provider's own field. To confirm which one you have, open the field in the browser's developer tools on the payment step and read its attributes. A simulated visitor cannot pay with a real card, so the test cannot show a saved card being filled in.

On a phone the card frame is the last thing to load, after the page, the total and the scripts that run before it. If the frame is slow, the buyer sees an empty box, and then the fields appear, or nothing does. The buyer has typed an address, so an empty box looks like a fault. The simulated test shows this as a step: the visitor reaches the payment step, and the report gives a screenshot of it, with any failed or slow request on that step. An empty box on the screenshot points at the frame or a script that blocks it. Fields with a dead Pay button point somewhere else, such as validation or the total.

A card number can leak after the payment step as well as inside the form. The wrong version is a redirect that carries the order total, the email or a partial card number in the address, where it stays in browser history, analytics and any link someone shares. The other wrong version is an error handler that writes the whole request body to a log, so every decline is saved with its digits. The right version sends only an order reference in the URL and logs the status code with that reference. After a decline, read the address bar and search your error log for the test number you used in staging, and make sure it is not there.

A store owner adds a review widget, an ad pixel or a new discount script, and the payment step changes without anyone opening it. Rerun the same first-time visitors up to the card fields after each change, and compare where they stopped with the last run. Mimiq can send the same visitors through again, so you see whether the step that loaded last week still loads today.