Why checkout and payment flow security testing is commissioned
A PCI DSS assessment, a payment launch, a customer security questionnaire or an acquirer requirement is usually what forces a test of checkout. This page explains what gets tested: checkout pages, payment page scripts, payment APIs and their business logic. It also shows how that work maps to PCI DSS requirements 6.4.3, 11.6.1 and 11.4.1, and what the client receives at the end. DeployOpen runs the testing and prepares the evidence, but it does not issue attestations or PCI validation. That decision stays with your assessor and your acquirer.
The risks in this area are specific. A tester checks whether the cart and order service trust a client-supplied price or quantity, whether a user can skip a payment step and still receive an order confirmation, and whether a coupon or refund flow can be replayed. On the browser side, a skimming script injected into the payment page can capture card data without ever touching your back end. Unauthorized changes to page content or response headers can do the same job. These are the cases that automated scanners tend to miss, which is why PCI DSS and the guidance behind it expect authenticated, business-logic-aware testing rather than a scan alone.
Before you commission the work, confirm three things with your assessor or acquirer: which payment pages and payment APIs are in scope, which third-party scripts load on those pages, and whether they expect the script inventory and the change-detection records as evidence. Those answers shape the test plan more than anything else. The OWASP Web Security Testing Guide is a useful reference for the methodology a tester should follow, and the rest of this page explains how DeployOpen scopes, runs and reports the test.
What can be in scope for a payment flow test
A payment flow test is only as good as its boundaries. The components below are the ones most often in scope, and each one raises its own decisions about environment, accounts, authentication and operating rules that should be settled in writing before testing begins.
Storefront and checkout front end
The pages a shopper sees from basket to confirmation, including client-side validation, price and total calculation in the browser, and how the checkout state is stored. Decide whether the test covers only the browser logic or also the server decisions that the front end relies on. Confirm which framework versions and single-page routes are included, since hidden routes often carry the same logic as the visible ones.
Payment page scripts and third-party tags
Every script that runs on the payment page, including analytics, fraud, chat and tag manager code loaded from third parties. The scope should include the script inventory, the integrity controls on each script, and who can change the tag configuration. Ask the client for the current inventory and the written justification for each entry, because the test checks whether those records match what the browser actually loads.
Payment and order APIs
The endpoints that create orders, apply discounts, set amounts, confirm payment and read order status. Testers look for trust in client-supplied values such as price, currency, quantity and shipping cost, and for object access that lets one shopper reach another's orders. Agree which API versions and internal services are in scope, and whether the test uses the published specification or discovers endpoints from traffic.
Webhooks and callbacks
Inbound notifications from the payment provider that mark orders paid, refunded or disputed. Confirm how the system verifies the sender, checks the signature, handles replayed or out-of-order events, and ties each event to a real transaction. Scope should state whether the tester may send test events to the webhook endpoint or only observe the flow, and which provider sandbox is used to generate them.
Hosted payment and iframe integration
The hosted page or embedded frame that collects card details, and the parent page that receives its messages. Scope the message passing between frames, the origin checks, the order token handling and whether the merchant page can read any card data. Ask the payment provider which parts of this integration are their responsibility, so the test does not duplicate or miss the boundary.
Admin, refund and operator functions
Back-office screens and APIs for refunds, manual orders, price overrides and account changes. Decide which operator roles are tested, whether high-value actions require a second approver, and whether the tester may perform refunds in a non-production store. These functions are often outside the public attack surface but carry the highest financial impact, so they need explicit inclusion or a documented reason for exclusion.
How a checkout test runs, phase by phase
The sequence moves from agreed scope and documentation into authenticated and unauthenticated testing of the payment flow, then closes with retesting and a report that maps findings to the requirements the client must evidence.
Agree scope and payment flow boundaries
The tester and the client agree in writing which checkout entry points, payment pages, payment APIs, third-party payment scripts and environments are in scope, and which PCI DSS requirements the test must support. Scope covers the hosted or embedded payment page, cart and pricing logic, order confirmation, and any webhook or callback endpoints. The timeline and fees are set in this written scope, and the step is complete when both parties sign off on the asset list and the rules of engagement.
Review documentation and source where available
The client supplies architecture diagrams, API specifications, data flow diagrams, the payment page script inventory and any source code the team can share. The tester reads these before touching the application, following the documentation-led approach that ASVS 5.0.0 favors over testing blind. The output is a shared map of the checkout flow, including which party controls each script and which API calls carry prices, quantities and payment tokens.
Build a threat model for the checkout flow
Using the flow map, the tester identifies the abuse cases that matter most for checkout: price or quantity manipulation, skipped payment steps, tampering with payment tokens, injected or swapped scripts on the payment page, and access to other customers' orders. The threat model is structured against the WSTG business logic, client-side and API testing categories and the ASVS V2 and V4 chapters for validation and API controls. The output is a prioritized test plan that the client reviews before testing starts.
Test as an unauthenticated visitor
The tester exercises the checkout from the outside with no account, covering exposed endpoints, error handling, input validation on public forms, and whether pages or APIs reveal information they should not. This establishes what an anonymous attacker could reach. The step closes when every public checkout endpoint in the plan has a recorded result, including checks that passed, so the report shows coverage and not only findings.
Test as authenticated customers and roles
Using test accounts the client provides, the tester checks authorization between customers, staff and merchant roles, object-level access to orders and payment records, and whether the cart, pricing and payment steps enforce server-side rules. The tester acts as both an authenticated and unauthenticated user, as CIS Control 16.13 describes for critical applications. The output is evidence for each business logic and access control check, since automated scanners cannot verify most of these on their own.
Review client-side payment scripts and changes
The tester compares the scripts loaded on the payment page with the inventory the client maintains, checks whether each script is authorized and integrity-protected, and reviews whether client-side code can alter amounts or redirect payment data. This step supports the evidence needed for PCI DSS 6.4.3 and 11.6.1, and it confirms whether the client's change and tamper detection covers the page headers and content the test observed. Gaps are recorded with the script name, owner and observed behavior.
Retest fixes and report against the standard
After the client fixes findings, the tester retests each one and records whether the fix holds, using the same test accounts and evidence trail. The final report lists scope, all checks performed with their results, findings with reproduction detail at a defensive level, recommended fixes, and requirements that did not apply. Where the client needs an ASVS-structured record, the report is organized by requirement rather than only by exception. The client then uses it with its qualified assessor, since DeployOpen prepares evidence but does not issue audit reports or certifications.
Which weaknesses checkout testing targets and why they matter
This table maps the weakness categories a checkout test looks for to their OWASP Top 10 2025 or API Security Top 10 2023 identifiers and the business impact of each. Read each row as a category a tester checks for, with the impact a finance, fraud or compliance owner would care about. The main takeaway is that most checkout losses come from trusting client input or from business rules enforced inconsistently, which scanners rarely catch.
| Weakness category | What testers look for | OWASP identifier and business impact |
|---|---|---|
| Client-side price or total trust | Whether the server recalculates totals and prices or accepts values submitted from the browser or app | A05 Injection and A06 Insecure Design. Orders may settle at amounts the business never offered, causing direct revenue loss. |
| Workflow bypass of payment or confirmation steps | Whether an order can reach fulfillment or confirmation without the payment step completing successfully | A06 Insecure Design and API6:2023 Unrestricted Access to Sensitive Business Flows. Goods or services may ship unpaid, and reconciliation breaks. |
| Quantity and discount manipulation | Whether server-side rules limit quantities, stack coupons, or enforce minimum spend and eligibility | A06 Insecure Design. Promotions and stock limits can be abused at scale, eroding margin and distorting reporting. |
| Race conditions on coupons and stock | Whether concurrent requests can redeem a single-use code or oversell limited inventory | A06 Insecure Design. Duplicate redemptions and oversold stock create refund workload and customer disputes. |
| Insecure direct references on orders and payment records | Whether a user can view or change another customer's order, invoice or payment record by altering an identifier | API1:2023 Broken Object Level Authorization and A01 Broken Access Control. Exposure of personal and card-adjacent data, with notification and regulatory consequences. |
| Mass assignment of payment properties | Whether API endpoints accept fields such as amount, currency, status or payment method that the client should not set | API3:2023 Broken Object Property Level Authorization. Clients could alter order state or pricing fields the business assumed were read-only. |
| Unauthorized function access such as refunds | Whether refund, void, capture or credit functions are restricted to the right roles and cannot be called by ordinary customers or support tiers | API5:2023 Broken Function Level Authorization and A01 Broken Access Control. Unauthorized refunds or voids create direct financial loss and fraud exposure. |
| Unrestricted access to sensitive business flows | Whether automated or repeated calls to checkout, card tokenization or gift card functions are limited by rate, velocity or fraud controls | API6:2023 Unrestricted Access to Sensitive Business Flows and API4:2023 Unrestricted Resource Consumption. Card testing, gift card abuse and service degradation during peak trading. |
| Unsanitized script or content injection into payment pages | Whether scripts, third-party tags and page content on payment pages are authorized, integrity-checked and changed only through controlled releases | A05 Injection and A08 Software or Data Integrity Failures. Skimming scripts can capture card data in the browser, a breach type that is hard to detect without change monitoring. |
What the report gives your QSA and your customers
A traditional penetration test report lists findings by exception: what was broken, how severe it is and how to fix it. That is useful for engineering teams, but it does not show an assessor what was checked and found clean. ASVS 5.0.0 describes a different shape for an ASVS verification report: the scope, a summary of every requirement checked, the requirements with exceptions and guidance on resolving them, and any requirements that do not apply. For a checkout or payment API, ask for that structure explicitly, because a clean payment page is only evidence if the report says which controls were examined and how. Agree the format in the statement of work before testing starts, and confirm with your QSA which format they accept for the PCI DSS requirement 11.4.1 application-layer testing evidence. Some assessors want a requirement-mapped table, others accept a narrative report with an appendix, and the answer changes what the tester should deliver.
A payment-focused report should keep two things separate. The first is the requirement mapping: which PCI DSS requirements the test addresses, which ones it does not, and which sit with another party, such as a hosted payment provider or the team that maintains the payment page scripts. The second is the findings: each weakness, its evidence, its severity in the context of the cardholder data flow and the remediation path. Mixing them makes it hard for a QSA to see coverage gaps, and it makes it hard for your team to retest a single fix without rereading the whole document. Ask the tester to state which checkout steps were tested in authenticated and unauthenticated roles, and which payment-related business logic cases, such as altered totals or replayed payment callbacks, were tested and with what result.
Requirements 6.4.3 and 11.6.1 depend on evidence that accumulates over time. Keep a current inventory of every script loaded on payment pages, with its authorization, its integrity method and a written justification, and keep the outputs of the change and tamper detection on payment page headers and content. DeployOpen can prepare that evidence as part of the engagement, including the inventory, the monitoring configuration and records of how alerts were handled, but the assessor judges whether it meets the requirement. Confirm with your QSA how far back the records must go, who signs off the inventory and whether the monitoring frequency you chose matches the risk analysis you documented. Those are the questions to settle before the report arrives, not after.
Deliverables: findings, severity, retest results and assurance letters
A payment flow test is only useful if its output can be acted on by developers and accepted by an assessor or customer. The cards below cover the items you receive, how each finding is tied to the PCI DSS requirements in scope, and where an assurance letter fits and where it stops.
Executive summary and scope record
The summary states what was tested, which checkout, payment page and payment API paths were covered, and the main risks in plain language for a risk committee. The scope record lists the URLs, user roles, test accounts, payment page scripts reviewed and anything excluded. Ask for both in writing before work starts, so the summary can be compared against the agreed scope rather than recalled from memory.
Requirement-mapped findings register
Each finding is recorded with its affected component, its weakness category, and the PCI DSS requirements it touches, such as 6.2.4 and 11.4.1 for application-layer testing or 6.4.3 and 11.6.1 for payment page scripts and change detection. The register is the document your QSA or internal assessor will read first. Check that every in-scope requirement has either findings or a documented statement that no issues were found.
Severity ratings and their basis
Each severity rating comes with a short written basis: the attack preconditions, whether authentication was required, the data or payment value at risk, and whether compensating controls were observed. A rating without this basis is hard to defend to a finance lead or auditor. Ask how the provider handles business logic issues, such as price or quantity manipulation at checkout, which scanners tend to miss and which need judgment.
Reproduction detail without exploit code
Developers need enough detail to reproduce the behavior in a test environment: the request sequence at a high level, the affected parameter or script, the observed response and the expected secure behavior. The report should not contain working exploit code, payloads or step-by-step attack commands. Confirm that reproduction notes are written for engineers fixing the flaw, and that the tester can explain each one in a debrief.
Remediation guidance and retest results
Remediation guidance names the control to restore, such as server-side price recalculation, script integrity checks or a payment page inventory with written justifications. Retesting then records a result for each finding: resolved, partially resolved, not resolved or accepted as risk, with the evidence used to decide. Ask whether retest is included in the fixed scope or priced separately, and how long after the fix the retest window is open.
Assurance letter with clear limits
Where a customer or partner asks for proof of testing, the provider can issue a letter that describes the testing performed, its dates, its scope and its high-level results. That letter is a summary of work, not an attestation, certification or audit report, and DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations. Agree the letter's wording, recipients and disclaimers before testing begins.
How payment testing differs by checkout architecture
In a hosted payment page or redirect model, the provider collects card data on its own domain and the merchant's front end sends the customer there with order details in the request. The merchant still controls the cart, the checkout pages that lead to the redirect, the return URL handling and every script loaded on those pages. Testing concentrates on the merchant front end, the parameters that carry amounts, currency, order references and return addresses, and whether the merchant can tell that a returned result is genuine. Many buyers assume this model removes them from scope, but PCI DSS requirements 6.4.3 and 11.6.1 still apply to any payment page the merchant's browser content controls.
- Redirect parameters: test whether amounts and order identifiers can be altered between the cart and the redirect, and whether the return flow trusts query values without server-side confirmation.
- Script inventory: list every script on the checkout pages, including tag manager and analytics code, with its source and justification.
- Result confirmation: check that the order is marked paid only after the provider's signed or server-side status is verified.
- Return and error paths: confirm that cancelled, failed and replayed returns cannot produce a completed order.
Confirm with the provider's documentation which parameters are signed, how return results are authenticated, and which script and iframe behaviors fall to the merchant.
An embedded iframe or JavaScript SDK places the provider's payment fields inside the merchant's own page. The parent page, which the merchant builds and hosts, loads the frame, passes configuration to it and receives tokens or status messages back. The main risks sit in that parent page: the scripts it loads, the messages it accepts from the frame, and how it reacts when a third-party script is compromised or altered. Testing therefore examines the parent page as much as the payment fields themselves, and it needs a clear picture of which scripts are authorized to run in the payment context.
- Message handling: review how the parent page validates the origin and structure of messages from the payment frame before acting on them.
- Third-party scripts: map every script on the payment page, check for integrity attributes where the provider supports them, and test how the page behaves if a script changes.
- Frame configuration: check the sandbox, permissions and content security policy applied to the frame and the parent.
- Token use: confirm that payment tokens are used only for their intended order and amount on the server.
Confirm with the provider which messages are authenticated, which script URLs must be allowlisted, and whether the SDK supports subresource integrity.
With a direct API integration, the merchant's backend builds payment requests, handles card or token data passed through its systems, and receives webhooks that update order state. The card data may never reach the merchant's browser, but the merchant's own APIs now carry the financial logic. This is where authorization gaps, price and quantity manipulation and retry problems usually appear. The test scope covers order, payment and refund endpoints, the webhook receiver and the server-side logic that connects them, and it matches the approach in the REST API security testing and business logic testing topics.
- Order and payment APIs: test object-level authorization so one customer cannot pay for, refund or view another customer's order.
- Idempotency: check that repeated requests with the same key cannot create duplicate charges or duplicate fulfilment.
- Webhooks: verify that incoming provider notifications are authenticated, and that replayed or forged events are rejected.
- Amount integrity: confirm that the server sets prices and totals rather than trusting client-supplied values.
Confirm with the provider's API reference which idempotency and signature mechanisms it offers, and which test accounts and sandbox environments it provides for testing.
A marketplace or multi-tenant platform collects payments for many merchants or sellers through one shared system. The platform may split funds, hold balances, manage merchant onboarding and expose administrative roles for operators and sellers. The main question changes from whether one transaction is correct to whether one tenant can see, change or pay out money belonging to another. Testing examines tenant isolation across every payment, payout and reporting function, and the boundary between platform administrators, merchant users and end customers.
- Tenant isolation: test whether identifiers from one merchant account grant access to another merchant's transactions, payouts or settings.
- Role boundaries: review what each merchant role, support role and platform administrator can change, including refunds and bank details.
- Payout and split logic: check that fee and split calculations cannot be altered by a seller or an API caller.
- Admin and support tooling: include internal interfaces that can act on payments, since they often have broader rights than customer paths.
Confirm with the provider which account and sub-account model it supports and which permissions it enforces itself, so that the test covers what the platform builds on top.
What your team prepares before the test starts
Confirm the payment provider's test-mode rules before anything else is shared. Testers should never handle live cardholder data, so the team needs sandbox or test payment credentials that cannot move real money or touch a live card number, plus written confirmation from the provider that automated and manual testing against test mode is permitted. Ask the provider which test card numbers, webhook endpoints and tokenization behavior apply, and whether the provider's own terms restrict load or abuse testing. Record the answers in the rules of engagement so the tester works only inside them. If a live environment is the only option, agree in writing how card data will be kept out of tester tooling, notes and reports before the test starts. The second group of inputs describes what runs in the browser and behind the checkout. Provide a current architecture and data flow diagram that shows where the payment page is hosted, which iframe or redirect model carries card entry, and which services receive payment tokens and webhooks. Provide the inventory of payment page scripts and tags with each item's owner and written justification, since the test will check that the inventory matches what loads in the browser. Where they exist, supply API specifications for cart, pricing, checkout, payment and refund endpoints, along with test accounts for each role (guest, customer, support agent and any merchant or administrator role) so authorization between roles can be tested. The third group covers people and operations. Name one technical contact who can answer questions about the payment flow within a working day and who can stop testing if a live payment or alert is affected. Agree a change freeze window so that script, tag or configuration changes do not invalidate findings mid-test, and record the rate limits the tester may apply and which third-party providers, such as fraud scoring, tax or analytics services, are out of scope or must be notified. Ask the testing provider to confirm how these inputs will be handled and what they cost to prepare, since a quote should reflect the time your team must spend gathering them.
What to check before choosing a payment testing provider
Payment flows combine browser scripts, server-side logic and third-party payment APIs, so a provider needs to show skill across all three. The checks below cover experience, method, scope, reporting, data handling, retesting and accreditation, and each one tells you what to ask for before you sign.
Experience with your payment stack
Ask which checkout and payment APIs the provider has tested in environments like yours, including hosted payment pages, embedded fields, tokenization flows and webhook handlers. Ask how they would test a page that loads scripts from third parties, and how they would confirm that a payment page script is authorized, integrity-checked and inventoried. Vague answers about "payments experience" usually mean the team has tested general web applications only.
Methodology referenced to WSTG and ASVS
Ask the provider to map the test to the WSTG categories and to the ASVS chapters that apply to checkout, including V2 Validation and Business Logic, V4 API and Web Service and V6 Authentication. A named method lets you check coverage later. Ask which ASVS level they will target and why, since ASVS recommends starting at Level 1 for the most critical concerns and moving up as the application requires.
Written scope with exclusions
The scope should list every payment entry point, including the checkout site, the payment API, administrative consoles, callback endpoints and any third-party hosted fields, along with the environments and accounts involved. Exclusions matter as much as inclusions: a provider should state in writing what they will not test, such as the processor's own infrastructure, and who approves changes to scope during the engagement.
Business logic testing with authenticated accounts
Price and quantity tampering, coupon stacking, skipped payment steps and order state manipulation are business logic flaws that scanners rarely find. Ask whether the provider will test with multiple customer accounts and at least one account with elevated roles, and whether they will work from the documented checkout flow. CIS Control 16.13 describes authenticated testing as better suited to this class of flaw for critical applications.
Report format and PCI DSS mapping
Ask for a sample report before you commit. It should show findings with reproduction detail, severity rationale and remediation guidance, and it should state which requirements the test supports, including 11.4.1 for application-layer testing. Ask whether the provider can also deliver an ASVS-style report that lists every requirement checked, not only exceptions, since that is the form an assessor typically reviews.
Data handling for test payment data
Testers will create orders and may handle card-like data, tokens or customer records. Ask how test card numbers are used, whether the provider uses only sandbox or test-mode payment credentials, where evidence is stored, how long it is retained and how it is deleted at the end of the engagement. Get these rules in the statement of work so they are enforceable.
Retest terms and accreditation
Confirm whether one retest of confirmed findings is included, what window applies and whether it is fixed-price. For accreditation, CREST's OVS scheme covers web application assessments against ASVS at Levels 1 and 2, but accreditation status changes, so check the provider's current status directly with CREST rather than assuming it from a logo or sales deck.
Questions buyers ask about checkout and payment testing
How much does checkout and payment flow security testing cost?
No fixed price applies, because the quote follows from the written scope. The main cost drivers are the number of checkout paths and payment methods, whether the tester works with authenticated accounts and test data, how many payment APIs and third-party scripts are in scope, whether the client provides documentation or source code, and how many retest rounds are expected. Each component is a tester's time, so ask the provider to break the quote into planning, testing, reporting and retest effort. Ask whether the price is one-time for a single engagement or recurs under a retainer for continuous testing. DeployOpen does not publish a price list.
How long does a payment flow security test take?
Duration depends on scope size and on how quickly the client provides access. The biggest timeline factors are the number of flows to test, how many user roles and test accounts are needed, whether a staging environment mirrors production payment configuration, and how many findings require validation and retesting. Fixed-scope engagements agree the timeline in writing before work starts, so ask for the planned start, test window, report date and the retest window. Confirm any blackout periods around peak trading or payment processing runs with your change board.
What does the client need to provide before a checkout test starts?
The tester needs enough context to test the flows that matter without guessing. Typically this includes an inventory of checkout pages, payment APIs and their specifications, the list of payment page scripts and their sources, authenticated test accounts for each relevant role, a staging environment or agreed test windows, test payment credentials supplied through the payment provider's sandbox, and contacts for escalation. Where available, provide architecture diagrams, the data flow for cardholder data and any web application firewall rules. Confirm with your payment provider which sandbox and test cards are permitted before the engagement begins.
Can our internal team run the checkout test without an outside provider?
Internal staff can run useful testing, but the result is not the same as an independent test. Internal teams can run regular scanning, review changes, and check whether payment scripts are inventoried, and these activities support the controls. An assessor, however, usually expects the application-layer test under requirement 11.4.1 to be performed by a qualified tester with suitable independence from the team that built the system. Ask your QSA or acquirer whether internal testing is acceptable for the requirement and what evidence of skill and independence they expect.
Does one penetration test satisfy PCI DSS requirement 11.4.1?
A single test can satisfy requirement 11.4.1 only if its scope, method and reporting meet the requirement, and the QSA decides that question for your assessment. The test must be application-layer penetration testing that covers the vulnerabilities listed in requirement 6.2.4, including business logic abuse through API manipulation and client-side functionality, which is why checkout flows need authenticated, scenario-based testing. Expect the assessor to ask for the methodology, the tester's qualifications, the scope against your cardholder data environment, the findings and evidence of retesting. Agree the scope and the evidence format with your QSA before testing starts.
Does a penetration test cover requirements 6.4.3 and 11.6.1 for payment page scripts?
No. A penetration test checks whether the controls work, but requirements 6.4.3 and 11.6.1 are continuing controls that the entity must run itself. Requirement 6.4.3 requires each payment page script to be authorized, integrity-checked and listed in an inventory with a written justification. Requirement 11.6.1 requires a change and tamper detection mechanism for payment page headers and content, run at least every seven days or at a risk-defined frequency. A test can show whether a script can be injected, whether integrity controls are bypassed, or whether a change goes unnoticed, and it can review your inventory and detection configuration. Your team still needs to maintain both controls and produce their records.
How is retesting billed and scheduled?
Retesting is usually scoped separately from the initial test, so ask the provider to state in writing whether retest rounds are included, how many are allowed, the window for them, and what is charged for each. The effort depends on how many findings are retested, whether fixes touch several flows, and whether the tester must reconfigure test accounts or environments. Schedule retesting only after fixes are deployed to the environment being tested, and make sure the retest report records the status of each original finding. Confirm whether a retainer or a planned follow-up would suit your release cycle.
How DeployOpen scopes, tests, reports and retests payment flows
DeployOpen scopes checkout and payment flow testing in writing before work starts, then tests the flow in the client's own environment and hands over findings that map to the PCI DSS requirements in play. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Confirm which checkout pages, payment API endpoints and hosted payment scripts fall within the written scope, and which are excluded.
- Agree whether testers receive authenticated access with test accounts for each customer role, plus any unauthenticated coverage.
- Record which PCI DSS requirements the test must support, such as 6.4.3, 11.4.1 and 11.6.1, so the deliverables match the assessor's needs.
How we build
- Review the payment flow design, API documentation and the list of payment page scripts with the client before active testing begins.
- Test business logic such as price, quantity and workflow manipulation manually, since automated scanners cannot verify these flaws reliably.
- Check script loading, integrity controls and change detection on payment pages, and record how each finding was reproduced without publishing exploit code.
How we hand over
- Deliver a report that lists the scope, the requirements checked, each finding with its evidence, and remediation guidance the engineering team can act on.
- Note which requirements do not apply to the flow and explain why, so the assessor can follow the reasoning without reconstructing it.
- Walk the client's engineers and security leads through findings and agree the owner and order of fixes before the engagement closes.
How we support
- Retest each fixed finding in the same environment and document whether the fix holds, with dated evidence for the assessor.
- Offer a retainer for ongoing testing when payment pages change often, covering new scripts, releases and checkout features.
- Confirm with the client's assessor or qualified security assessor how the report and retest evidence will be used before work starts.
