Payment gateway security testing

Why payment gateway security testing is now a recurring obligation

A payment gateway or processor that acts as a PCI DSS service provider needs security testing on a recurring cycle, not as a one-off check before launch. The active requirement set is PCI DSS v4.0.1, which became the only active version when v4.0 was retired on 31 December 2024, and its future-dated requirements became effective on 31 March 2025 (PCI SSC blog announcing v4.0.1). If your assessor, a merchant or a launch plan is pushing you toward a test, the question to answer is which requirements now apply to your service provider role, and which of them set a fixed testing frequency. Confirm the exact requirement list with your Qualified Security Assessor before you scope anything.

The risk concentrates in three places. Merchant-facing APIs handle authorization, capture, refund and tokenization calls, and each new integration or version adds surface. Multi-tenant platforms can leak data or controls between merchants if tenant boundaries, role checks or segmentation controls fail, which is why requirement 11.4.6 requires service providers that rely on segmentation to penetration test those controls at least every six months and after changes. Payment page scripts loaded in the consumer's browser are a third risk, covered by requirements 6.4.3 and 11.6.1, which call for script authorization, inventory and change or tamper detection on payment pages.

Testing is needed on a recurring basis because these components change far more often than an annual assessment cycle. Each merchant onboarding, API release, third-party script update or infrastructure change can reopen a weakness that a single test would not catch. Requirement 11.4.7 also means that, as a multi-tenant provider, you must either show customers redacted evidence of testing on their subscribed infrastructure or give them prompt access to test it. Decide early which of those routes you will offer, and ask any testing provider to map its deliverables to the evidence your merchants and assessor will request.

What can be in scope for a gateway test

A gateway test is only as useful as its boundaries. The cards below cover the components a provider can put in scope, and the decisions that determine how those components are tested, including which tenants are used and whether production is involved.

Merchant-facing and partner APIs

These are the endpoints merchants, acquirers and integration partners call to create payments, refunds, payouts and tokens. Testing covers authentication, object-level authorization between merchant accounts, input validation and rate limits on sensitive business flows. Ask whether the scope includes both versioned and legacy API versions, since older versions often keep weaker controls. Mapping the API inventory before testing starts prevents gaps.

Hosted payment pages and scripts

Hosted checkout pages and the third-party scripts they load are where cardholder data is captured in the browser. Scope should list every script, its authorization and integrity controls, and the change and tamper detection on each page. Confirm with the provider which requirement set governs script inventory, since PCI DSS 6.4.3 and 11.6.1 both apply to payment pages.

Tenant administration consoles

Administrative portals let staff and merchant administrators manage accounts, keys, users and settings. Testing focuses on role separation, session handling, multi-factor enforcement and whether one tenant's administrator can view or change another tenant's data. Decide whether the console is tested with tenant accounts only or also with provider staff roles, since each needs separate credentials and rules of engagement.

Segmentation between cardholder data and other zones

Segmentation controls determine which systems fall inside the cardholder data environment. For a service provider using segmentation, PCI DSS 11.4.6 requires penetration testing of those controls at least every six months and after changes. Scope should name each segmentation boundary, the systems on each side, and the evidence the tester will use to confirm that traffic is blocked as designed.

Cloud and Kubernetes hosting

The gateway runs on cloud accounts, managed services and often Kubernetes clusters. Scope should state which accounts, clusters, namespaces, secrets stores and network policies are included, and whether the provider's cloud testing rules apply. Confirm how shared responsibility is divided so the test does not assume controls the provider does not operate.

Test merchants, environments and rules of engagement

Decide which tenants and merchant accounts the testers use, and whether they are dedicated test accounts with no live funds or settlement. State whether testing runs in production, pre-production or a mirror, and what happens if a test triggers a live transaction, lockout or alert. Written rules of engagement should set testing windows, rate limits, emergency contacts and data handling for any cardholder data encountered.

How a gateway penetration test runs, phase by phase

The sequence turns a payment gateway's segmentation, merchant integrations and API layer into a scoped, evidenced test whose findings can be fixed, retested and handed to a QSA or to customers. Each phase has a defined output that the next phase depends on.

