TrueLayer Integration Penetration Testing
TrueLayer confirms the payment, but your backend decides whose account it belongs to and whether to trust the redirect. We test the account binding, token handling, signing and webhook checks around it. CREST-certified testers, fixed price from £3,860 for a 3-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.”
payment_id is the query parameter TrueLayer returns when the user’s browser lands back on your return_uri. It proves the browser came back, not that TrueLayer executed the payment, which only a GET request to the payment resource or a verified webhook can confirm.
A payment_id on your return_uri confirms a browser came back, not that TrueLayer executed the payment
TrueLayer’s hosted payment page sends the user’s browser back to your return_uri with a payment_id in the URL once they finish authorising at their bank. That query parameter is confirmation that a browser came back, nothing more. TrueLayer’s own payment status documentation sets out the actual lifecycle a payment moves through, authorization_required, authorizing, authorized, then a terminal status of executed or settled, and a payment into a merchant account can still fail after it reaches executed. An integration that releases an order the moment the browser lands back on the confirmation page, rather than checking the payment resource or waiting for a verified webhook, is trusting a redirect that proves nothing about whether the money actually moved.
Payments API requests carry their own proof of origin. Every signed request needs a Tl-Signature header, a detached JWS built from the exact method, path and body sent and signed with an ECDSA private key you generate and register against a key ID in Console. TrueLayer’s request signing guide is specific about what breaks it: a body reformatted after signing, a header signed but not sent, or a path that does not match byte for byte. The same signature scheme secures webhooks, and TrueLayer states plainly that an incoming webhook without a verified TL-Signature should never be trusted, since acting on it means accepting whatever payment status an attacker chooses to post.
The Data API side of an integration carries a different risk. An access token is only valid for an hour, and a refresh token only exists if the offline_access scope was requested, so what your integration does once a token expires, and whether a refresh token stays scoped to the customer who granted it, matters as much as the consent screen itself. Where payments run on a mandate for Variable Recurring Payments, the mandate carries its own constraints, a maximum amount per payment, a maximum total and a period, and a payment created against a revoked or expired mandate should never reach the bank. None of this depends on TrueLayer’s platform failing. It depends on what your application does with the tokens, signatures and statuses TrueLayer hands back to it.
SCOPE
What we pen test on a TrueLayer integration
Consent and account-to-user binding
Whether the state value returned to your redirect_uri is checked before an account connection is attached to a customer record, rather than trusted from a client-supplied user ID, and whether the account and identity data the Data API returns can end up linked to a different signed-in user than the one who completed consent.
Access and refresh token handling
Whether access and refresh tokens returned by the Data API are stored server-side rather than in the browser, whether a stored refresh token is still scoped to the customer who granted consent, and what your integration does once the one-hour access token expires or the customer revokes their connection.
Redirect and callback handling
Whether return_uri and redirect_uri values are restricted to the exact Allowed Redirect URIs registered in Console rather than accepted from an open parameter, and whether the outcome of a payment or a Data API consent is decided by anything in the query string TrueLayer redirects the user back with.
Request signing (Tl-Signature)
How the ECDSA private key used to sign Payments API requests is generated, stored and rotated, whether the Tl-Signature is built from the exact method, path, headers and body actually sent, and whether Idempotency-Key values are unique per request rather than reused across different payments.
Webhook signature verification
Whether the webhook endpoint verifies the TL-Signature header against TrueLayer’s published keys before acting on a payment_executed, payment_authorized or mandate event, and whether it can safely receive the same webhook more than once, since TrueLayer does not guarantee single delivery.
Payment-state verification before fulfilment
Whether your backend confirms a payment’s actual status with a GET request to the payment resource or a verified webhook before releasing goods, services or an account credit, rather than treating the browser’s arrival back at your return_uri as proof that TrueLayer executed the payment.
Client ID and secret handling
Whether the client secret used to exchange an authorisation code or refresh an access token has reached client-side code or a public repository, and whether sandbox client credentials, which TrueLayer prefixes distinctly from live ones, are kept separate from your production configuration.
Mandates and Variable Recurring Payments
Where VRP is used, whether a recurring payment is checked against its mandate’s period, per-payment and total constraints before submission, and whether a payment can still be created against a mandate that has been revoked or has expired.
Sandbox and live environment separation
Whether sandbox and live base URLs, client credentials and signing keys can be mixed up in configuration, and what your integration does if a sandbox payment or webhook event, identifiable by its mock provider ID, is posted to an endpoint expecting live traffic.
Account and payment data retention
What your application stores from Data API and Payments API responses, such as account identifiers, balances, transaction history and payer account details, how long it is retained once a connection or payment no longer needs it, and who inside your application can access it.
OUR PROCESS
TrueLayer Integration Penetration Testing: From Scope to Attestation
Map the integration
We catalogue every TrueLayer touchpoint in scope: the Data API consent flow, Payments API request signing, the webhook endpoint, and mandate creation if Variable Recurring Payments are used.
Provision sandbox connections and payments
We work from TrueLayer sandbox credentials, mock bank providers and sandbox mandates so redirect, signing and webhook checks run against real flows without moving real money.
Exploit consent, redirect and payment-state logic
CREST-certified testers attempt account-binding bypass, redirect and state tampering, forged or replayed webhooks, and fulfilment triggered before a genuine payment status is reached.
Reporting and retest
Executive summary, technical report with CVSS scores and reproduction steps, a walkthrough call, and a free retest once fixes are in place.
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 TrueLayer 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 TrueLayer Integration Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 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 TrueLayer 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 TrueLayer 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 to test our TrueLayer integration?
A sandbox Console application with its own client_id and client_secret, a signing key pair registered against that application, and sandbox bank connections or mock providers covering the flows in scope. We do not need your live client secret or private signing key; sandbox credentials are enough to test consent, signing, webhooks and payment logic.
Does this touch our live bank connections or move real money?
No, wherever the check allows. TrueLayer’s sandbox environment mirrors the live API at a separate base URL and includes mock bank providers that let us test authorisation, payments and mandates without moving real money or needing the KYC checks the live environment requires. Anything that genuinely needs the live environment is agreed with you first and scoped tightly.
Are you testing TrueLayer itself?
No. TrueLayer runs its own vulnerability disclosure programme covering its own production platform and domains, and that is out of scope for us. We test your integration: the consent and account binding, token handling, signing, webhooks and payment-status checks your team built around it.
How long does a TrueLayer integration test take?
A single-integration scope like this one starts at 3 testing days, with results delivered around 5 working days after kickoff. Multiple markets, a Variable Recurring Payments mandate flow, or a second open banking provider alongside TrueLayer add testing days, which we confirm once we see your integration.
What is out of scope?
TrueLayer’s own authorisation servers, banking connections and payment rails, and the receiving or sending bank’s own security, are out of scope. We focus on how your application handles consent and account binding, tokens, request and webhook signing, redirects, and payment or mandate status.
We only use the Data API for account information, not payments. Is there still something to test?
Yes. Consent and account binding, access and refresh token handling, redirect and state validation, and client secret handling all apply to a Data API-only integration regardless of whether you also take payments through TrueLayer.
Do you test our webhook endpoint specifically?
Yes. We check that it verifies the TL-Signature header against TrueLayer’s published keys, rejects unsigned or tampered deliveries, and handles receiving the same payment or mandate webhook more than once, since TrueLayer does not guarantee single delivery of each notification.
Does TrueLayer have a policy on this kind of testing?
TrueLayer’s sandbox is designed for autonomous, unattended testing without the KYC checks the live environment requires, which is why we run signing, webhook, consent and payment logic checks against it. We confirm TrueLayer’s current developer terms for your account during scoping, since any live-environment exception has to sit within whatever TrueLayer currently permits for your integration.
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 TrueLayer integration
TrueLayer confirms the payment, but your backend decides whose account it belongs to and whether to trust the redirect. We test the account binding, token handling, signing and webhook checks around it. CREST-certified testers, fixed price from £3,860 for a 3-day single-integration scope, quoted within 24 hours.
