E-commerce Security Testing: Payment Flows, Cart Abuse, and PCI DSS

E-commerce applications run on business logic that doesn't exist in other web application categories. Cart state management, price calculation, coupon and discount systems, inventory locking, payment processing flows, order state machines — each of these is a potential attack surface that generic web security testing checklists don't cover.

The attacks that actually impact e-commerce businesses are often not the OWASP Top 10 classics. They're price manipulation via parameter tampering, coupon abuse that bleeds margins, cart race conditions that allow purchasing at invalid prices, payment bypass through order state manipulation, and negative quantity tricks that generate refunds without returning merchandise. These are business logic vulnerabilities — and finding them requires understanding the business logic, not just sending malformed payloads.

This guide covers the specific vulnerability classes that matter for e-commerce platforms, how to test them, and what PCI DSS requires in terms of security assessment scope.

Price and Cart Manipulation

Client-Side Price Tampering

The most common e-commerce vulnerability class. Applications that calculate price on the client side and submit the final price to the server for payment processing are trivially abusable. The attacker intercepts the checkout form submission, modifies the price parameter, and submits. If the server trusts the client-supplied price without re-validating against the server-side product catalogue, the purchase goes through at the tampered price.

Quantity Manipulation

Variations of price tampering that target quantity rather than unit price. Submit negative quantities to trigger store credit or reverse charges. Submit 0 quantity after adding an item. Submit extremely large quantities to test for integer overflow in total calculation (if the total overflows to a small positive number or zero, some systems process it at that amount).

# Test negative quantity
POST /cart/update HTTP/1.1
Content-Type: application/json

{"items": [{"product_id": "SKU-123", "quantity": -1, "price": 49.99}]}

# Test quantity that causes integer overflow
{"items": [{"product_id": "SKU-123", "quantity": 2147483647, "price": 0.01}]}

Coupon and Discount Abuse

Coupon systems are a rich attack surface. Testing scope includes:

