Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
Checkout.com is a global payment processor (headquartered in the UK) that provides merchants with card payment processing, fraud prevention and risk scoring. It loads a JavaScript SDK onto the checkout page to securely collect card data and perform real-time fraud analysis. Payment-session cookies and device fingerprinting are strictly necessary for completing a transaction and are exempt from consent under the ePrivacy Directive. However, broader fraud profiling beyond the checkout session may require a separate legal basis. Data flows to UK and global (including US) infrastructure.
Checkout.com is a global payment processor headquartered in the United Kingdom. It provides merchants with a complete payment stack: card acquiring, alternative payment methods, fraud prevention and risk scoring. When a customer reaches the checkout page of a merchant using Checkout.com, a JavaScript SDK is loaded from checkout.com or cko.com domains. This SDK securely collects card data within an iframe or hosted payment page, encrypts it and sends it directly to Checkout.com's payment infrastructure, keeping raw card numbers off the merchant's servers in line with PCI DSS requirements. Checkout.com is not a shopping cart or e-commerce platform; it is purely a payment processing and fraud-prevention service.
Checkout.com sets session cookies and may perform device fingerprinting as part of its fraud-prevention and 3D Secure authentication flows. Session-scoped cookies are used to maintain the integrity of the payment session (e.g. correlating the payment attempt with the authorisation response) and to support Strong Customer Authentication (SCA) required under PSD2. Device fingerprinting collects browser and device attributes to generate a risk signal; this data is processed by Checkout.com's fraud-scoring engine. Cookies set during the payment transaction itself are strictly necessary for the secure completion of that transaction.
For cookies and fingerprinting that are strictly necessary to complete a payment transaction initiated by the user, the legal basis is performance of a contract (Art. 6(1)(b) GDPR) and the ePrivacy Directive's strictly-necessary exemption applies (Art. 5(3) ePrivacy). These do not require consent. However, if Checkout.com's JavaScript is loaded on pages outside the direct checkout flow (e.g. product pages, account dashboards) and performs background fraud-signal collection on visitors who are not actively making a payment, this goes beyond strictly necessary processing. Such broader profiling would require either a documented Legitimate Interests Assessment (LIA) under Art. 6(1)(f) GDPR or explicit user consent, depending on the nature and intrusiveness of the data collected.
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
Checkout.com's primary operations are in the UK. The UK has an EU adequacy decision, so personal data transferred to Checkout.com's UK servers does not require additional safeguards. For processing on US or other global infrastructure, Checkout.com relies on Standard Contractual Clauses (SCCs) or the EU-US Data Privacy Framework (DPF). Merchants should verify Checkout.com's current DPA and transfer mechanism documentation, update their Art. 30 records accordingly, and reference the applicable safeguards in their privacy notices.
Checkout.com is regulated as a payment institution and operates under PSD2 for EU transactions and equivalent UK FCA rules. Strong Customer Authentication (SCA) mandated by PSD2 requires additional verification steps (two-factor authentication) for most online card payments. Checkout.com's 3DS (3D Secure) integration fulfils this requirement. The data processed for SCA purposes, including device binding and authentication signals, is necessary under financial regulation and does not require GDPR consent. Merchants should nonetheless explain SCA processing in their privacy notices and ensure their Data Processing Agreement (DPA) with Checkout.com is signed and up to date.
Sign a Data Processing Agreement with Checkout.com. Update your privacy notice to name Checkout.com as a payment processor, describe the data processed (card-holder name, card details, IP address, device data), reference the UK adequacy decision and note the SCCs or DPF for US transfers. If you deploy Checkout.com's JS beyond the checkout page, document your Legitimate Interests Assessment. Do not list Checkout.com's strictly-necessary payment cookies in your consent management platform as requiring consent; doing so would incorrectly imply payment processing is optional. Audit your integration annually against any changes to Checkout.com's SDK or data processing terms.
Websites using Checkout.com must obtain user consent under GDPR regulations.
DPIA considerations
A DPIA is unlikely to be required for standard payment processing use of Checkout.com, as the data processing is necessary for the performance of a contract and the volumes involved are not typically large-scale in the Art. 35 GDPR sense. However, if Checkout.com's fraud-profiling SDK is deployed across multiple pages beyond the checkout (behavioural profiling of non-transacting visitors), a DPIA should be considered. Document the processing in your Art. 30 records, noting the UK adequacy decision for Checkout.com's primary infrastructure and SCCs/DPF for US-side transfers.
Sample consent text
Checkout.com is our payment processor. When you proceed to payment, Checkout.com loads its payment SDK to securely handle your card details and perform fraud prevention checks. This is strictly necessary to complete your purchase and does not require your separate consent. For more details, see our privacy notice.
Third-party domains contacted
checkout.comapi.checkout.comcko.comCookies placed
| Name | Type | Duration | Purpose |
|---|---|---|---|
| Payment session cookie | session | Session | Maintains the integrity of the payment session between the customer browser and Checkout.com's payment infrastructure, linking the payment attempt to the authorisation response. |
| 3D Secure authentication cookie | session | Session | Supports the 3D Secure (3DS) Strong Customer Authentication flow required by PSD2, correlating the authentication challenge with the payment authorisation. |
| Fraud-risk signal cookie | persistent | Up to 1 year | Stores device and browser attributes used by Checkout.com's fraud-scoring engine to assess transaction risk and flag potentially fraudulent payment attempts. |
Checkout.com is an essential service, but transparency matters. Manage all your consent with FlowConsent.
Checkout.com sets session-scoped cookies during the payment process to maintain the integrity of the payment session and support 3D Secure authentication. It may also perform device fingerprinting to generate fraud-risk signals. These cookies are strictly necessary for the secure completion of a payment transaction and are not advertising or analytics cookies. They are typically short-lived (session duration or a few hours) and expire once the transaction is complete. The exact cookie names may vary by integration; inspect your checkout page with browser developer tools to see the current set.
No, for standard payment processing. Cookies and device signals that are strictly necessary to complete a payment transaction the user has initiated are exempt from the consent requirement under Art. 5(3) of the ePrivacy Directive. You do not need to present a cookie banner consent option for Checkout.com's payment cookies. However, if Checkout.com's JavaScript is loaded on non-checkout pages (e.g. for background fraud profiling of all site visitors), that broader use may require a separate legal basis or consent.
For payment transaction processing, the legal basis is performance of a contract (Art. 6(1)(b) GDPR): the user has requested the purchase and the payment must be processed to fulfil it. For fraud prevention during the transaction, this is also covered by Art. 6(1)(b) and by the controller's legal obligations (Art. 6(1)(c)) under PSD2 and anti-fraud regulations. If Checkout.com is used for broader behavioural fraud profiling beyond the transaction, Legitimate Interests (Art. 6(1)(f)) may apply, but requires a documented Legitimate Interests Assessment.
Yes. Checkout.com's primary operations are in the UK, which benefits from an EU adequacy decision. For processing on US or global infrastructure, Checkout.com uses Standard Contractual Clauses (SCCs) or the EU-US Data Privacy Framework (DPF). You should obtain and retain a copy of Checkout.com's Data Processing Agreement (DPA), which documents the applicable transfer mechanisms, and reference this in your privacy notice.
A DPIA is not typically required for standard Checkout.com payment processing, as the data processing is necessary for the performance of a contract and does not inherently involve large-scale profiling or high-risk processing in the Art. 35 GDPR sense. However, if you deploy Checkout.com's SDK across your entire website for passive fraud profiling of all visitors (not just those transacting), you should conduct a DPIA given the scale and intrusiveness of the processing. Record your analysis in your Art. 30 register.
Sign the Data Processing Agreement (DPA) provided by Checkout.com. Update your privacy notice to name Checkout.com, describe the purpose (payment processing and fraud prevention), list the categories of data processed, identify the data transfers to the UK and US, and cite the applicable safeguards (UK adequacy, SCCs or DPF). Do not include Checkout.com's strictly necessary payment cookies in your cookie consent layer. Keep your integration scoped to the checkout page unless you have a documented legal basis for broader deployment. Review the DPA and SDK documentation annually.
Alternatives include Adyen (Netherlands, strong EU data residency), Stripe (US, with EU data processing options and SCCs), Mollie (Netherlands, EU-focused), and Worldpay (UK/US, similar risk profile to Checkout.com). All major payment processors have similar data transfer considerations; the key compliance differentiator is the strength of their DPA, the availability of EU-side processing, and their SCA compliance record. Evaluate alternatives based on your specific geographic and processing needs.
In your cookie policy or privacy notice, include a section on payment processing cookies. Name Checkout.com as the payment processor, describe the cookies as strictly necessary for completing a card payment transaction, state that they do not require consent, and note that they are typically session-scoped and expire after the transaction. Reference the data transfer to the UK (adequacy decision) and any US processing (SCCs or DPF). Link to Checkout.com's own privacy policy for further detail on their data processing practices.