Selling Payment Tech to Retailers: Penetration Testing in Your SCA Evidence Pack

Why SCA security assurance decides payment tech deals

SCA security assurance decides deals because the retailer carries the customer relationship if your authentication flow fails, so their security teams push the burden of proof onto you before a contract is signed. It is often the question that stalls or closes a payment tech sale.

Strong Customer Authentication sits at the heart of every card-not-present transaction your product touches.

That proof usually arrives as an evidence pack: certifications, an architecture summary, and independent technical testing of the flows that matter. Vendors with a recent, well-scoped penetration test report of their authentication and payment APIs move through procurement faster; vendors offering only a self-assessment questionnaire face a second round of questions, a delayed start date, or a lost deal.

What SCA actually requires, and what it does not

SCA requires customer-initiated electronic payments to be authenticated with at least two independent factors from knowledge, possession and inherence, with the authentication dynamically linked to the amount and payee for remote card payments. It is mandatory wherever payment rules apply.

Strong Customer Authentication comes from UK payment rules overseen by the FCA and applied across the payment ecosystem.

Here is the honest part. The SCA rules do not contain a clause that says “carry out an annual penetration test”. They demand that authentication is applied correctly, that exemptions such as low-value or transaction risk analysis are used lawfully, and that the authentication mechanism itself holds up: a strong technical-testing expectation rather than a named obligation. Acquirers, payment providers and larger retailers translate that expectation into a concrete ask during onboarding: show us independent testing of your authentication and payment flows.

What retailers expect in an SCA evidence pack

Evidence packs vary by buyer, but for payment tech vendors selling into UK retail a credible pack usually contains:

• A recent penetration test report covering authentication and payment flows, from an independent, accredited firm, with retest evidence for anything high or critical.
• An architecture and data flow summary showing where cardholder and authentication data moves, and which controls sit around it.
• Your PCI DSS status where card data is in scope, plus certifications such as Cyber Essentials Plus or ISO 27001 that show organisational maturity.
• A statement on how SCA exemptions are applied, monitored and change-controlled.
• Vulnerability management and patching evidence, showing the test result reflects an ongoing process.

The penetration test report is the piece buyers scrutinise hardest: it is the only item produced by someone with no incentive to make you look good. If you supply regulated retail or financial services groups, the bar rises further; our guide to cyber security in financial services covers how those buyers assess suppliers.

What the penetration test should cover

SCA-focused testing is not a generic infrastructure scan with a new cover page; it is authentication, API and payment flow testing. When EJN Labs scopes this work for a payment tech vendor, we map the transaction journey end to end and test where an attacker could defeat or sidestep the authentication:

• Authentication logic: factor enrolment, step-up triggers, fallback paths, brute-force and enumeration resistance, and whether dynamic linking can be tampered with between authorisation and capture.
• Exemption and risk-engine abuse: can a request be manipulated to claim a low-value or trusted-beneficiary exemption it should not receive?
• Payment APIs: object-level and function-level authorisation, replay handling, idempotency, webhook authenticity and merchant-facing endpoints. This is classic API penetration testing applied to money movement.
• Mobile SDKs and apps where your product ships one, including token storage, certificate pinning and tamper detection, via mobile application penetration testing.
• The supporting estate: the cloud environment and external perimeter hosting the payment service, because a strong 3DS flow means little if the admin plane is exposed.

One first-hand detail from scoping these estates: the finding that most often worries retail buyers is not a flaw in the cryptography or the 3DS protocol itself. It is business logic, for example an API that lets the transaction amount change after authentication, quietly breaking dynamic linking. Automated scanners miss that class of issue; UK-based testers working through the flow manually find it, which is why we ask for sandbox merchant credentials and a realistic test transaction path during scoping.

How an engagement runs

An engagement runs in four steps: scoping, testing, reporting and a retest of fixed findings. Scoping starts with a short call and a walkthrough of your transaction flows, API documentation and environments, from which the test boundary and day count are agreed in writing.