• Stacking — applying multiple coupons when only one should be allowed, either sequentially through multiple API calls or by batching coupon codes in a single request if the API accepts arrays
• Reuse after invalidation — single-use coupons that can be applied multiple times due to race conditions (apply the coupon in two parallel requests before either completes; if the invalidation check and application aren't atomic, both may succeed)
• Expired coupon bypass — submit past-expiry coupons with manipulated expiry_date parameters if the date is client-supplied
• Coupon code enumeration — if coupons follow predictable patterns (SAVE10, SAVE20, SUMMER2025, SUMMER2026), enumerate valid codes through the discount lookup endpoint
• Cross-user coupon theft — if single-use coupons are tied to a specific user account, test whether a different user can apply the same coupon code
• Coupon with negative discount — submit a coupon code with a tampered discount value parameter to increase the discount beyond the intended amount

Race Conditions in Cart and Checkout

E-commerce systems are particularly vulnerable to race conditions because multiple legitimate users compete for the same inventory, and the checkout flow involves multiple sequential state transitions that can be exploited when parallelized.

Key race condition tests:

• Double-spend on limited stock — add the last item to cart in two parallel sessions; both receive confirmation but inventory should only decrement once
• Flash sale price race — initiate checkout at sale price; have a parallel request trigger the sale to end; complete checkout at the stale (sale) price
• Coupon application race — as noted above, apply a single-use coupon in parallel requests
• Loyalty point race — redeem loyalty points in parallel requests to spend more than the available balance

Order State Machine Abuse

E-commerce order flows follow a state machine: cart → checkout → payment-pending → paid → processing → shipped → delivered → return-possible → closed. Each state transition should be validated server-side. When state validation is weak or absent, attackers can force invalid transitions.

Payment Bypass via Order State Manipulation

Test whether an order can be forced to "paid" or "processing" state without completing payment:

• Initiate checkout, abandon payment, and directly call the order confirmation or shipping endpoint with the order ID
• After payment fails, replay the payment success callback or webhook with a modified order ID pointing to a larger order
• Submit a valid payment completion request for order A, then immediately replay it with order B's ID before the completion is persisted

Webhook Replay and Manipulation

Payment processor webhooks (Stripe, Mollie, Adyen, PayPal) notify your application when payments succeed or fail. These webhooks must be validated — unsigned or weakly validated webhooks allow an attacker to send forged payment success notifications.

Refund Abuse

Refund systems are often implemented with weaker authorization than purchase flows. Test:

• Requesting a refund for an order belonging to another user (IDOR on order ID)
• Requesting multiple refunds for the same order (insufficient state checking)
• Requesting a refund for a non-refundable item type
• Requesting a refund for a larger amount than the original purchase
• Requesting a refund to a different payment method than the original

Authentication and Account Security

Guest Checkout to Registered Account Merge

E-commerce sites that allow guest checkout and later account creation sometimes merge guest session data into the new account without proper validation. Test whether completing a guest checkout with a victim's email address, then registering an account with that email, grants access to the victim's order history or stored addresses.

Saved Payment Method Security

Applications that save payment methods typically store a tokenized reference (not the raw card) via their payment processor. Test:

• IDOR on saved payment method IDs — can user A charge user B's saved card by referencing B's payment method token?
• Whether saved payment methods are accessible across accounts that share a device or billing address
• Whether deleting a payment method invalidates active subscriptions or pending orders properly

Address Book Enumeration

Shipping address records often contain full name, address, and phone number. Test for IDOR on address IDs, and whether the address search/autocomplete endpoint leaks data from other users' address books.

Inventory and Availability Manipulation

Negative Inventory

Some systems allow inventory to go negative — meaning more units are sold than exist. Test by placing many parallel orders for the last available unit. If inventory goes negative, orders are processing for items the warehouse can't fulfill, creating operational disruption and potential fraud.

Cart Reservation DoS

Systems that reserve inventory when items are added to a cart (before checkout) can be abused to lock out other buyers. Add all available inventory to a cart without completing checkout. If the cart reservation doesn't expire, the item becomes unavailable to legitimate purchasers. Test whether cart reservations expire and how long the window is.

PCI DSS Penetration Testing Requirements

If your e-commerce application processes, transmits, or stores cardholder data, PCI DSS Requirement 11.4 mandates penetration testing at least annually and after significant infrastructure or application changes. Understanding what's actually in scope for a PCI-required pentest avoids expensive over-scoping.

Cardholder Data Environment (CDE) Scope

The CDE is the system components, people, and processes that store, process, or transmit cardholder data. For most modern e-commerce applications that use a payment processor (Stripe, Adyen, Mollie), the CDE is limited:

• Your application typically never touches raw card data — the payment processor's JavaScript (Stripe.js, etc.) handles card entry in an iframe hosted by the processor
• What you do process: the payment token, order amounts, and payment confirmation webhooks
• PCI scope for tokenized implementations: the web server that hosts your checkout page, the server that processes webhooks, and any component that handles the payment token

Confirm your scope with your QSA (Qualified Security Assessor) before commissioning a penetration test — over-scoping significantly increases cost.

PCI DSS Penetration Test Requirements (v4.0)

PCI DSS v4.0 Requirement 11.4 specifies:

• External penetration testing at least annually and after significant changes
• Internal penetration testing at least annually and after significant changes
• Testing must cover the entire CDE perimeter and critical systems
• Application-layer testing must include OWASP Top 10 (at minimum)
• Network-layer testing must include components that support network functions
• Testing by a qualified internal resource or qualified third party — assessor must be organizationally independent from the systems being tested

SAQ A and the Limits of Scope Reduction

Merchants eligible for SAQ A (fully outsourced card data handling) are not required to perform a penetration test under SAQ A alone. However, SAQ A eligibility requires that your checkout page itself doesn't handle card data — only the processor's hosted payment page or iframe does. Verify your iframe implementation is correct before assuming SAQ A eligibility:

• The card entry iframe must be hosted by the payment processor (js.stripe.com, pay.adyen.com), not your domain
• Your server must never receive card numbers, CVVs, or full PANs — only tokens
• Your checkout page JavaScript must not modify or intercept the payment iframe

API Security for E-commerce Backends

Product Catalogue API

• Mass assignment — can an attacker set price, stock, or is_featured fields on a product they didn't create? Test PUT/PATCH endpoints for all writable fields.
• Price override parameters — does the product API accept a custom_price or override_price parameter that bypasses catalogue pricing?
• Draft/unpublished product access — can a guest user access draft products by guessing their ID?

Order API

• IDOR on order IDs — can user A retrieve user B's order details by changing the order ID in a GET request? Test with sequential or UUID-based IDs. If IDs are sequential integers, this is almost certainly exploitable.
• Order cancellation after shipment — can an order be cancelled after it's already shipped? What happens to the payment?
• Rate limiting on checkout — can the checkout endpoint be called repeatedly without rate limiting? Could this allow unlimited coupon attempts or payment method validation (card testing)?

Card Testing / Carding

Fraudsters use e-commerce checkout flows to validate stolen card numbers at small amounts before large purchases. Your checkout API should rate-limit payment attempts per IP, per account, and per card number (hashed). Test:

• How many failed payment attempts are allowed before rate limiting activates
• Whether rate limiting applies to guest checkout (no account required)
• Whether CAPTCHA or additional verification is triggered after repeated failures
• Whether different IP addresses bypass per-IP rate limits on the same account

Testing Checklist for E-commerce Security

Use this as your pre-engagement scope for an e-commerce penetration test:

• Price parameter tampering (unit price, total, shipping, tax)
• Negative quantity and integer overflow in cart totals
• Coupon stacking, reuse, expiry bypass, and enumeration
• Race conditions in checkout, coupon application, and loyalty points
• Order state machine — bypassing payment to reach paid/shipped state
• Webhook validation — missing or bypassable signatures
• Refund IDOR and amount manipulation
• Saved payment method IDOR
• Guest checkout to account merge security
• Cart reservation DoS and inventory exhaustion
• Product API mass assignment and price override
• Order API IDOR on order IDs
• Card testing / carding rate limit testing
• Checkout page script inventory (Magecart surface)
• CSP on payment page
• OWASP Top 10 on all in-scope endpoints
• API authentication and authorization across all order/cart endpoints