Why the card form lives on a separate page

If you have used the recharge wizard, you have noticed that the last step is not a card form. The wizard ends with a review summary and a single confirm button. Press it, and the browser is redirected to a dedicated payments domain. The card number, expiry and CVV are entered there, not on platemanage.net.

The boring reason

PCI scope. Any page that handles a full card number falls under PCI DSS. By isolating that page on its own domain with its own deployment pipeline, the rest of the Service — the marketing pages, the wizard, the legal documents, the blog — stays out of scope. That is good for users (less risk of a card leak via a stray script on a marketing page) and good for us (a smaller, more focused security audit).

The user-visible reason

The redirect makes the card form feel different. The URL changes, the styling stays consistent but the layout simplifies, and the page is the only one on the whole property that asks for a card. If someone phishes a fake recharge page, the missing redirect is one of the first signals you can use to spot it.

What stays the same after the redirect

• Branding — the wordmark, fonts and colours match.
• The AED total — locked at the previous review screen and shown again on the card page.
• The order reference — visible on both sides so support can trace either end.

What changes after the redirect

• The domain changes from platemanage.net to payments.platemanage.net. The TLS certificate is different because the domains are different — that is expected.
• The card form replaces the wizard.
• The session is short — 90 minutes from the moment you arrive. If you leave the card page idle, you'll need to start the wizard again. This is on purpose.

What the redirect does not buy you

The redirect alone is not a security guarantee. Plenty of payment systems use a separate domain and still leak data through a sloppy logging library on the card page. The actual safety comes from the things behind that page — TLS 1.3, restrictive CSP, no third-party scripts, encrypted at rest, short retention. The redirect is one ingredient in a longer recipe, not the whole dish.

← Back to blog