Skip to main content

New: AI Privacy Impact Assessments for teams shipping AI features. Learn about AI-PIAs

Pen testing · Fintech & financial services

Penetration Testing for Payment Processors & PayFacs

Penetration testing shows a processor or PayFac exactly how its cardholder data environment, sub-merchant onboarding APIs and merchant portal hold up against a realistic attacker, then proves the segmentation separating the CDE from the rest of the business actually works. Testing here answers to two audiences at once: your QSA validating PCI DSS v4.0.1, and a sponsor acquirer's due-diligence team reading the report before renewing your facility. Most engagements land ahead of a ROC deadline, a new acquirer relationship, or after a card-brand-mandated review.

Reviewed by the Privacy Horizon team · Last reviewed

What you're protecting

The systems a payments pen test has to reach

A test that only touches the marketing site misses where the money and the cardholder data actually move. Six environments deserve deliberate scoping.

The cardholder data environment end to end

The tokenization vault, HSMs and any P2PE terminal links running through processors such as Moneris, Global Payments or Elavon make up the CDE a QSA will walk end to end.

Segmentation between the CDE and corporate network

The boundary separating your card-data systems from everyday corporate tools, laptops, the ticketing platform, back-office SaaS, because a flat network turns one phished employee into a full CDE compromise.

Sub-merchant onboarding and KYB intake

The APIs and web forms collecting owner identification, banking documents and void cheques at merchant signup, tested for authorization flaws that let one applicant see another's file.

The merchant support portal

Login, session handling and account-lookup functions used by merchants and your own support staff, where credential stuffing and broken access controls both tend to surface.

Payout and settlement pathways

The systems that move money to merchants and payees, tested for authorization gaps that could let an attacker redirect a settlement run rather than merely view data.

Acquirer API integration points

The connections your platform makes into sponsor and acquirer systems, examined for credential handling and error responses that could expose more than a status code.

Regulatory map

Why acquirers and card brands expect this testing

PCI DSS names the requirement outright, and the parties who supervise or sponsor you treat a current report as baseline evidence that a program is real.

PCI DSS v4.0.1's testing requirement

The standard requires regular penetration testing of the CDE and applies that duty explicitly to service providers, not only to merchants; every future-dated v4 requirement became mandatory on March 31, 2025.

Primary source →

Segmentation testing that keeps PCI scope honest

PCI expects segmentation controls to be verified, not assumed. Confirming the corporate network genuinely cannot reach the CDE is what keeps a SAQ D-Service Provider or ROC scope from quietly widening.

Primary source →

RPAR's testing and independent-review expectations

The Retail Payment Activities Regulations call for testing and periodic independent review of your risk-management framework, and a technical test of the underlying systems is part of showing that review is genuine.

Primary source →

OSFI B-10 duties flowing down from your sponsor

Sponsor banks manage PSPs as material third parties under B-10-style expectations, and their due-diligence schedules routinely ask for recent test results and proof that findings were remediated.

Primary source →

What goes wrong

What adversarial testing catches before an attacker does

The finding categories below are the ones that turn into fraud losses or a Bank of Canada notification, not abstractions nobody prioritizes.

  • Long-dwell access through the gateway

    One Canadian-facing gateway ran with an intruder inside its systems for roughly ten months, August 2023 through June 2024, before the exposure of about 1.7 million cards came to light, evidence that a compromise can sit inside a payment platform for the better part of a year.

    Source →

  • Checkout script tampering

    Skimming code injected into a payment page is exactly what PCI v4's newly mandatory script-inventory and integrity-monitoring requirements target, and testing checks whether those controls would actually catch it.

  • Segmentation that fails under real traffic

    A firewall rule that reads correctly on paper can still leave a path from the corporate network into the CDE once forgotten exceptions and real traffic patterns are involved, the exact gap segmentation testing is built to find.

  • Authorization flaws in onboarding APIs

    Broken object-level authorization in a sub-merchant onboarding flow can let one applicant pull another's beneficial-owner documents, a finding class testing surfaces well before a merchant stumbles into it.

Our pen testing for payment processors & payfacs

How a payments engagement is scoped

The work follows our standard testing approach, vulnerability exploration, response observation, improvement guidance, pointed at the systems that carry card data and move money.

