The payment page: what you must not store and what you must not connect

A store usually does not need to store a card number. That is the payment provider's job: the person enters data in its field or on its page, the store receives the payment status. As soon as the store starts taking the card "into its own form", the responsibility jumps. This note is not about payment-scheme certification. It is about ordinary mistakes that show up before any auditor.

An ordinary minimum

• The card fields belong to the provider. Your database keeps the order and the status, not the PAN and not the expiry.
• The payment page has no extra chats, pixels and experiments that read input.
• The payment address is explainable. If there is a redirect, the buyer should not have to guess whether it is their bank.
• The admin where orders are visible is closed with separate rights. A warehouse clerk does not have to see payment identifiers.
• Submitting the form again does not create a second order for the same payment.

A WAF on this path helps against junk and guessing, but it does not replace a logic review: a swapped amount, someone else's order, a status of "paid" without a payment. That is a pentest of the path, and it makes sense to do it on test payments, not on employees' live cards.

Lexora walks the payment page together with the store: both as a buyer path and as a plane that extra data should not enter.