Confirm scope against requirements 11.4.6 and 11.4.7
Before any testing, the provider and your team agree in writing which systems, networks, tenant boundaries and merchant-facing interfaces are in scope, and which segmentation controls separate the cardholder data environment from everything else. Requirement 11.4.6 applies if you rely on segmentation, and requirement 11.4.7 applies if you are multi-tenant and must support customer testing. Confirm with your QSA which segmentation boundaries they will expect to see evidenced. The step is done when a signed scope document lists each boundary, each tenant model and the testing windows for production-adjacent systems.
Map the cardholder data flows and tenant boundaries
The tester documents how payment data enters, moves through and leaves the gateway, including hosted payment pages, API endpoints, webhooks, admin consoles, support tooling and integrations with acquirers and processors. For multi-tenant platforms, the map shows how merchant identities, keys and data are isolated from each other. Your team validates the map against the architecture and the current network diagrams. The output is an agreed data flow and tenant map that becomes the reference for every later test case.
Test segmentation controls from both sides
Under requirement 11.4.6, the tester attempts to reach the cardholder data environment from out-of-scope networks, from tenant workloads and from the internet, to confirm that segmentation controls hold. Testing covers network paths, identity boundaries between tenants, and management plane access. Tests run against the environment you specify, with a rollback and contact plan for production-adjacent systems. The step closes with a list of confirmed or disproven segmentation boundaries, each with evidence, so you can show that the controls work and not only that they exist.
Test application and API layers against OWASP guidance
The tester assesses the gateway's web interfaces, merchant APIs and hosted payment components using the OWASP Web Security Testing Guide as the method reference. API testing covers authentication, object-level authorization between merchants and tenants, input handling, rate limits and abuse of business flows such as refunds, payouts and card-on-file operations, which the OWASP API Security Top 10 2023 describes under API6 Unrestricted Access to Sensitive Business Flows. Test accounts and data must be agreed in advance, and the tester avoids destructive payloads against live transaction processing. The output is a set of validated findings tied to specific endpoints and roles.
Check payment page scripts and change detection
Where the gateway serves or influences payment pages in the consumer's browser, the tester reviews the scripts loaded, their authorization and integrity controls, and the inventory and written justification that requirement 6.4.3 expects. The tester also reviews how requirement 11.6.1 change and tamper detection is configured, including its frequency and alerting. Confirm with the gateway team which scripts are under their control and which belong to merchants. The step is complete when each script is classified as in scope, out of scope or merchant responsibility, with the review evidence attached.
Deliver the report and agree remediation
The provider delivers a report that states the methodology, scope, tools categories used, test dates, each finding with severity and reproduction detail at a level your engineers can act on, and the segmentation and tenant results. Your team triages findings with the provider, agrees owners and remediation approach, and confirms which items affect the next retest. Under requirement 11.4.1, the penetration test and remediation results must be retained for at least 12 months, so agree storage and access arrangements now. The output is a report plus a remediation register that lists each finding, owner and status.
Retest fixes and prepare customer evidence
After remediation, the tester retests the closed findings and confirms whether each fix works without introducing new exposure. For multi-tenant gateways, the retest also confirms that segmentation and tenant isolation controls still hold after changes, which requirement 11.4.6 expects after any significant change. If you must support customer testing under requirement 11.4.7, prepare redacted evidence or a process for prompt customer access, and confirm with your QSA which form they accept. The step closes with a retest report and an updated register that show what was fixed, what was accepted as risk and why.

How segmentation testing and tenant separation are validated

Under requirement 11.4.6, a service provider that uses segmentation to reduce its PCI DSS scope must penetration test those segmentation controls at least once every six months and after any change to them. That is twice the 12 month cycle that requirement 11.4.5 sets for other entities, so the six month rhythm should be planned into the operating calendar from the start, not discovered at the first assessment. For a payment gateway, the segmentation boundary usually separates the cardholder data environment from the merchant portal, the administrative network, the build and deployment tooling and shared services such as logging and identity. Agree that boundary in writing before testing starts, list every control that enforces it (firewall rules, network policies, cloud security groups, jump hosts, identity boundaries) and confirm with your assessor which of them your scope depends on. Each change to those controls, including a new merchant onboarding path or a new cluster, should trigger a retest, so ask the testing provider how out-of-cycle tests are requested and priced.

