Checkout.com Integration Penetration Testing
Checkout.com authorises the card, but your webhook listener decides when the order is paid and fulfilled. We test the keys, signatures, captures and refund logic behind that decision. CREST-certified testers, fixed price from £3,040 for a 2-day single-integration scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Checkout.com splits access across a public key for the browser, a secret key for your server, and OAuth access keys with their own scopes for services such as Payouts. An integration is only as safe as the most widely scoped key it exposes.
Why the risk sits in your keys and webhooks, not Checkout.com’s platform
Checkout.com separates access by key type. A public key sits in your front-end code and can only reach a limited set of client-side APIs, while a secret key sits on your server and can reach most of the Payments API; a single account can also be split into several secret keys, each scoped to just the APIs it needs. Checkout.com’s key documentation is clear that a secret key’s value is shown only once, at creation, so how your team stores and rotates it matters as much as where it is used.
A separate class of credential, the OAuth access key, is used for services such as Payouts, and any scope you request at token time has to be a subset of what that access key was actually granted when it was created. Your webhook listener carries its own risk: Checkout.com signs every notification with a Cko-Signature header, and Checkout.com’s webhook setup guide is specific that verifying it means hashing the raw request body with your webhook signature key, since re-serialising the payload first can change it enough to break the check.
None of this is a flaw in Checkout.com’s platform. It comes down to how your integration stores its keys, verifies a signature, and decides whether a capture, refund or 3D Secure result is genuine before it changes an order’s state, and that is what we test.
SCOPE
What we pen test on a Checkout.com integration
Secret and public API keys
Whether your public key, used client-side, is limited to the APIs it needs, whether your secret key ever reaches browser code, and how a team running several integrations splits access across multiple scoped secret keys rather than one key that can reach every API.
OAuth access keys and scopes
For OAuth access keys used against services like Payouts, whether the scopes requested at token time are the minimum your integration needs, and whether an access key created with broad scopes gets reused for a task that only needed a narrow one.
Webhook signature verification
Whether your listener checks the Cko-Signature header against an HMAC computed from the raw request body using your webhook signature key, rather than trusting whatever event_type and payload the request claims to carry.
Payment state and idempotency
Whether a repeated webhook, or a retried request carrying the same Cko-Idempotency-Key, can trigger a second fulfilment, and what your order state machine does with a payment event that arrives out of sequence or twice.
Amount and currency integrity
Whether the amount your integration sends to Checkout.com is recomputed server-side from your own order and cart data rather than trusted from the browser, and how minor units, currency codes and decimal precision are handled between quote and payment.
Capture and refund authorisation
Who can trigger a capture or refund against a payment ID, whether the capture_type and amount are validated against what was actually authorised, and whether one authenticated customer can act on another customer’s payment.
Customer and instrument ownership
Whether a stored customer or payment instrument ID returned by Checkout.com is checked against the authenticated session before it is reused, so a saved card cannot be charged, or a customer record read, by anyone other than its owner.
Flow, Frames and Hosted Payments Page
How your integration builds and validates the token or session it hands to Flow, whether a Frames-based integration still in use is treated with the same scrutiny now that Frames itself is deprecated, and how return and redirect handling from the Hosted Payments Page is checked.
3D Secure handling
Whether your integration ever sets attempt_n3d to bypass 3D Secure, what that trade-off costs you in liability shift if a chargeback follows, and how a completed or failed authentication result is checked before an order proceeds.
Sandbox and production separation
Whether sandbox keys and test card data can reach the production environment or vice versa, and what your integration does if a sandbox event, which carries lower rate limits and is not meant for load testing, is posted to the endpoint that expects live traffic.
OUR PROCESS
Checkout.com Integration Penetration Testing: From Scope to Attestation
Map the integration
We list every Checkout.com touchpoint in your application: payment creation, capture, webhooks, refunds and any stored payment methods, and confirm which keys and access tokens belong to sandbox and which belong to production.
Test against your sandbox
Payment, webhook, capture and refund logic is tested against your Checkout.com sandbox account using test cards wherever the check allows; anything that genuinely needs production is agreed with you first and run read-only.
Chain the business logic
CREST-certified testers chain findings across your keys, webhooks, capture and refund logic, covering forged signatures, replayed events, scope creep on access keys and instrument ownership gaps rather than relying on scanner output alone.
Report and retest
Executive summary, technical report with CVSS scores and reproduction steps, a walkthrough call, free retest after remediation, and an attestation letter.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Checkout.com pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Checkout.com Integration Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Checkout.com For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Checkout.com Integration Penetration Testing
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need?
A sandbox secret and public key pair for the integration under test, and if your integration uses OAuth access keys, a sandbox access key ID and secret carrying the same scopes as production. We do not need your live Dashboard login, and only need scoped, read-only production access where a specific check requires it.
Does this touch live Checkout.com payments or real card data?
No, wherever the check allows. Checkout.com’s sandbox mirrors the live Payments API and accepts test cards instead of real card data, so we can run payments, captures, refunds and webhook events without moving real money. Anything that must run against production is agreed with you in advance and scoped tightly.
How long does a Checkout.com integration test take?
A single integration is a 2-day scope. Multiple Checkout.com products in the same checkout, a custom Frames or Flow build alongside a Hosted Payments Page, or a second payment provider running in parallel add testing days, which we agree before the engagement starts.
We use the Hosted Payments Page, not a custom Flow or Frames integration. Is there still anything to test?
Yes. The hosted page removes some client-side risk, but payment creation, the return handling, your webhook listener and your capture or refund logic are still your code, and that is where the risk sits regardless of which front end collects the card details.
What is out of scope?
Checkout.com’s own infrastructure, acquiring relationships and fraud engine. We test the integration your team built: your key handling, your webhook endpoint, your capture and refund authorisation and your instrument ownership checks, never Checkout.com’s platform itself.
Does Checkout.com have a policy on this kind of testing?
Checkout.com’s sandbox environment is intended solely to test the functional aspects of an integration, uses test cards in place of real card data, and applies lower rate limits so it is not suitable for load testing. We test against your sandbox for exactly that reason, and confirm Checkout.com’s current terms for any production-facing check with you directly during scoping.
Do you test Flow, Frames and the Hosted Payments Page the same way?
We scope in whichever your integration actually uses. Frames was Checkout.com’s older client-side library and was deprecated on 30 June 2026 in favour of Flow, so if your integration has not migrated yet, we test what is actually live rather than assuming it has moved.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Checkout.com integration
Checkout.com authorises the card, but your webhook listener decides when the order is paid and fulfilled. We test the keys, signatures, captures and refund logic behind that decision. CREST-certified testers, fixed price from £3,040 for a 2-day single-integration scope, quoted within 24 hours.
