Online Marketplace Penetration Testing

Testing whether a buyer, seller or member of marketplace staff can reach data or actions that belong to someone else: another seller’s listings and payouts, another buyer’s orders, or a dispute and refund outcome they shouldn’t control. We test through the interface, the API and the webhooks your payment processor and fulfilment partners rely on.

The URLs or apps in scope, API documentation if you have it, the roles in your platform (buyer, seller, staff, and any partner roles), how many sellers we’re testing across, your payment model and processor, staging accounts for each role, and a note of which transactions we’re permitted to run, for example real refunds versus simulated ones.

Yes. We test how your platform creates and manages connected seller accounts, how payout recipients and schedules can be changed, and whether webhook events are verified and cannot be replayed. See our Stripe and Adyen pages.

Yes, where your marketplace or its sellers integrate with Amazon SP-API. Amazon’s Data Protection Policy requires solution providers that access seller PII to run vulnerability scans every 30 days, complete a penetration test every 365 days, scan code before every release, and remediate critical findings within 7 days and high findings within 30 days. It’s a contractual requirement from Amazon, not a legal one, and we scope testing to match it. Amazon SP-API vulnerability management guide.

We test the boundary your platform controls: how you call the processor or partner API, how you verify their responses and webhooks, and what you do with the data they send back. We do not attack the processor’s or partner’s own infrastructure, and any test transactions are agreed in advance and run through sandbox or staging credentials wherever they exist.

Yes. Refund and payout testing covers whether the recipient, amount, timing or approval state of a refund or payout can be changed by a user who shouldn’t control it, including sequences that combine a legitimate refund with an unrelated payout change.

Yes. We test the checkout and payment flow alongside the wider marketplace, and where your platform sits in the cardholder-data environment we scope to PCI DSS Requirement 11.4.2 and 11.4.3 so the report is ready for your QSA or acquirer.

A typical scope: buyer browses, purchases and messages sellers about their own orders only; seller manages their own listings, orders and payout details, and nothing belonging to another seller; marketplace staff moderate listings and mediate disputes, with every override logged; payment processor integration holds tokens and webhook secrets, never raw card data on your servers; fulfilment partner reads shipping address and order contents only, never payment credentials. We confirm each boundary holds through the interface and the API.

Illustrative examples of the technique, not findings from a client engagement. Can a seller edit an order that belongs to another seller by swapping the order ID in an API call? Can a buyer trigger a refund and cancel the linked payout adjustment before it applies, keeping the goods and the money? Can a seller account change its own payout bank details and cash out before your fraud checks or manual review catch the change?

Executive summary (board-ready), technical report with CVSS 3.1 scores, reproduction steps, screenshots, specific remediation guidance, and a 60-minute walkthrough call. Letter of attestation issued after free retest.

Yes. We sign client-supplied NDAs as standard. Engagement data is protected under our ISO 27001 (BSI-audited) information security management system.

From signed scope to active testing in 24 hours where required. Standard pipeline is 3-5 business days from initial scoping call to test start.

Every engagement is performed by vetted UK-based CREST-certified testers matched to your engagement based on security clearance, compliance scope, and sector specialism. Testers hold CREST certifications relevant to their discipline (CRT, CCT APP, CCT INF, CCSAM).