Payment page is the single screen where a customer enters or confirms a payment credential and commits to the purchase, the narrowest point of the checkout funnel. It can be served entirely by the provider as a hosted payment page, by the merchant with provider-served fields as an embedded checkout, or by the merchant handling raw card data, which pulls the business into the heaviest PCI DSS tier. The screen should show an itemized total, the likeliest payment option first, and a seller name that matches the statement descriptor. In-field validation and preserved inputs after a decline decide whether customers retry. Injected scripts reading card fields, usually arriving through third-party tags, make it a store's highest-value attack target.
Whose domain serves the page
Three arrangements are common, and they differ mainly in who holds the card data. The provider can serve the entire page from its own domain, which is a hosted payment page. The merchant can serve the page while the provider serves the fields inside it, which is an embedded checkout. Or the merchant can take raw card data into its own systems, which almost nobody chooses now because it pulls the whole business into the heaviest PCI DSS tier.
What earns space on the screen
The order total, itemized, with nothing left to reveal. The payment options, with the one this customer is most likely to use placed first. The seller's legal name and a support contact. Little else: navigation, cross-sells and newsletter prompts all give a hesitating buyer somewhere else to go.
The name shown here should match the payment descriptor that will later appear on the statement. A mismatch is a dispute waiting a month to happen.
Error states decide whether there is a second attempt
Validate the card number and expiry in the field, before submission, so an obvious typo never becomes a decline. When a payment does fail, keep every value the customer already typed — re-entry is where people give up.
Wording matters as much as the retry. "Payment failed" tells the customer nothing; "your bank declined this card, try another or contact them" produces a second attempt. Telling a soft decline worth retrying from a hard one is the substance of decline recovery.
Thumbs, keyboards and small screens
A numeric keypad for the card number. Tap targets a thumb can hit. A layout that still works when an on-screen keyboard takes half the viewport. Autofill attributes on every field so the browser or wallet can populate them. On phone traffic these are not refinements; they decide whether the page converts at all.
The scripts on this page are a security boundary
A payment page is the highest-value target on any store. Injected JavaScript that reads keystrokes out of card fields has been a standard attack for years, and it usually arrives through a third-party tag rather than the merchant's own code.
Load nothing here that is not needed to take the payment. Pin script versions, apply a content security policy, and put change control on the template — a marketing tag added in a hurry is the usual entry point.