An e-commerce site collects card details in its own form and posts them to a payment provider's API. What would you change and why?

What the interviewer is testing

Whether you recognise that this design maximises compliance scope and know the standard remedy.

What is wrong

Card numbers touch your servers, which pulls every system that stores, processes or transmits them — and every system connected to those — into PCI DSS scope. Without deliberate segmentation that expands to most of the estate, and each in-scope system needs the full control set, evidence and annual assessment.

Scope is the single largest driver of compliance cost, so this decision is worth far more than it appears.

There is also a security consequence: your checkout page's JavaScript context now has access to card data, which makes any third-party script on that page — analytics, tag manager, chat widget — a card-skimming vector. This is the mechanism behind a long series of real breaches where the victim's own servers were never compromised.

What to change

Hosted payment fields or a redirect, so the card number goes directly from the customer's browser to the payment provider and never touches your servers. You receive a token.

This is what reduces a merchant from the most demanding validation level to the simplest, and it is the largest scope reduction available.

Tokenise at the earliest point for any card data you do handle, so downstream systems hold tokens rather than numbers and fall out of scope.

Segment the network so that whatever remains in scope is genuinely isolated with minimal demonstrable connectivity.

What pulls systems back in unexpectedly

Card numbers in application logs. In a support ticket where a customer pasted one. In a database backup. In an analytics event. In a screenshot on a bug report.

Each of these pulls the receiving system fully into scope, and preventing it is a detection problem as much as a design one — pattern scanning of logs and tickets, plus input handling that never logs payment fields.

What a strong answer adds

The framing that gets it funded: this is not a security refinement, it is the difference between a manageable annual assessment and a permanent compliance programme. And it simultaneously removes the third-party script risk on the most sensitive page, which is two significant risks addressed by one change.

Common weak answers

Encrypting the card number in transit and at rest, which does not remove it from scope. Adding a WAF.