Use case · Payments & BNPL
Protecting payment data from checkout to settlement
Card numbers, bank details and identity documents pass through checkouts, gateways, fraud tools and support systems. CCL keeps them sealed until the service that needs them.
- Card numbers
- Bank details (IBAN)
- Identity documents
- Income and affordability data
The challenge
Where the data goes today.
Payment and buy-now-pay-later providers collect some of the most valuable data there is, at the busiest point in the customer journey. It then moves through a chain of systems: checkout pages, gateways, fraud and credit checks, payment processors, customer support and reporting.
Each of those systems is usually able to read the data, even when it only needs to move it. Every one adds to the attack surface and to the scope of what has to be secured and audited.
Where it’s readable
- Checkout pages shared with third-party scripts
- Gateways and load balancers where TLS ends
- Fraud, credit and onboarding services that pass full records between them
- Logs and monitoring that capture request bodies
- Support tools with broad access to customer records
How CCL applies
The same journey, sealed where it doesn’t need to be read.
- CheckoutBrowser SDK
Card and bank fields are sealed in the browser before they are sent, so no network hop, gateway or intermediate service can read them.
- EdgeGateway
Payment requests are validated and routed while the data stays sealed.
- Internal servicesBroker
Only the payment or credit service you authorise receives the data it needs to act on.
- RecordsProtected Storage
Stored credentials and onboarding documents are sealed again at rest.
What changes
The outcome.
Fewer systems see card data
Reducing the number of systems that can read cardholder data is the core of PCI DSS scope reduction. Your assessor decides final scope.
A breach stays contained
A compromised gateway, log store or support tool does not automatically expose customer payment details.
Evidence for regulators and due diligence
A clear, explainable data protection architecture for regulators, banking partners and merchants, including under DORA where it applies to you.
CCL is in development. This use case describes how the v1.0 design is intended to apply.
Related insights
Where your customers' data is exposed today
Encrypted in transit, encrypted at rest. Follow one piece of customer data through your stack and count how often it is neither.
- Data exposure
- Architecture
AI agents and payment data: who is really asking?
Software agents are starting to shop and pay on people's behalf. That raises two separate questions, and they need two separate answers.
- AI
- Payments
- Authorisation
Post-quantum: what actually changes for payments
The new standards are published and the migration clock is running. What changes, what doesn't, and the one design property that matters most.
- Quantum
- Payments
- Crypto-agility
Contact
Get in touch.
Whether you’re exploring how to protect your clients’ data, interested in CCL, or want to work with us, we’d like to hear from you.