Testing runs against a production-like environment using agreed merchant and customer test accounts, so real cardholders are never touched, and findings are shared as they are confirmed so critical issues can be fixed while the test is still running. The report serves two audiences: a technical section your engineers can action, and an executive summary your sales team can hand to a retailer’s security reviewer. Our penetration testing checklist walks through what to have ready before day one.

What it costs and how scope drives the price

Pricing is driven by day count, and day count by scope: the number of APIs, whether a mobile app is included, user roles, and whether the cloud estate is in. UK day rates for CREST-accredited testing typically run £1,100 to £1,400:

Scope	Typical days	Typical cost
Authentication and payment API test	4 to 6 days	£4,400 to £8,400
APIs plus mobile app or SDK	6 to 9 days	£6,600 to £12,600
Full payment platform including cloud estate	8 to 12 days	£8,800 to £16,800

These are typical UK ranges rather than a quote; an exact price follows a short scoping call. For a broader view of how UK testing is priced across engagement types, see our guide to penetration testing cost in the UK.

How EJN Labs approaches SCA security assurance

Built around the buyer’s question

We scope from the retailer’s due diligence request backwards. If a prospect has sent you a security questionnaire, share it with us; we shape the test so the report answers the specific questions your buyer is asking. As a CREST-accredited penetration testing firm holding Cyber Essentials Plus, ISO 27001 and ISO 9001, our reports carry weight with acquirer and enterprise security teams, and our own assurance stack mirrors what your buyers expect of you.

Payment flows tested by UK-based testers

All testing is delivered by UK-based testers, which matters when the buyer’s contract restricts where data and access can flow. We test authentication logic, exemption handling and payment APIs manually, chain findings into realistic attack paths, and include a retest so your evidence pack shows issues closed, not just found.

Frequently Asked Questions

Does SCA legally require a penetration test?

No. UK Strong Customer Authentication rules, overseen by the FCA, mandate multi-factor authentication and dynamic linking where payment rules apply, but they do not name penetration testing. A well-scoped independent test is still the accepted way to demonstrate SCA security assurance.

The rules apply across the payment ecosystem, and in practice acquirers, payment providers and retailers demand independent testing of authentication and payment flows as evidence during onboarding.

What should an SCA-focused penetration test cover?

An SCA-focused test should cover the authentication journey and the payment APIs, not just the perimeter. That means factor enrolment and step-up logic, dynamic linking integrity, exemption and risk-engine abuse, API authorisation and replay handling, webhook authenticity, and any mobile app or SDK you ship.

The supporting cloud estate and external perimeter should be included where they host the payment service.

How much does an SCA-focused penetration test cost?

Expect £4,800 to £16,800 depending on scope, at UK day rates of £1,100 to £1,400 for CREST-accredited testing. A focused authentication and payment API test sits at the bottom of that range and a full platform test including the cloud estate at the top.

The focused authentication and payment API test usually takes 4 to 6 days, so £4,400 to £8,400. Adding a mobile app or SDK typically brings it to 6 to 9 days, £6,600 to £12,600, and the full platform including the cloud estate runs 8 to 12 days, £8,800 to £16,800. Exact pricing follows scoping.

How recent does the test in my evidence pack need to be?

Less than 12 months old for most retail and acquirer due diligence teams, and many also expect a retest after any significant change to authentication or payment flows. Annual testing plus change-driven retesting is the pattern that keeps a pack credible.

If your last test predates a major release of your checkout, 3DS integration or exemption logic, buyers may treat it as stale.

Can one test support both SCA assurance and PCI DSS?

Yes, often. If card data touches your platform, PCI DSS Requirement 11.4 requires penetration testing of the cardholder data environment, and much of that scope overlaps with the authentication and API flows retailers ask about for SCA, so a single engagement can be scoped to satisfy both.

The report is structured so each audience finds the evidence it needs. Tell us both requirements at scoping and we will design one test rather than two.

Put a credible test at the front of your evidence pack

If retailers are asking for SCA security assurance and your current evidence is a questionnaire, a focused test of your authentication and payment flows closes that gap quickly. Get a CREST pentesting quote and have the report your next retail deal needs, with a fixed day count and a retest included.