Tenant separation is tested as three distinct layers, because a gateway that isolates merchants at the database but not at the API or the admin console has not isolated them. At the data layer, testers check that one merchant's transactions, tokens, keys and reports cannot be read or altered through any query path, including reporting exports and background jobs. At the API layer, they test object-level authorization on every merchant-scoped identifier, looking for ways a credential issued to one merchant can reach another's resources. At the administration layer, they examine how support staff, operators and automated services are authenticated, what their roles can reach across tenants, and whether privileged actions are logged and separated from routine access. Requirement 11.4.7 then addresses customers directly: a multi-tenant provider must either supply evidence, such as redacted penetration test reports showing that testing covered the customer's subscribed infrastructure, or give customers prompt access to test. Decide with your gateway provider which of the two options you will rely on, and confirm the redaction and access terms in the contract before you need them.

Which weakness categories matter most in a payment gateway

This table compares the weakness categories that testers most often examine in a payment gateway or processor platform, with a defensive description of each and why it matters to merchants and assessors. Read each row as a question to put to your provider: is this category in scope, and what evidence will show it was tested?

Weakness category	What it looks like defensively	Why it matters to merchants and assessors
Broken object level authorization across tenants	One merchant's account can read or change another merchant's transactions, tokens or settings by altering an identifier in a request	Cross-tenant exposure of cardholder-linked data is a breach event for the provider and its merchants, and it undermines the tenant separation that 11.4.7 customer testing depends on
Insecure merchant API authentication	Weak handling of API keys, secrets or client credentials, missing rotation, or tokens accepted outside their intended scope or lifetime	Merchant integrations are the most common entry path into a gateway, and assessors look for documented key lifecycle controls and evidence of how they were tested
Unrestricted access to sensitive business flows (OWASP API6 2023)	Payment, refund, payout or enrollment operations can be run at high volume by automation with no rate, velocity or behavioral controls	Automated abuse of transfers, card testing or refund flows causes direct financial loss and fraud exposure, and it is a common gap between functional and security testing
Weak segmentation between cardholder data and other zones	Flat networks or shared management paths let systems outside the cardholder data environment reach it, or segmentation controls were never validated after a change	Under 11.4.6, a service provider that relies on segmentation must test those controls at least every six months and after changes, so weak segmentation directly widens the scope of assessment
Payment page script integrity gaps	Third-party or inline scripts on checkout pages are loaded without authorization records, integrity checks or change detection	Requirements 6.4.3 and 11.6.1 expect scripts to be inventoried and payment pages monitored for tampering, and skimming through a script is a frequent finding for merchants using hosted fields
Insufficient logging and detection of abuse	Failed authentication, unusual API volumes or changes to payment pages do not generate alerts or are not reviewed	Assessors check that testing results and remediation are retained for at least 12 months under 11.4.1, and that detection supports the response claimed in the security narrative

How the test changes for hosted pages, APIs and hosting platforms

When a gateway serves a payment page or script that runs in the consumer's browser, the risk moves from the server to code the gateway does not fully control at runtime. Requirement 6.4.3 asks for every script on a payment page to be authorized, integrity-assured and inventoried with a written justification, and requirement 11.6.1 asks for change and tamper detection on those pages at least every seven days or at a risk-defined frequency. A test therefore checks the script inventory against what the page actually loads, the integrity controls on each script and whether the detection mechanism would notice an unauthorized change.

Access: Testers need a staging or pre-production copy of the page that matches production scripts, plus the inventory and change records the client keeps.
Test data: Use test card numbers and sandbox merchant accounts only. Never enter live cardholder data during the test.
Rules of engagement: Confirm whether any production page can be exercised, and who monitors the page if it is.
Evidence: Ask for the script inventory, justification records and the tamper-detection alert history for the period under review.
Coverage: Include third-party scripts, tag managers and iframe injection paths, since these are where unlisted code tends to appear.

Before signing, confirm which pages and scripts are in scope and whether the test covers both staging and the live page.

What drives the cost and duration of a gateway test

This table compares the components that shape the price and schedule of a payment gateway test, who is paid for each one, and whether it recurs. Use it to check that a written quote states the same inputs, since the largest differences between quotes usually come from scope items left unstated. The main takeaway is that the six-monthly segmentation cycle and customer testing support recur, so the one-time test price is only part of the total cost.

