The payment page is the single screen on which a customer enters or confirms a payment credential and commits to the purchase. It is the narrowest point of the funnel: one page, a handful of fields, and no second chance if it fails badly.
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.