payment-security

Payment Security Testing

Payment systems are the highest-impact attack surface in any e-commerce application. A single vulnerability translates directly to financial loss, regulatory exposure, and reputational damage. Payment findings are almost always HIGH or CRITICAL severity -- a confirmed price manipulation or payment bypass is an automatic CRITICAL.

This skill covers the full offensive lifecycle against payment systems: flow mapping, price manipulation, race conditions, IDOR exploitation, gateway bypass, cart tampering, and refund abuse.

Triage Workflow

Follow this sequence. Each phase builds on the previous one. Skip nothing -- payment logic bugs hide in edge cases.

Phase 1 -- Payment Flow Mapping

Before attacking, map the entire payment lifecycle. Every request from cart to confirmation is in scope.

Map these flows:

1. Add to cart -- item selection, quantity, variant, pricing source
2. Cart management -- update quantity, remove items, apply coupons/discounts
3. Checkout initiation -- address entry, shipping method selection, tax calculation
4. Payment method selection -- card entry, saved card, wallet, gateway redirect
5. Payment processing -- tokenization, charge creation, 3DS challenge
6. Payment confirmation -- callback/webhook, order status update, fulfillment trigger
7. Post-payment -- refund flow, cancellation, subscription management

Capture with HTTP Repeater:

Load: ToolSearch -> select:mcp__hexstrike-ai__http_repeater

Intercept the full checkout flow from cart to confirmation.
For each request, note:
- Which parameters control price, quantity, item identity
- Which parameters reference user identity (user_id, session, account)
- Where the server trusts client-supplied values vs. server-side lookup
- Where the flow can be short-circuited (skip steps, replay confirmations)

Key questions to answer during mapping:

• Does the server recalculate totals, or trust the client-submitted amount?
• Are item prices embedded in the request, or looked up by product ID?
• Is the payment amount derived from the cart at checkout time, or passed as a parameter?
• Does the webhook/callback validate the payment amount matches the order total?
• Can checkout steps be reordered or skipped?

Record flow architecture:

node ${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js add <target> tech-stack payment-flow \
  "gateway=<stripe|paypal|custom>, checkout=<spa|redirect|server-rendered>, webhook=<yes|no>" \
  --source "payment-flow-mapping"

Phase 2 -- Price Manipulation

Test whether the application trusts client-supplied pricing data. This is the most common payment vulnerability class.

Attack vectors (test all):

1. Direct amount tampering -- modify the amount, price, total, or unit_price field
2. Negative values -- send negative amounts to generate credits or reverse charges
3. Zero price -- set amount to 0 or 0.00
4. Float precision -- exploit IEEE 754: 0.1 + 0.2 != 0.3, send 19.999999999999998
5. Integer overflow -- send amounts exceeding INT_MAX or BIGINT boundaries
6. Currency confusion -- change currency code to a weaker currency (USD -> VEF, EUR -> IRR)
7. Discount stacking -- apply multiple coupon codes, loyalty points + coupon + gift card simultaneously
8. Coupon replay -- reuse single-use coupons across sessions or accounts
9. **Quantity * price mismatch** -- change quantity to 0 or negative after price calculation

Use http_repeater to modify each parameter individually and observe server response.

See references/price-manipulation.md for detailed techniques, edge cases, and examples.

Phase 3 -- Race Conditions

Payment flows are stateful and time-dependent -- prime targets for TOCTOU attacks.

Attack vectors:

1. Double-spending -- send concurrent payment confirmations for the same cart
2. Coupon race -- apply the same single-use coupon in parallel requests
3. Balance race -- deplete wallet/credit balance simultaneously from multiple sessions
4. Inventory race -- purchase limited-stock items with concurrent checkouts
5. Refund race -- submit multiple refund requests before the first completes

Load: ToolSearch -> select:mcp__hexstrike-ai__http_intruder

Send 20-50 concurrent identical requests to the payment confirmation endpoint.
Use null payloads mode with 50 threads.
Check: did more than one succeed? Were multiple orders created? Was balance debited once but credited twice?

See references/race-conditions.md for timing techniques and detection methodology.

Phase 4 -- Payment IDOR

Payment IDORs let attackers access, modify, or hijack other users' transactions.

Attack vectors:

1. Order ID enumeration -- sequential or predictable order IDs in /orders/<id>, /invoices/<id>
2. Transaction reference swapping -- change transaction_id in confirmation callbacks
3. Recipient manipulation -- change emailDesc, account_id, user_id in payment creation
4. Invoice access -- access other users' invoices/receipts via IDOR on the invoice endpoint
5. Horizontal escalation -- view/modify another user's payment methods, saved cards, billing addresses
6. Vertical escalation -- access admin payment dashboards, refund capabilities, or transaction logs

See references/payment-idor.md for detailed IDOR patterns and testing methodology.

Phase 5 -- Gateway Integration Testing

The integration layer between the application and the payment gateway is a rich attack surface.

Attack vectors:

1. Webhook forgery -- send fake payment confirmation webhooks without valid signatures
2. Callback manipulation -- modify return URLs to inject payment status parameters
3. 3D Secure bypass -- skip or downgrade 3DS authentication
4. Token replay -- reuse payment tokens across orders or accounts
5. Gateway downgrade -- force fallback to a less secure payment method
6. Split payment abuse -- manipulate partial payment flows

See references/gateway-testing.md for provider-specific testing (Stripe, PayPal, Adyen, custom).

Phase 6 -- Cart Manipulation

The shopping cart is trusted state that feeds into payment calculation. Tamper with it.

Attack vectors:

1. Quantity manipulation -- negative quantities, zero quantities, fractional quantities
2. Item substitution -- change product ID to a cheaper item after price calculation
3. Shipping fee bypass -- remove shipping charges, change shipping method to free
4. Tax evasion -- manipulate tax calculation via address spoofing or parameter removal
5. Bundle breaking -- extract individual items from bundles at bundle pricing
6. Hidden item injection -- add items not displayed in the cart UI via API manipulation

See references/cart-manipulation.md for cart-specific attack patterns.

Phase 7 -- Refund and Post-Payment Abuse

After a legitimate payment, test the refund and post-payment flows.

Attack vectors:

1. Full refund on partial return -- request full refund while returning partial items
2. Refund to different method -- redirect refund to attacker-controlled payment method
3. Double refund -- submit refund through multiple channels (API, UI, support)
4. Chargeback + refund -- get both a merchant refund and a bank chargeback
5. Subscription manipulation -- downgrade after using premium features, cancel/resubscribe for trial reset
6. Digital goods + refund -- obtain digital delivery then refund the payment

See references/refund-abuse.md for refund flow testing methodology.

Decision Tree -- Attack Surface by Architecture

Stripe Integration

Stripe Checkout (hosted) → Focus on: webhook forgery, callback URL manipulation, metadata tampering
Stripe Elements (embedded) → Focus on: PaymentIntent amount mismatch, client-side amount override
Stripe custom (API direct) → Focus on: server-side amount vali