Skip to content

Testing plan · Ecommerce

Security testing for ecommerce websites

An ecommerce testing plan for cart totals, order ownership, discounts, refunds and checkout transitions, using sandbox payments and traceable evidence.

By BugSnaps · Updated

Start an authorized assessment View an example report

How should an ecommerce website be security tested?

Test storefront exposure and account permissions, then review the server-side rules for cart totals, discounts, payment confirmation, fulfillment and refunds. Use synthetic orders and sandbox payments so the assessment can verify state changes without charging customers or dispatching goods.

Checkout security depends on the relationship between several systems: the storefront, order database, payment provider and fulfillment process. A success screen alone is weak evidence. The assessment should establish which event authorizes an order and what happens if that event is repeated or arrives late.

Scope

Define the assets, actors and boundaries.

Use this plan to agree an assessment scope. The exact checks depend on your application, authorization and available test access.

Assets, test roles and priorities for ecommerce
Asset or journeyTest contextsPriority
Orders, invoices and addressesTwo shoppers, guest and support userCheck ownership of purchase and shipping information.
Cart, discount and checkout APIsShopper and store administratorReview which prices and transitions the server accepts.
Payment callbacks and fulfillmentSandbox provider and controlled workerTrace payment state into stock, shipment and refunds.

Before the assessment

Prepare representative access and a clear scope.

  • Use payment-provider sandbox accounts, test stock and a fulfillment sink.
  • Document allowed discount combinations, tax and shipping calculations, and refund permissions.
  • Separate the owned storefront from provider-hosted payment pages and other suppliers' systems.

Only test systems you own or have explicit permission to assess. Agree target boundaries, data handling and stop conditions before active testing.

Workflow

Move from a baseline to verified repairs.

  1. Step 1

    Inventory the purchase path

    Capture cart creation, login, shipping selection, payment approval, order confirmation and cancellation. Mark the source of truth for totals and the event that permits fulfillment.

  2. Step 2

    Assess the reachable application

    Run an authorized baseline against the storefront and supplied sessions. Review exposed files, supported input checks and whether account-specific pages were actually reached.

  3. Step 3

    Review business transitions

    A tester should inspect client-supplied totals, discount reuse, unpaid orders, repeated callbacks and cancellation after approval. Reconcile each result against the sandbox order and provider ledger.

  4. Step 4

    Validate the repair end to end

    Retest a normal purchase as well as the previously invalid transition. Confirm a retry does not create a second fulfillment job, refund or credit.

Report evidence

Keep enough detail to verify and repair the issue.

Use controlled records, remove secrets and keep the result tied to the permission or workflow that failed.

  • Sanitized cart, order and sandbox payment identifiers linked to a single test case.
  • The expected total or state and the server's actual stored result, including worker effects.
  • A normal purchase control, the failing transition and a repeat test after remediation.

Use the evidence in the release decision

Treat an unpaid order becoming fulfillable, another shopper's data becoming accessible, or a repeat event creating duplicate value as a concrete workflow defect. Keep its business effect in the remediation ticket, rather than reporting only an HTTP response code.

Coverage and limits

Know what automation establishes and what needs a reviewer.

Automated baseline

Automated assessment is useful for the web surface and supported API checks. It does not know your discount policy or prove that a provider callback, inventory worker and refund ledger agree.

Review MyPentest's scope

Human review

Manual testing is needed for payment-state races, loyalty programs, refund abuse, multi-currency rounding and custom fulfillment rules. Do not let a general active scan make real purchases or request live refunds.

Discuss the assessment scope

Common questions

Questions about testing ecommerce.

Can the test use real customer orders?

Use synthetic orders wherever possible. If production verification is necessary, agree the exact read-only records and handling rules with the owner first; customer data is not needed for a repeatable checkout control test.

Does scanning the store test the payment provider?

It assesses the owned integration within its scope. Provider-hosted pages and infrastructure need their own authorization and are not included simply because the store uses them.

Why test webhooks as well as the checkout page?

Some stores update payment and fulfillment state through asynchronous events. Human review should verify how those events are authenticated, repeated and reconciled with the provider's payment record.

References for this testing plan

These primary references inform the testing approach. They are not endorsements of BugSnaps or claims that a product implements every test in a standard.