Most organisations we assess have chosen their online payment integration for commercial reasons: what the provider supported, what the developer knew, what shipped fastest. That decision then quietly sets the size of the compliance job for years. It is worth understanding what each pattern does before the next replatform, rather than after.
Full redirect or hosted payment page
The customer leaves your site, enters their card details on a page served entirely by your payment provider, and returns once the payment is authorised. Card data never touches your systems, and the page they type into is not yours.
This is the lightest option, and for many merchants it is the difference between a short self-assessment questionnaire and a much longer one. It is not a free pass. You still control the page that sends the customer onward, and that page is in scope.
Embedded iframe or hosted fields
The form appears inside your page, but the fields themselves are served from the provider’s domain. Your site never receives the card number, yet your page hosts the container it sits in and every script that runs alongside it.
The card data may never reach your servers, but the page that frames it is still yours to protect.
This pattern is where we see the most misplaced confidence. Teams assume the iframe removes them from scope entirely. It does not, and v4.0 made that explicit.
Direct post or full API integration
Your application receives the card details and passes them to the provider. You are now storing, processing or transmitting cardholder data, which puts your web servers, your application, your logging and often a good deal of your internal network inside the cardholder data environment.
There are legitimate reasons to work this way, usually around checkout experience or unusual payment flows. It is the most demanding option, and it should be a deliberate choice rather than an inherited one.
What v4.0 changed for all three
Version 4.0 introduced requirements aimed squarely at payment page skimming. Whichever integration you use, if you serve the page a customer enters their card into, you are expected to know what scripts run on it, to authorise them, and to detect unauthorised changes.
Maintain an inventory of every script on your payment pages, with a written justification for each.Detect unauthorised change to the payment page as received by the browser.Confirm your provider’s responsibilities in writing, and keep the evidence.
Where to start
Work out which of the three patterns you are actually running. We regularly find organisations who believe they are on a hosted page and are not, usually because a second checkout path was added for a campaign and never removed. A short scoping conversation settles it, and the answer changes what you have to evidence.
