/payment-security

name: payment-security
description: |
  This skill should be used when the user mentions "payment", "payment gateway", "checkout",
  "IDOR payment", "payment bypass", "Stripe", "MercadoPago", "Binance Pay", "PIX", "PayPal",
  "Adyen", "Braintree", "Square", "Razorpay", "Mollie", "webhook", "payment webhook",
  "price manipulation", "amount tampering", "currency manipulation", "e-commerce",
  "shopping cart", "cart manipulation", "checkout flow", "checkout bypass", "order tampering",
  "refund abuse", "refund fraud", "chargeback", "race condition payment", "double spending",
  "coupon abuse", "discount stacking", "promo code", "gift card", "store credit",
  "PCI DSS", "PCI compliance", "payment card", "credit card testing", "payment token",
  "tokenization", "3D Secure", "3DS bypass", "SCA bypass", "payment callback",
  "payment confirmation", "invoice manipulation", "subscription bypass", "trial abuse",
  "payment flow", "financial API", "billing bypass", "pricing logic",
  "negative amount", "zero price", "float precision", "currency confusion",
  "payment race condition", "concurrent checkout", "gateway bypass", "gateway testing",
  "shipping fee bypass", "tax manipulation", "quantity manipulation", "item substitution",
  or discusses testing payment system security. It provides comprehensive methodology for
  payment system penetration testing using Hexstrike tools.
version: 2.0.0

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.