PCI DSS testing for payment flows
We test payment flows against the PCI DSS v4.0 requirements a QA team can evidence: declines, refunds, webhooks, who can touch an invoice. Your QSA gets the results. We are not a QSA and we do not assess compliance.
Book a 30-minute call
Six things that go wrong between "pay" and "paid"
We test with the processor's test cards and sandbox, never real card numbers.
The payment paths
Cards, saved cards, declines, insufficient funds, 3D Secure pass and fail, abandoned checkout, a double click on pay, autopay, partial and over-payments, retries.
evidence: case list with results per pathMoney maths
Refunds, including one larger than the original payment. Ledger reconciliation. Fees shown to the customer match fees charged. Amounts are computed on the server, not trusted from the browser.
evidence: expected against actual amountsWebhooks and payouts
Signed and idempotent webhooks, the same event delivered twice, a payout retried after a timeout, chargebacks, payout onboarding.
evidence: replayed events and the resulting balancesWho can touch a payment
API tests that payment and payout endpoints refuse callers who are not signed in, and callers signed in to another customer's account.
evidence: request and response pairs per endpointWhere card data shows up
We look for test card numbers in places they should not be: pages, API responses, exports, emails and logs.
evidence: search results across those outputsMoney without the goods
A payment taken but no booking or order created, or the reverse. We test every failure between the charge and the record.
evidence: charge and order compared, step by stepWhich requirements we test, and where we stop
A QA team can produce evidence for part of PCI DSS. This table says which part, and what stays with your QSA or a specialist.
| Requirement | What we test | Where we stop |
|---|---|---|
| 3 · Protect stored account data | Test card numbers do not appear in screens, API responses, exports, emails or logs. | We do not review your encryption or key management. |
| 6 · Secure systems and software | Security testing of web, API and mobile: injection, broken access, session flaws. Retest after fixes. | Not a source-code audit or a design review. |
| 6.4.3 · Payment page scripts | We can test it: list every script a payment page loads, compare it with your authorised list, and flag one that was added or changed. | Offered as a QA check on request. It does not replace your own script inventory and justification. |
| 7 · Restrict access by need to know | Role and tenant isolation on payment and payout screens and APIs. | We do not review who holds access in your systems today. |
| 8 · Identify and authenticate users | Sign-in, multi-factor, lockout, password reset and session handling in the application. | Not your directory, VPN or admin-console setup. |
| 10 · Log and monitor | Payments, refunds, role changes and failed sign-ins each leave a log entry saying who, what and when. | We do not review log retention or your monitoring tooling. |
| 11.6.1 · Change detection on payment pages | We can test it: change a script or header on a test copy of the payment page and check that your alert fires. | Offered as a QA check on request. Needs a test copy you control. |
Not covered: ASV external vulnerability scans, network segmentation testing, network and infrastructure penetration testing, and the assessment itself. Those need an ASV, a QSA or a network testing specialist.
What this finds in payment code
| Platform | What the tests covered | What they found |
|---|---|---|
| A US property-management platform with resident payments and payouts | Cards, saved cards, declines, autopay, partial and over-payments, refunds including one larger than the original, retries, ledger reconciliation, fee disclosure, and API tests that payment and payout endpoints reject unauthenticated and cross-tenant callers. | Any logged-in user could change another community's invoice status. A retried payout could pay twice. A webhook could process a renewal twice. An invoice could deposit to another community's bank account. |
| A marketplace on Stripe Checkout and Connect | Declines, insufficient funds, 3D Secure pass and fail, abandoned checkout, double submit, server-computed amounts, signed and idempotent webhooks, chargebacks, refunds, payout onboarding. | A payment was taken with no booking created. Fixed. |
Evidence a QSA can read
A test evidence pack
Every case, the version tested, the date and the raw result.
Findings tied to the requirement
Steps to reproduce, severity, and the PCI DSS requirement each finding relates to.
A retest after your fix
We confirm the fix holds and close the finding. Retests are billed at the same hourly rate as other testing time.
A one-page summary
What passed, what failed, what is open and what we did not test, in plain words.
| ID | Finding | PCI DSS | Severity | Status |
|---|---|---|---|---|
| P-004 | Refund endpoint accepts an amount above the original charge | Req. 6 | High | Retested, closed |
| P-011 | Payout endpoint answers a caller from another account | Req. 7 | High | Retested, closed |
| P-016 | Refunds leave no log entry with the user who issued them | Req. 10 | Medium | Fix in progress |
Our tools run the checks, our engineers read the results
Paper first, test mode only
NDA and data processing agreement before access. We use your processor's sandbox and test cards, never live money.
Our own tools
Flows re-runs the payment cases on every release. The AI Security Toolkit tests web and API security. BugBoard keeps every finding, with a retest history.
People who review
A QA engineer reads every result. Automated output can be confidently wrong, and a payment bug is expensive to miss.
Rates
EUR 20-45 per hour, engagements from one month. The first month is a trial: if you are not happy, the first two weeks are complimentary. After that the notice period is 30 days.
Common questions
Are you a QSA?
No. A QSA is accredited by the PCI Security Standards Council to assess you. We are a software testing company: we test your payment flows and give your QSA evidence to work from.
Do you need real card numbers?
No. We use your processor's test cards and sandbox. They cover approvals, declines, insufficient funds and 3D Secure, without a real card or real money.
Does hosted checkout take us out of scope?
It reduces your scope, often by a lot, but it does not remove it. Your QSA or processor decides which questionnaire applies. What stays yours is the page that sends customers to checkout, access to your payment admin and your webhook handling, which is what we test.
Do you run ASV scans?
No. External vulnerability scans for PCI DSS must come from an Approved Scanning Vendor, and we are not one. We do security testing of your web, API and mobile software, which is a different job.
Do you cover 6.4.3 and 11.6.1?
We can test them as a QA check: the script inventory on your payment pages, and whether a changed script triggers your alert. It supports your own controls and does not replace them. Ask us about scope.
How do we start?
With a 30-minute call, then a written scope. The first month is a trial. If you are not happy, the first two weeks are complimentary. After the first month the notice period is 30 days. Tell us what you need to evidence.
Related: security testing, API testing, AI Security Toolkit.
Tell us what your QSA will ask for
Thirty minutes: your payment flow, your processor, the evidence you need and by when. We reply with a written scope.