Modern and luxury office
  1. CDE and tokenization vault testing

    Authenticated and unauthenticated testing of the systems storing or transmitting cardholder data, including detokenization paths and the services sitting closest to your HSMs.

  2. Segmentation verification

    Confirmation, through active testing rather than firewall-rule review alone, that the boundary between the CDE and everything else genuinely holds.

  3. Merchant portal and API testing

    Exploration of the merchant-facing portal and the APIs behind your mobile and partner integrations, probing authentication, session handling and cross-account access.

  4. Sub-merchant onboarding flow testing

    Targeted testing of KYB intake and underwriting pathways, where beneficial-owner and banking data are collected at volume during sub-merchant signup.

  5. Detection and response observation

    Insight into whether your monitoring noticed the simulated activity at all, often the most sobering finding in the whole report.

How the engagement runs

Running the test around your change freeze

Scheduling matters as much as scope, because testing has to fit around batch settlement runs and the Q4 freeze ahead of peak retail volume.

  1. Step 1

    Scope and rules of engagement

    We agree targets, test accounts and environments, and pick a window that avoids settlement batches and any freeze your merchants depend on.

  2. Step 2

    Controlled testing window

    Testing proceeds with an open channel to your engineers, so anything unexpected during the window gets flagged and contained immediately.

  3. Step 3

    Debrief with evidence

    Findings arrive ranked by what enables CDE access or payout fraud first, with reproduction detail your engineers can act on directly.

  4. Step 4

    Remediation and retest support

    Directional guidance through fixes, plus a follow-up check so your QSA and sponsor see closed findings rather than a static list.

What it costs

What shapes the price of a payments pen test

Scope drives the estimate: how many environments make up your CDE, how many acquirer and sponsor API integrations exist, whether sub-merchant onboarding is included, and whether coverage needs to be sized for a full ROC rather than an SAQ D-Service Provider. A single-gateway PayFac is a smaller engagement than a multi-acquirer platform running its own onboarding stack.

Depth adds cost where it adds value. Verifying segmentation properly and testing onboarding business logic take longer than a standard scan, and that depth is exactly what a sponsor's due-diligence team is checking for. Share your architecture and your assessment deadline and we will return a fixed scope and quote.

Payment Processors & PayFacs: Pen testing questions, answered

Yes. PCI DSS requires regular penetration testing of the cardholder data environment, and the requirement applies to processors and service providers directly, not only to merchants. With v3.2.1 retired and every future-dated v4 requirement mandatory since March 31, 2025, your QSA will expect a current test report covering the CDE and its segmentation, timed to fit your assessment cycle rather than assembled at the last minute.

Yes, and for most processors this is the single most valuable part of the engagement. We attempt to reach the CDE from the corporate network and from other out-of-scope segments, verifying that the boundary your SAQ D-Service Provider or ROC relies on actually holds under active testing rather than firewall-rule review alone. A gap here expands your PCI scope immediately, so it is worth finding before an assessor does.

One well-scoped test can serve both, provided the report covers what each reader needs. Your QSA wants CDE and segmentation coverage mapped to PCI DSS testing requirements; your sponsor's due-diligence team wants evidence that testing happened recently, findings were tracked, and remediation closed out. We structure the deliverable so the same evidence pack answers a QSA and a B-10-style acquirer schedule without a second engagement.

Onboarding is usually in scope, because it is where beneficial-owner IDs and banking documents move at volume and where authorization mistakes are common. We test the intake forms and APIs behind sub-merchant onboarding for the kind of access-control flaws that let one applicant reach another's file, alongside the core CDE and portal testing.

We build the testing window around your batch settlement schedule and any change freeze ahead of peak retail volume, agreeing kill criteria and a live communication channel with your engineers before anything starts. High-impact techniques run in staging where one exists; anything touching production is timed and throttled so testing never becomes the outage.

A scan checks known signatures against your systems automatically; a penetration test has a person chaining weaknesses together the way an intruder would, including business-logic abuse no scanner recognizes. PCI DSS distinguishes between the two and expects genuine penetration testing of the CDE, not a rebadged scan report, which is the gap we most often find when reviewing a processor's existing evidence.

What's Protecting Your Business from the Next Threat?

Don't wait for a breach to expose your vulnerabilities. Let Privacy Horizon secure your data, ensure compliance, and build lasting trust.

(647) 622-2644

Free, no obligation

Get a quote

Tell us what you need and we'll come back within one business day with a tailored quote.

We only use your details to respond to this request.