Cost component	Who is paid for what	One-time or recurring	What to request in a written quote
API and endpoint count	Tester time to map merchant, partner and admin APIs, then test authorization and input handling on each	One-time for the initial test, recurring at each six-monthly cycle if scope changes	Endpoint inventory or OpenAPI definitions, with the count tested and any items excluded
Tenant and role combinations	Testing cross-tenant access for each merchant tier and each role (for example merchant admin, support staff, reporting user)	One-time per scope, expands as tenants or roles are added	List of tenant types, roles and how many isolated test accounts the client will provide
Segmentation depth	Testing whether controls between the cardholder data environment and other networks hold, under requirement 11.4.6	Recurring every six months and after changes to segmentation	Diagram of segmentation boundaries, count of segmentation controls to test, and the change trigger definition
Payment page scope	Review of hosted or embedded payment pages, scripts and their integrity controls against requirements 6.4.3 and 11.6.1	One-time assessment, with recurring checks if the script inventory changes	Inventory of payment page scripts, hosting model and whether change detection is in scope to verify
Environments	Time spent on production-like, staging or production testing, including safe testing practices and coordination with operations	One-time per environment, recurring if environments are retested	Named environments, change freeze windows and the client's rules for production testing
Retest rounds	Tester time to verify fixes, update findings and confirm remediation evidence	One-time per round, with each additional round billed separately	Number of retest rounds included, the retest window and how verified findings are recorded
Customer evidence and support	Preparing redacted reports, supporting customer testing requests under requirement 11.4.7 and retaining results for at least 12 months under requirement 11.4.1	Recurring as customers request testing or evidence	Format of evidence packs, expected customer request volume and who handles customer contact

Which frameworks ask for gateway testing and what they expect

Payment gateways fall under several overlapping frameworks, each asking for testing in a different way. The cards below set out what PCI DSS, DORA, FAPI 2.0 and the Swift CSCF expect, so the test scope, cadence and evidence can be agreed before work starts.

Segmentation testing for service providers

Requirement 11.4.6 applies when a service provider relies on segmentation to isolate the cardholder data environment. The segmentation controls must be penetration tested at least every six months and after any change to them, which is twice the cycle that applies to most other entities. Confirm with your assessor which segmentation controls are in scope and whether your change triggers match the standard's expectations.

Support for customer penetration tests

Requirement 11.4.7 applies to multi-tenant providers. You must either give customers evidence that testing covered their subscribed infrastructure, such as redacted reports, or give them prompt access to test. Because this became mandatory on 31 March 2025, agree the method for each tenant contract and record how requests are handled.

Retention of test and remediation results

Requirement 11.4.1 requires penetration test results and remediation activity results to be kept for at least 12 months. Assessors will ask for the report, the remediation tickets and the retest evidence together. Set up a retention location and a naming scheme for these records before the first test, not during the assessment.

Yearly testing for EU financial entities

DORA Article 24(6) requires financial entities other than microenterprises to test all ICT systems supporting critical or important functions at least yearly. Article 25(1) names the test types, including vulnerability scans, source code reviews where feasible, scenario-based tests and penetration testing. A gateway that carries payment flows will often fall within this scope, so confirm the function classification with your risk team.

Threat-led testing for large payment institutions

Delegated Regulation (EU) 2025/1190 lists payment and e-money institutions above EUR 150 billion of payment transactions in each of the two preceding years among entities that TLPT authorities require to test, unless their assessment says otherwise. Threat-led tests run on live production systems and their scope is validated by the competent authority. Check your transaction volumes against the criteria before planning gateway tests.

FAPI 2.0 for payment API profiles

The FAPI 2.0 Security Profile, finalized on 22 February 2025, requires pushed authorization requests, PKCE with S256 and sender-constrained access tokens using mutual TLS or DPoP. It supports only confidential clients. Testing should check each of these controls against the profile and use the free OpenID conformance suite as a baseline before any self-certification claim is made.

Swift CSCF advisory penetration testing

Swift CSCF v2026 control 7.3A, under the objective Detect and respond, is advisory. It recommends penetration testing to validate the operational security configuration of the Swift-related environment. Because it is advisory, your Swift customer security attestation depends on its own rules, so confirm with your Swift security officer how much of this testing the attestation expects.

What your team needs to prepare before testing starts

Before a payment gateway test starts, your team needs test accounts and merchant sandboxes that behave like production in the ways that matter: the same payment methods, the same tokenization and 3-D Secure paths, and the same webhook and settlement behavior. Confirm with your engineering lead which tenants, merchant IDs and API credentials the testers will use, and which test cards, bank simulators and callback endpoints are available. Ask for separate credentials per tester so that activity can be traced in your logs. Also agree who owns the sandbox data, how it is reset between test windows, and whether any sandbox shares a database, key store or HSM partition with production. If it does, that sharing belongs in the rules of engagement, not in a footnote.

