AI Web Center

// blog

The Safest Card Number Is One Your Store Never Has

Hackers go where the card numbers are. If customers pay on the payment provider’s off-site page, or in the provider’s own card fields, card numbers never reach the store’s server, so a break-in yields no cards and the store can validate with PCI’s shortest self-assessment, SAQ A. The store keeps the payment ID, card brand, last four digits and expiry date, which is enough for receipts and refunds. A card form on the store’s own server puts every card typed since a break-in at risk and brings in the full PCI standard.

Last updated 2 min read

From our case study on building a shopping cart and checkout.

When an online store gets hacked, the attacker is usually after one thing: card numbers. Addresses and order histories are bad enough to lose. Card numbers are what sell.

So the best defense is simple. Don’t have them.

Three ways to take a card

1. The provider’s off-site payment page. The customer clicks Pay and lands on the payment provider’s secure page, at the provider’s own web address. They pay there and come back to your thank-you page. This is how PayPal and Alipay already work, and every major card processor offers it for cards too. Your website and server never see the card number.

2. The provider’s card fields inside your page. The customer stays on your checkout page, but the boxes they type the card into are small frames served by the provider. Card numbers still go straight from the browser to the provider. The catch: the page around those frames has to stay locked down, because an injected script on your page is the classic way to skim cards.

3. A card form on your own server. Your form, your server, passing the number on to the provider. Avoid it. Every card typed since a break-in is exposed, and you take on the full PCI security standard. Stripe’s security guide puts that at more than 300 security controls.

Options 1 and 2 let a store validate with PCI’s shortest self-assessment, SAQ A. Since March 31, 2025 that comes with one condition: you confirm your site isn’t open to script attacks that could affect your e-commerce systems.

“But we need the card for refunds”

You don’t. Here is what the store keeps:

  • The provider’s payment ID, which is all a refund needs.
  • The card brand, last four digits and expiry date. Per Stripe’s guide, these are outside PCI scope and safe to store. They’re enough for receipts and for a support call (“the Visa ending 4242?”).
  • For repeat customers, a token. The saved card itself lives in the provider’s vault.

What the store never keeps: the full card number or the security code.

Two rules that go with it

  • An order is paid when the provider says so, by a signed webhook to your server. A customer reaching the thank-you page proves nothing; anyone can type that address.
  • Every payment call carries an idempotency key, so a double click or a retry charges the card once.

That’s our default for every store we build. The full case study shows where it fits, from the cart to the refund, with a diagram of all three options: Shopping cart and checkout case study →

Worried about how your own store takes cards? Get in touch, or run our free website security check.

// keep reading