Fraud Controls
Checkout security and access
Map who can change checkout, review staff and app access, keep payment data out of logs and prepare to investigate unexpected changes.
Secure checkout means identifying who and what can change the buying path, limiting that access and noticing unexpected changes.
Start with the store's actual pages, payment provider, apps and staff roles. A provider-hosted payment page can reduce the merchant's card-data work, but the merchant still needs to protect its own pages and accounts.
Map what can affect payment
Trace the buyer's path from cart to payment outcome. Record each page, script, app, API connection and payment endpoint.
Include systems that set the payable amount and update the order. A changed discount rule or order-status handler can matter even when the card form is untouched.
For each component, record its purpose and whether it can affect payment security, including components outside the visible checkout page. Keep an inventory of expected payment-page scripts and their purpose.
PCI DSS includes controls for authorising scripts, checking integrity and detecting tampering. The requirements that apply to a merchant depend on its implementation and assessment route.
Include embedded payment boundaries
Do not define the checkout boundary only by the merchant's page URL. PCI Security Standards Council guidance also covers webpages that can affect e-commerce payment security through embedded iframes.
Record the merchant page that embeds a payment frame and the provider-operated payment component.
Limit and review access
Use individual staff accounts where the platform allows them. Give checkout editors, developers, support and finance staff the access their duties require.
Review privileged access when duties change or someone leaves. Enable suitable multi-factor authentication for administrative accounts and include emergency access in the review.
Treat app access as part of the same inventory. An app that needs order data may have no reason to change checkout settings.
Record its business owner, granted permissions, data access and continuing purpose. Review its access when its permissions or work change.
| Control point | Question for the owner |
|---|---|
| Staff access | Who can publish or configure checkout changes? |
| Apps and integrations | Which services can read order data or alter the buying path? |
| Payment-page code | Which scripts are expected, and who approved them? |
| Logs and alerts | Who receives and investigates a change alert? |
| Recovery | Which approved configuration can be restored, and who authorises it? |
Confirm responsibility for each component
PCI DSS is a baseline of technical and operational requirements for protecting payment account data. Its intended audience includes entities that store, process or transmit cardholder data or sensitive authentication data, and entities that could affect the security of the cardholder data environment. This includes merchants and service providers.
For each component, record who operates it, who can change it, how an unexpected change would be noticed, and how an approved configuration could be restored. Add the relevant provider or internal team alongside the merchant owner.
At the boundary between merchant and provider systems, note who can change the merchant page, embedded frame, scripts or security-impacting HTTP headers. For externally operated components, note who can make changes and how the merchant can raise an unexpected change.
This makes access ownership visible even when the merchant does not administer the underlying system.
The PCI Security Standards Council does not enforce compliance or decide whether a particular implementation is compliant. For questions about validation or reporting responsibilities, work with the organisation managing the compliance program, such as an acquirer or payment brand.
Keep useful records without copying payment data
Logs should help staff reconstruct a change or payment error. Record the event, time, component, outcome and an appropriate order or provider reference.
Avoid copying payment request bodies, card details, verification codes, credentials and access tokens. Check error reporting, debugging tools and third-party monitoring as well as the main application log.
Card verification codes must not be stored after authorisation, even if encrypted. Masking a card number on a staff screen does not establish that a full number was never stored in a log or file.
Prepare for an unexpected change
Assign an investigator for an unfamiliar script, app grant or checkout setting. Make the approved configuration, change history and provider contacts available to that person.
Plan how to pause an affected route while preserving relevant evidence as far as practicable.
An unfamiliar change is a reason to investigate, not proof of a data breach. Establish what changed, when it operated, which checkout routes were affected and whether information may have been exposed. Seek payment-security, incident-response or privacy advice when the facts warrant it.
Review access and components on a schedule the store can maintain. After a release, compare the live checkout with its approved configuration, confirm alerts reach an owner, and record exceptions with owners and due dates.
For payment pages, include security-impacting HTTP headers in the approved configuration alongside expected scripts. PCI DSS v4.x Requirements 6.4.3 and 11.6.1 address script authorisation, integrity checks and tamper monitoring, as well as careful management of those headers.
A check should account for the page as customers see it, not only the server-side configuration. PCI Security Standards Council guidance addresses unauthorised changes in the server environment and in the page rendered in the customer's browser. Record which view was checked and which owner follows up any mismatch.
Critical PCI DSS requirements for Australian merchants
- Requirement 6.4.3
- Script authorisation and integrity checks
- Requirement 11.6.1
- Tamper monitoring and detection
- Prohibited data retention
- Card verification codes must not be stored post-authorisation
- Log hygiene
- Avoid copying card numbers, CVVs, tokens
- Incident response readiness
- Assign investigator for unauthorised changes
In this guide
- Keeping sensitive payment data out of application logsDesign useful checkout logs without collecting card details, credentials or raw payment requests, and respond if sensitive data appears.
- Reviewing checkout permissions for third-party appsInventory checkout apps, compare granted access with each app’s job, and plan safe permission changes or removal.
- Planning a response to suspicious checkout changesSet incident triggers, preserve evidence, contain an affected checkout path and verify restoration without guessing the scope of exposure.
- Checking current security obligations with qualified specialistsPrepare a checkout data-flow brief and ask the right PCI, payment and Australian privacy specialists for an account-specific decision.