Give the testers a documented architecture and segmentation diagram that matches what is deployed, not what was designed. For a service provider under PCI DSS requirement 11.4.6, the segmentation controls are the thing being tested, so the diagram should show every boundary between the cardholder data environment and out-of-scope networks, the firewall and security group rules that enforce them, and each tenant boundary in your multi-tenant platform. Include the merchant-facing API gateways, the hosted payment pages and the scripts they load. Ask your architects to list which systems hold or process account data, and note any drift since the last review. Expect the testers to ask for a current data flow diagram and a list of in-scope IP ranges, and confirm both are signed off by the system owner before kickoff.

Name one incident contact and one backup for each of the following: the security operations lead, the payments operations on-call owner, the platform owner for each production-adjacent system, and the compliance lead who will receive the report. Agree how testers will reach them during the window and what they should do if a test triggers an alert or a payment failure. Set a change freeze for the in-scope systems for the test window, and tell the monitoring team exactly when testing starts and stops, which source addresses to expect, and which alerts should be acknowledged rather than escalated. Record these decisions in the rules of engagement, including the stop conditions, such as a live settlement problem or a suspected real attack, and who has authority to pause testing. Confirm your fraud and chargeback teams know about the window so that test transactions are not treated as merchant fraud.

What to check before choosing a payment gateway test provider

A payment gateway test provider will touch production-adjacent systems, merchant integrations and customer data, so the selection criteria matter as much as the test itself. The cards below cover the questions to put to each candidate and the documents to request before any commitment.

PCI DSS service provider experience

Ask for examples, described in general terms, of testing performed against PCI DSS service provider scope, not only merchant or e-commerce scope. A provider that understands the difference will ask which systems store, process or transmit cardholder data, which systems could affect their security, and how the cardholder data environment is bounded. Ask who on the team has performed this work and how recently.

Documented test methodology

Request the written methodology the provider follows, including how it maps findings to severity, how it handles production-adjacent systems, and what it will not test. A credible method describes its phases, tooling categories, and reporting structure in plain language. Vague answers such as proprietary approaches with no written steps are a reason to pause.

Segmentation test scheduling

Confirm how the provider will schedule segmentation penetration tests under requirement 11.4.6, including who triggers the retest after a significant change to network controls, cloud accounts or tenant boundaries. Ask how the schedule is recorded, who owns it on your side, and how the provider confirms that the segmentation controls it tested are the ones in production.

Tenant data handling

Ask how the provider will access and store any merchant, tenant or cardholder-related data it encounters during testing. Check whether test data is redacted or minimized, where evidence is kept, how long it is retained, and who can access it. For multi-tenant platforms, confirm that testing on one tenant cannot expose data belonging to another.

Insurance and confidentiality terms

Review the professional liability and cyber insurance the provider carries, the confidentiality terms that apply to your findings, and how liability is limited if a test disrupts a service. Confirm that the agreement covers subcontractors and that findings are not shared with third parties without your written consent.

Sample redacted report

Ask for a sample report, redacted to remove client names and sensitive data, so you can judge its structure before you buy. A useful report includes the scope, test dates, methodology, reproduction steps at a defensive level, affected assets, severity rationale, and retest status. Check that it can be shared with your QSA and that the provider will support evidence requirements such as retaining results for at least 12 months under requirement 11.4.1.

QSA coordination

Ask whether the provider will coordinate directly with your Qualified Security Assessor, including agreeing the scope and evidence format before testing begins. Confirm who answers auditor questions, how quickly, and whether the provider will explain its methodology in a form the QSA can assess. The provider prepares evidence for your assessment but does not issue your compliance opinion.

Written scope before commitment

Require a written scope document before signing, listing in-scope systems, testing windows, excluded systems, escalation contacts, and the deliverables. The scope should state how changes to it will be approved and priced. A fixed-scope quote derived from this document lets you compare providers on the same basis.

Questions buyers ask about payment gateway security testing

How much does payment gateway security testing cost?

No fixed price applies, because the cost follows from the written scope. The main cost components are the tester's time across the gateway's merchant and API integrations, tenant separation, segmentation controls and payment page scripts, plus reporting and the debrief. Costs rise with the number of integrations, the number of tenants, the size of the segmented environment and whether testing runs against production-adjacent systems. Ask for a quote that lists each component, separates one-time work from any recurring segmentation testing, and states what is excluded. DeployOpen does not publish a price list, so the written scope is the basis for any figure.

How long does a payment gateway penetration test take?

