PCI-compliant payment flows
Raw card details passing through enterprise systems expand audit scope and expose more infrastructure to PCI DSS controls. PCI DSS compliance orchestration uses hosted payment fields and isolated iFrames to keep cardholder data outside merchant environments.
- Category
- Security
- Capabilities
- 10
- Available on
- All plans
Cardflo ensures PCI-compliant payment flows for all transactions, mitigating security risks and safeguarding sensitive cardholder data. Our platform integrates directly with your systems, providing a secure environment from payment initiation to authorisation.
Achieve and maintain regulatory adherence without operational burden.
PCI scope is minimised through hosted fields and network tokens, and sensitive credentials never touch your servers. Strong Customer Authentication is applied intelligently to keep both regulators and conversion teams happy.
PCI-compliant payment flows overview
PCI-compliant payment flows are the structured pathways through which sensitive cardholder data moves from the point of entry to the acquiring bank and payment schemes. These flows are governed by the Payment Card Industry Data Security Standard (PCI DSS), a set of technical and operational requirements designed to protect account information.
In a typical online environment, a payment flow must ensure that Primary Account Numbers (PANs) and sensitive authentication data are either encrypted or substituted with tokens before they touch the merchant server.
By utilising specific integration methods such as hosted fields or iframes, merchants can reduce their compliance scope, shifting the burden of protecting raw data to a Level 1 service provider.
This architecture minimises the risk of data breaches while ensuring that internal systems only interact with non-sensitive identifiers, facilitating secure authorisation and settlement without the merchant directly storing prohibited data elements.
How PCI-compliant payment flows works
Data capture and encryption
When a customer enters their card details into a checkout form, the sensitive data is captured via an iframe or hosted field. This ensures the raw information is encrypted at the point of entry before it reaches the merchant server, redirecting the payload directly to a secure vaulting environment for processing.
Tokenisation of cardholder information
The secure environment replaces the primary account number with a non-sensitive token. This token acts as a unique identifier for the transaction, allowing the merchant to perform subsequent actions like captures or refunds without ever coming into contact with the actual card data, thereby maintaining a restricted compliance scope.
Authorisation and transmission
The encrypted transaction details are transmitted to the acquirer and the relevant payment schemes. During this stage, the flow adheres to secure protocols to prevent interception. The issuer evaluates the request, and the authorisation response is passed back through the gateway to the merchant to finalise the order.
Audit and logging procedures
Throughout the transaction lifecycle, every interaction is recorded in a secure audit trail. These logs track access and system changes without storing sensitive data. Regular scans and assessments ensure the flow remains compliant with current PCI DSS versions, identifying potential vulnerabilities before they can be exploited by external actors.
Why PCI-compliant payment flows matters
Reduction of Compliance Scope
Implementing structured PCI-compliant flows significantly reduces the number of controls a merchant must implement and audit annually. By using hosted interfaces, a business may qualify for a Self-Assessment Questionnaire (SAQ) A rather than the more rigorous SAQ D. This transition minimises operational overhead, reduces the cost of annual assessments, and allows internal technical teams to focus on core product development rather than complex cryptographic management.
Mitigation of Financial Risk
Data breaches involving cardholder information carry substantial financial penalties, including scheme fines, increased transaction fees, and potential suspension of merchant IDs. Compliant flows isolate sensitive data from the merchant's internal network, ensuring that even if a server is compromised, the attackers cannot access raw credit card numbers. This defensive posture is critical for maintaining long-term stability and protecting the balance sheet from unpredictable litigation and remediation costs.
PCI-compliant payment flows use cases
SAQ A retail checkout
Enterprise retailers seeking SAQ A eligibility must prevent checkout pages, tag managers and commerce servers from receiving primary account numbers or security codes. Cardflo provides hosted fields within isolated iFrames, while its acquirer partners receive payment data through PCI DSS Level 1 controlled infrastructure that reduces the merchant’s assessment scope.
Script interception containment
Merchants with heavily customised checkouts face data interception risk when third-party scripts, analytics tags or compromised JavaScript can alter card-entry components. Cardflo isolates sensitive inputs in hosted iFrames and supports controlled integration patterns that keep raw cardholder data outside the merchant’s document object model, application logs and web infrastructure.
SaaS platforms reducing PCI scope
Enterprise groups operating multiple brands often inherit different checkout implementations, creating inconsistent PCI DSS evidence, change controls and card-data boundaries. Cardflo supplies a standard hosted-fields pattern across commerce estates, helping security teams document one controlled collection workflow and keep participating merchant systems within the intended SAQ A scope.
Call centre payment isolation
Call centres taking card details during assisted sales risk exposing primary account numbers through agent desktops, CRM fields, screen recordings and support logs. Cardflo enables isolated hosted payment forms that agents can guide without merchant applications handling raw cardholder data, supporting PCI DSS scope reduction for contact-centre systems and operational controls.
PCI-compliant payment flows by the numbers
This represents an industry-typical reduction in annual audit and management costs when moving from full server-side processing to a hosted payment flow that reduces SAQ scope.
Industry security reports suggest that isolating cardholder data from merchant networks can prevent the vast majority of common data theft scenarios during a server compromise.
Typical timeframe for a development team to integrate a compliant hosted-field solution compared to months for building and certifying a custom, secure vaulting system.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with PCI-compliant payment flows
- Implementation of TLS 1.2 or higher for all transit of sensitive transaction information.
- Restriction of physical and digital access to cardholder data based on business need-to-know.
- Use of hardware security modules for the generation and storage of cryptographic keys.
- Regular internal and external vulnerability scanning of all network perimeters and systems.
- Requirement for multi-factor authentication for all administrative access to the payment environment.
- Automated detection and prevention of unauthorised modifications to the payment page code.
- Strict prohibition of storing sensitive authentication data such as CVV2 or PIN blocks.
- Maintenance of a comprehensive information security policy that addresses all PCI DSS requirements.
- Formalised incident response plans to address potential data breaches or security anomalies.
- Rigorous testing of security systems following any significant changes to the payment infrastructure.
A short scoping call, then a written plan for your MIDs.
Questions about PCI-compliant payment flows
What is the difference between PCI DSS Level 1 and other compliance levels?
PCI DSS compliance is divided into levels based on transaction volume. Level 1 is the most stringent, typically for merchants processing over 6 million transactions annually or any merchant that has suffered a data breach.
It requires an annual Report on Compliance (ROC) performed by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV). Other levels may allow for a Self-Assessment Questionnaire (SAQ).
Regardless of the merchant's level, the underlying payment flow must adhere to the same technical security standards.
How does tokenisation help in maintaining PCI compliance for recurring billing?
Tokenisation replaces the primary account number (PAN) with a surrogate value known as a token. In a compliant payment flow, the merchant only stores the token and the card's expiry date.
Because the token cannot be used to reconstruct the original PAN, the merchant's storage systems are largely removed from the scope of PCI DSS controls.
This allows for secure Merchant Initiated Transactions (MITs) for subscriptions while ensuring that the actual sensitive data remains in a hardened, third-party vault.
Can I use an API integration and still be PCI compliant?
Yes, but direct API integrations where card data passes through the merchant's server require the merchant to meet more rigorous PCI DSS requirements, usually SAQ D. This involves extensive documentation and security controls for the merchant's server environment.
To minimise this, many organisations use 'hosted fields' or 'elements' where the input fields are hosted by the PSP, ensuring the data never touches the merchant's infrastructure despite appearing as a native part of the checkout page.
What happens if a merchant does not maintain a PCI-compliant flow?
Non-compliance exposes a business to significant risks, including monthly fines from card schemes and the potential loss of the ability to process card payments entirely.
In the event of a data breach, a non-compliant merchant is liable for the costs of card replacement, forensic audits, and legal settlements. Acquirers may also increase the transaction fees for non-compliant merchants to offset the perceived risk to the payment ecosystem.
Do these compliant flows cover both online and in-person payments?
Yes, PCI compliance applies to all channels, though the technical requirements differ. For online flows, the focus is on web application security and encryption in transit.
For in-person payments, flows must involve PCI-validated Point-to-Point Encryption (P2PE) solutions, ensuring the card data is encrypted within the hardware terminal before it ever reaches the Point of Sale (POS) software or the local network.
Is CVV storage allowed if it is for the purpose of a refund?
No, the PCI DSS strictly prohibits the storage of Sensitive Authentication Data (SAD), which includes the CVV or CVC code, after authorisation. This applies even if the data is encrypted.
For refunds or subsequent transactions, the original authorisation's ARN (Acquirer Reference Number) or a transaction ID provided by the gateway should be used to link the new request to the original payment, rather than re-using CVV data.
Related features.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.