The duration depends on the agreed scope, and the written plan sets the timeline. The biggest factors are the number of merchant and API integrations, how many tenants must be separated and tested, how complex the segmentation design is, the access the client can provide and how quickly remediation findings are fixed and retested. Environment readiness often decides the start date, so confirm test accounts, sandbox availability and change freeze windows early. DeployOpen does not quote durations in advance, so request a schedule with the quote.

What does our team need to provide for the test?

Expect to supply architecture diagrams, a data flow for cardholder data, a list of in-scope systems and integrations, network segmentation documentation, test merchant and tenant accounts, and named contacts for change and incident handling. Your team also needs to agree on testing windows, the source IP ranges used by testers and the escalation path if a critical issue appears during testing. Ask the provider to list these inputs in the written scope so that gaps are visible before work starts.

Can our internal team run the payment gateway test instead?

An internal team can run some testing, such as regular vulnerability scanning and checks on payment page scripts, but PCI DSS penetration testing expects a qualified, independent tester and a documented methodology. Internal staff can prepare the environment, maintain the segmentation inventory and verify fixes. Ask any provider how testers are qualified, how independence from the system owners is maintained and what the report will contain. DeployOpen plans and runs security testing, but it does not issue attestations, so confirm with your assessor which evidence they will accept.

How does six-monthly segmentation testing work for a service provider?

Under requirement 11.4.6, a service provider that uses segmentation must penetration test the segmentation controls at least once every six months and after any significant change, which is twice the frequency required for other entities under requirement 11.4.5. In practice, the test checks whether systems that should be isolated, such as cardholder data environments and tenant boundaries, can reach each other. The testing cycle should be scheduled in advance, tied to change management and recorded with results and remediation evidence. Requirement 11.4.1 expects those results to be kept for at least 12 months.

Does the gateway need to support customer penetration testing?

Multi-tenant service providers must support customer external penetration testing under requirement 11.4.7, which became mandatory on 31 March 2025. The provider can either supply evidence, such as redacted reports showing that testing covered the customer's subscribed infrastructure, or give customers prompt access to test. Buyers should ask which option the gateway uses, how customers request access and what limits apply. Clear rules protect both parties and keep tenant data separate.

How is retesting billed after findings are fixed?

Retesting cost depends on how many findings need verification, how much of the original scope they touch and whether the fixes change the architecture or segmentation. Some providers include a limited retest window in the original quote, while others charge for each verification round. Ask whether retests are included, how many rounds are covered, how long a retest window lasts and whether segmentation changes trigger a new six-monthly test. Put these terms in the written scope so that retest effort is not a surprise at the end of the engagement.

How DeployOpen scopes, tests, reports and retests gateway environments

DeployOpen runs payment gateway security testing as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. We test the gateway platform, its merchant and API integrations and its tenant boundaries, then document results in a form your QSA and customers can use.

How we scope

Written scope defines which gateway components, merchant APIs, tenant boundaries and hosted payment pages are in and out of testing
Segmentation boundaries are mapped so the segmentation test under requirement 11.4.6 covers the controls that actually separate cardholder data
Customer-facing testing rules are agreed for requirement 11.4.7, including whether evidence or prompt customer access is the chosen route
Ongoing support and continuous testing can be added as a retainer once the initial written scope is accepted

How we build

Test environments are agreed with you, and production-adjacent testing follows documented safety rules and agreed change windows
Test accounts, merchant sandboxes and tenant records are prepared so that no testing affects other merchants on the platform
Payment page script inventory and change-detection evidence under requirements 6.4.3 and 11.6.1 are reviewed alongside the test plan
Testing covers merchant and API integrations, authorization of sensitive business flows and tenant isolation in line with the agreed scope

How we hand over

Findings are reported with affected component, risk rating, reproduction context at a defensive level and recommended remediation
Segmentation test results and remediation evidence are packaged so they can be retained for at least 12 months under requirement 11.4.1
Redacted summaries for customers are prepared separately, so sensitive internal details stay out of customer-facing documents
A retest is scoped in writing to confirm that agreed findings have been remediated and to record the result

How we support

Retesting after significant platform changes is scoped in advance, since requirement 11.4.6 calls for testing after changes as well as every six months
Support questions from your QSA or customers about test scope, method and evidence are answered from the written engagement record
Recurring testing, upgrades and continuous assessment are available through a retainer agreed separately from the initial scope
Confirm with your QSA which evidence format they accept before the engagement starts