Payment Security

Skill: Payment Systems Security

Supplementary Files:

• payloads.md — PCI-DSS 4.0 requirement map, Stripe/Adyen/PayPal API test patterns, 3-D Secure 2.x challenge flow probing, card testing / BIN attack detection, recurring billing manipulation, mobile wallet Frida hooks (Apple Pay / Google Pay), EMV L2/L3 review, fraud system (Sift / Forter) feature probing, Python pipeline for Stripe CLI / webhook replay / card-test bot detection
• test-cases.md — Structured test cases (PCI scope validation, ASV scan, Stripe webhook signature, 3DS challenge bypass, Apple Pay token interception, Google Pay SDK, Frida runtime hook, Sift feature probe, card test pattern detection, EMV replay, contactless relay, terminal config review) with severity and summary tables

Summary

Payment Systems Security skill domain covering financial operations.

Tools: Stripe CLI, Burp Suite (payment extensions), OWASP ZAP, mitmproxy, Postman, Frida, objection, MobSF, Nessus/Qualys (ASV), PCI-DSS Quick Reference, EMVCo test cards (+3 more)

Domain: financial

MITRE ATT&CK: T1566-Phishing (credential harvesting) + domain-specific

Description

Payment systems security covers the full cardholder-data lifecycle and the regulated ecosystem around it: PCI-DSS 4.0 compliance scoping and gap assessment, payment gateway API security (Stripe, Adyen, PayPal, Braintree), 3-D Secure 2.x authentication flows, mobile wallet tokenization (Apple Pay, Google Pay, Samsung Pay), EMV chip & contactless terminal review, recurring billing and subscription abuse, refund/chargeback fraud, and behavioral fraud-system assessment (Sift Science, Forter, Riskified, custom ML).

This is not generic API security. The distinction matters because payment systems sit inside a regulated perimeter (PCI-DSS 4.0, PSD2 in the EU, Reg E in the US, card-scheme operating regulations from Visa/Mastercard/Amex), touch a defined Cardholder Data Environment (CDE), and depend on cryptographic primitives (EMV cryptograms, 3-D Secure SDKs, network tokenization, device account numbers) that have no equivalent in a vanilla REST API. A single misconfiguration in scope delineation can pull an entire datacenter into PCI scope; a single leaked webhook signing secret can let an attacker mint successful payment confirmations; a single bypassed 3DS challenge shifts fraud liability back onto the merchant.

Difference from api-security: API security covers generic REST/GraphQL concerns (BOLA, broken auth, mass assignment). Payment-security applies those same concerns to a specific regulated domain — cardholder data minimization, PCI-DSS requirement traceability, processor sandbox-vs-production rules, 3DS challenge mechanics, and EMV cryptogram validation. The toolset adds Stripe CLI, Adyen test cards, EMVCo reference cards, and fraud-system test modes.

Difference from web-auth-bypass: Auth bypass targets session and access control logic (JWT, OAuth, cookie tampering). Payment security uses those techniques to probe payment-specific authorization: idempotency-key reuse on PaymentIntents, webhook replay with stale signatures, 3DS frictionless-vs-challenge routing, and refund authorization on already-captured charges.

Difference from mobile-security: Mobile security covers app-level concerns (certificate pinning, rooted/jailbroken detection, local data). Payment security targets the wallet integration layer inside the app: PKPaymentAuthorizationViewController delegate hooks on iOS, Google Pay PaymentsClient tokenization, device account number (DAN) interception, and the cryptographic handoff to the payment gateway.

Use Cases

• PCI-DSS 4.0 gap assessment: Map the client's cardholder data environment, validate scope delineation (segmentation, tokenization), and produce a requirement-by-requirement gap report against the 12 PCI-DSS 4.0 requirement families.
• Payment gateway API pentest: Stripe / Adyen / PayPal / Braintree — test webhook signature validation, idempotency keys, PaymentIntent lifecycle manipulation, and customer object data leakage in test mode (and, with explicit authorization, in production).
• 3-D Secure 2.x bypass testing: Probe the frictionless-vs-challenge routing, SDK fingerprinting, and authentication-value (CAVV/ECI) handling to find flows where strong customer authentication can be skipped in violation of PSD2 SCA requirements.
• Fraud system assessment: Test Sift Science / Forter / Riskified in their sandbox/test modes to understand feature-set inferences, decision thresholds, and what behavioral signals an attacker can probe without tripping the model.
• Mobile wallet integration review: Apple Pay (PassKit / PKPaymentAuthorizationViewController) and Google Pay (PaymentsClient / TokenizationSpecification) — review device account number handling, dynamic cryptogram validation, and the in-app token lifecycle.
• EMV chip & contactless terminal review: Terminal L2/L3 kernel configuration, contactless (CL-T / paywave / PayPass) relay-attack resistance, and on-device cryptogram validation.
• Recurring billing & subscription abuse: Plan-swap attacks, proration abuse, cancel/resume state-machine bugs, trial-period farming via card rotation, and metered-billing backdating.
• Marketplace / split-payment review: Stripe Connect, Adyen Marketplace, PayPal for Marketplaces — review platform-fee handling, connected-account authorization scope, and funds-release (escrow) logic.

Core Tools

Interception & Proxying

API Testing — Processors

Compliance & Scanning

Mobile Wallets

Card Testing & BIN Attack Patterns

| Capability | Command Example | |------|---------|-----------------| | Detect card-test bot velocity | grep -c 'POST /v1/payment_intents' access.log \| sort over time windows | | BIN-range enumeration detection | Cluster declined /v1/charges by BIN prefix; flag > 50 declines per BIN/hour | | CAPTCHA / rate-limit test | for i in $(seq 1 100); do curl -X POST .../checkout; done (with authorization) | | Test-mode card cyclcing | Use Stripe's deterministic test cards (4000 0027 6000 3184 → "insufficient funds") |

EMV

Fraud Systems (Test Mode Only)

Methodology

Payment Pentest Six-Phase Process

Phase 1            Phase 2            Phase 3            Phase 4            Phase 5            Phase 6
Scope & PCI        Compliance         API & Flow         Mobile Wallet      Fraud System       Report
Delineation    →   Check          →   Testing        →   Review         →   Assessment     →   & SAQ Mapping
   │                  │                  │                  │                  │                  │
   ▼                  ▼                  ▼                  ▼                  ▼                  ▼
Identify CDE,      Map 12 reqs,       Stripe/Adyen       Frida hooks on     Sift/Forter test   PCI gap report,
tokenization,      ASV scans,          API, webhooks,     PassKit /          mode, feature      API findings,
segmentation       SAQ selection       3DS, idempotency   PaymentsClient     probing            wallet findings,
                                                                                               fraud recs

Phase 1: Scope & PCI Delineation

Before any active testing, define what is and is not in the Cardholder Data Environment.

CDE In-Scope:                Out-of-Scope (if properly segmented):
- Cardholder data stores      - Merchandising CMS
- Payment gateway integration - Marketing analytics
- 3DS / MPI servers           - Internal HR systems
- Terminal management system  - Public marketing site
- Tokenization vault          - Post-tokenization order mgmt (sometimes)

Phase 2: Compliance Check

Map the client's controls to PCI-DSS 4.0's 12 requirement families and run ASV-approved external scans.

# External ASV scan (PCI-DSS mandated quarterly)
nessuscli scan PCI-DSS-External --target payments.example.com,api.example.com --policy "PCI Quarterly External"

# Internal CDE scan (PCI-DSS req 11.3)
qualys scan launch --title "PCI Internal CDE" --option "PCI-DSS-Internal"

# OpenSCAP host hardening baseline (req 2.2)
oscap xccdf eval --profile pci-dss --results scan.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Phase 3: API & Flow Testing

With processor sandbox credentials, exercise the full payment lifecycle.

# Stripe CLI — forward webhooks to local dev server
stripe listen --forward-to localhost:8000/webhooks --events payment_intent.succeeded,charge.failed

# In another terminal, trigger synthetic events
stripe trigger payment_intent.succeeded
stripe trigger charge.failed
stripe trigger invoice.payment_failed

# Replay attack — capture a webhook, modify amount, replay
# (legitimate Stripe sigs include a timestamp; verify the server rejects stale)

Phase 4: Mobile Wallet Review

Instrument the iOS / Android wallet integration.

# iOS Frida hook on Apple Pay authorization
frida -U -f com.example.app -l applepay_hook.js --no-pause

# Android Frida hook on Google Pay
frida -U -f com.example.app -l googlepay_hook.js --no-pause

# Inspect device account number (DAN) vs real PAN
# Should NEVER see raw PAN in the app — DAN is tokenized on-device by the wallet OS

Phase 5: Fraud System Assessment

Probe fraud systems in their test mode to understand decision boundaries — never trip a real fraud alert in production.

# Sift sandbox — send synthetic events
curl -X POST 'https://api.sift.com/v205/events' \
  -H "Content-Type: application/json" \
  -d "{
    \"\$api_key\": \"$SIFT_SANDBOX_KEY\",
    \"\$user_id\": \"test_user_001\",
    \"\$type\": \"\$create_order\",
    \"\$order_id\": \"order_test_001\",
    \"\$amount\": 5000000
  }"

Phase 6: Report & SAQ Mapping

Produce a PCI-DSS-aligned report that maps every finding to a specific requirement number.

Quick Selection Guide

Defense Perspective

Practical Steps

Detailed payloads in payloads.md, complete test checklist in test-cases.md.

Exercise 1: PCI-DSS Scope Mapping

Goal: identify what is and is not in scope, so the client knows what must meet PCI requirements.

# Inventory: which systems store, process, or transmit PAN?
# Walk through each component and answer:
#   - Does it store PAN? (database, log, backup)
#   - Does it process PAN? (payment gateway, fraud service)
#   - Does it transmit PAN? (TLS channel to gateway)

# Output: a CDE boundary map like:
#
#   Customer browser ─ TLS ─> Checkout API ─> Stripe ─> Card network
#                                  │
#                                  └──> Order DB (tokenized card_id, NOT PAN)
#
#   In-scope: Checkout API, Stripe integration, any system that can see PAN pre-tokenization
#   Out-of-scope (if segmented): Order DB (stores token), fulfillment, CRM

# Verify segmentation (PCI req 1.2/1.3):
nmap -p1-65535 -sV --reason <out-of-scope-system> --script=firewalk --traceroute
# If a path exists from out-of-scope to CDE without a firewall/ACL, segmentation is broken

Exercise 2: Stripe CLI Webhook Testing

Goal: verify the client's webhook handler validates signatures and rejects replays.

# Install Stripe CLI
# https://stripe.com/docs/stripe-cli
stripe login

# Forward webhooks to local dev server
stripe listen --forward-to localhost:8000/webhooks \
  --events payment_intent.succeeded,charge.failed,invoice.payment_succeeded

# In another terminal, trigger synthetic events
stripe trigger payment_intent.succeeded
stripe trigger charge.failed
stripe trigger invoice.payment_succeeded

# Capture the raw webhook payload + signature, then replay with modified amount
# (See payloads.md Section 2 for the full replay attack)

Exercise 3: 3DS Challenge Bypass Testing

Goal: find flows where Strong Customer Authentication can be skipped.

# Test the 3DS routing logic on the checkout API
curl -X POST https://api.example.com/checkout/3ds-route \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 2900,
    "currency": "usd",
    "card": "4000 0027 6000 3184",
    "merchant_category": "low_value"
  }'

# Variations to test:
# 1. Amount just under low-value exemption threshold (PSD2: €30, €100 cumulative)
# 2. Trusted beneficiary list manipulation
# 3. Corporate card (B2B) exemption abuse
# 4. Recurring transaction exemption on first payment

Exercise 4: Mobile Wallet Frida Hooking

Goal: confirm the app never sees raw PAN — only the tokenized DAN.

// applepay_hook.js — hook the Apple Pay authorization delegate
Interceptor.attach(ObjC.classes.PKPaymentAuthorizationViewController['- paymentAuthorizationViewController:didAuthorizePayment:completion:'].implementation, {
  onEnter: function(args) {
    const payment = new ObjC.Object(args[3]);
    const token = payment.token();
    const paymentData = token.paymentData();
    console.log("[+] Apple Pay token intercepted:");
    console.log("    DAN (device account number):", token.transactionIdentifier().toString());
    console.log("    paymentData:", paymentData.toString());
    // paymentData contains: applicationPrimaryAccountNumber (DAN, NOT real PAN),
    //                       applicationCryptogram, paymentDataType, etc.
  }
});

Exercise 5: Card Testing Pattern Detection

Goal: detect (or simulate) a card-testing bot sweeping BIN ranges.

# Simulate card test (with authorization, in sandbox only)
for i in $(seq 1 20); do
  pan="4111 1111 $(printf '%04d' $i) $(printf '%04d' $((i*7%10000)))"
  curl -X POST https://api.example.com/checkout \
    -H "Content-Type: application/json" \
    -d "{\"card\": \"$pan\", \"amount\": 100, \"currency\": \"usd\"}"
done

# Detection (defense side):
# Aggregate checkout requests by BIN prefix per hour
awk '/POST \/checkout/ {print $1, $5}' /var/log/nginx/access.log \
  | grep -oE '[0-9]{4} [0-9]{4}' \
  | sort | uniq -c | sort -rn | head -20

# Alert threshold: > 50 declines per BIN per hour = card testing in progress

Exercise 6: Recurring Billing Manipulation

Goal: find subscription state-machine bugs that grant free service or unwanted upgrades.

# Probe plan-swap endpoints for proration bugs
curl -X POST https://api.example.com/subscriptions/sub_123/swap \
  -H "Content-Type: application/json" \
  -d '{"new_plan": "enterprise_annual", "prorate": false}'

# Probe trial-period farming
# Cancel trial, immediately re-subscribe — should NOT grant a new trial
curl -X POST https://api.example.com/subscriptions/sub_123/cancel
curl -X POST https://api.example.com/subscriptions \
  -d '{"plan": "pro_monthly", "trial_days": 14}'  # should be rejected

# Probe pause/resume state for backdated billing
curl -X POST https://api.example.com/subscriptions/sub_123/pause \
  -d '{"until": "2020-01-01"}'  # backdated pause = refund abuse

Exercise 7: Fraud System Testing

Goal: probe Sift / Forter sandbox to understand feature inference without tripping production.

# Sift sandbox — send events with escalating risk signals
# (NEVER test against production fraud systems without explicit authorization)

# Legitimate-looking order
curl -X POST https://api.sift.com/v205/events \
  -H "Content-Type: application/json" \
  -d "{
    \"\$api_key\": \"$SIFT_SANDBOX_KEY\",
    \"\$user_id\": \"u_normal\",
    \"\$type\": \"\$create_order\",
    \"\$amount\": 4999
  }"

# Same user, suddenly high-risk signals
curl -X POST https://api.sift.com/v205/events \
  -d "{
    \"\$api_key\": \"$SIFT_SANDBOX_KEY\",
    \"\$user_id\": \"u_normal\",
    \"\$type\": \"\$create_order\",
    \"\$amount\": 50000000,
    \"\$ip\": \"185.220.101.5\",
    \"\$billing_address\": {\"\$country\": \"RU\"}
  }"

Exercise 8: EMV L2/L3 Terminal Review

Goal: review terminal configuration for cryptogram validation and contactless relay resistance.

# Read EMV tags from a card via PC/SC reader
scriptor <<EOF
00A4040007A000000004101000
80A8000002830000
EOF

# Key tags to inspect:
# 9F26 (AC, Application Cryptogram) — must be verified by terminal/issuer
# 9F10 (IAD, Issuer Application Data) — contains CVR, CID
# 9F36 (ATC, Application Transaction Counter) — must be monotonically increasing
# 95 (TVR, Terminal Verification Results) — records what checks failed

# L2 kernel config review (vendor-specific):
# - Is CDA (Combined DDA/Application Cryptogram Generation) enabled?
# - Are online PIN and signature fallbacks configured per card scheme rules?
# - Is contactless CL-T limit enforced per region (e.g., €50 in EU)?

Exercise 9: PCI-DSS Audit Report Assembly

Goal: produce a deliverable that maps every finding to a PCI requirement.

# PCI-DSS 4.0 Gap Assessment — Example Corp

## Finding 1: Webhook signature not verified
- PCI-DSS 4.0 req: 6.5.1 (web application security), 10.2 (audit logging)
- Severity: HIGH
- Risk: Attacker can forge payment success notifications
- Remediation: Verify Stripe-Signature on /webhooks/stripe with 5-min tolerance

Detection Methods

PCI-DSS Compliance Audit

• Cardholder data exposure: PAN (Primary Account Number) appearing in logs; alert on regex \b\d{13,19}\b.
• TLS version: TLS 1.0/1.1 still in use; non-compliance with PCI-DSS 3.2.1+.
• Encryption key rotation: Keys not rotated per PCI-DSS schedule.
• Network segmentation: Cardholder Data Environment (CDE) not isolated; alert on cross-segment traffic.

SIEM Detection Rules

• Splunk SPL: index=app | regex message="\b\d{13,19}\b" | stats count by source
• PCI scanner: ASV (Approved Scanning Vendor) quarterly scans.

Defense Evasion Techniques

Card Data Theft Stealth

• Tokenization abuse: Use legitimate payment token to bypass PAN scanning.
• Skimming stealth (Magecart): Inject skimmer via compromised CDN; evade CSP.
• Slow exfiltration: Pace exfil below baseline; <100 cards/day.

Payment Fraud Stealth

• Use legitimate merchant account: Compromise legitimate merchant; appears as legitimate transaction.
• Test cards first: Use BIN test cards to validate fraud logic before mass fraud.
• Off-hours fraud: Execute fraud during low-activity hours; less monitoring.

CDE Lateral Movement

• Use PCI-exempt paths: Move laterally via paths not subject to PCI monitoring (mgmt VLAN).
• Compromise jump host: Pivot through jump host that has CDE access; appears as legitimate admin.
• Memory-only card capture: Capture card data from process memory; no disk writes.

Safety Notes

• Authorization is non-negotiable: Never test production payment systems without a signed Statement of Work that explicitly names the cardholder data environment, the processor accounts, and the test window. PCI-DSS violations carry fines (per-incident, monthly, or card-scheme-level termination) and many jurisdictions criminalize unauthorized access to financial systems.
• Use sandbox credentials: Stripe (test mode sk_test_...), Adyen (test merchant account), PayPal (sandbox at api-m.sandbox.paypal.com) all offer full-featured test environments. Use them for everything except final authorized production validation.
• PCI scope delineation: Stay inside the agreed scope. Probing systems the client has declared out-of-scope (e.g., a marketing CMS) without re-confirmation can pull them into scope and trigger remediation costs.
• Cardholder data minimization: Never log full PAN, CVV, or track data in your test artifacts. Use masked test cards (4111 1111 XXXX 1111) and redact PAN in Burp logs (configure match-and-replace). PCI-DSS req 3.4 mandates PAN masking.
• Fraud system test mode only: NEVER send synthetic events to a production fraud system (Sift/Forter/Riskified) without explicit authorization — a single high-risk event can flag your IP, taint the merchant's risk profile, or trigger card-scheme monitoring.
• EMV terminal testing: Use only EMVCo reference cards or client-provided test cards on the terminal-under-test. Live cards on a non-certified terminal can void the merchant's certification.
• Legal/regulatory liability: PSD2 (EU), Reg E (US), card-scheme operating regulations, and local financial-services laws all apply. When in doubt, ask the client's legal counsel — not your pentest lead.
• Non-disclosure: Payment system details (processor account IDs, signing secrets, merchant IDs) are NDA-protected. Encrypt at rest, shred on engagement close.

Hacker Laws

• Trust but Verify — Payment webhooks are unauthenticated until proven otherwise. Verify the signature, the timestamp tolerance, and the idempotency. Stripe's Stripe-Signature header includes t= (timestamp) and v1= (signature); missing timestamp checks open replay windows measured in hours.
• Defense in Depth — A payment system that relies on a single control (e.g., "the gateway rejects bad cards") will fail when that control is bypassed. Layer gateway-side checks with your own server-side amount/quantity validation, fraud-system scoring, and human review for high-value outliers.
• Least Privilege — Cardholder Data Minimization — Every system that can see PAN is in PCI scope. The strongest payment design is one where PAN never touches your servers — Stripe Elements / Adyen Drop-in / PayPal Smart Buttons tokenize client-side and your backend only ever sees a token. This is PCI-DSS req 3 (protect stored cardholder data) applied as architecture.
• Assume Breach — When (not if) an attacker gets into your network, what can they do with payment data? Tokenization limits blast radius. Network segmentation prevents lateral movement into the CDE. Encrypted-at-rest PAN (with HSM-backed key management) prevents mass exfiltration. Audit logging (req 10) gives you the trail to reconstruct what happened.
• Information Wants to Be Free — Cardholder data, like all data, leaks. The question is whether it leaks as raw PAN (catastrophic) or as an opaque token (acceptable). Tokenization is the architectural answer to this law.

Learning Resources

• This skill's supplementary files: payloads.md, test-cases.md
• Deep-dive guide: guides/payment-pentest-playbook.md — end-to-end payment pentest from scoping through PCI delineation, API testing, mobile wallet review, fraud system probing, EMV terminal review, and report assembly
• Related skills:
  • skills/api-security/SKILL.md — generic REST/GraphQL API testing (payment APIs are a subset)
  • skills/web-auth-bypass/SKILL.md — auth flow testing (3DS, idempotency, webhook auth build on this)
  • skills/mobile-security/SKILL.md — mobile app analysis (PassKit, PaymentsClient, Frida hooks)
  • skills/crypto-attacks/SKILL.md — cryptographic primitives (EMV cryptograms, 3DS CAVV/ECI, tokenization crypto)
  • skills/pentest-reporting/SKILL.md — report assembly and SAQ mapping
  • skills/engagement-manager/SKILL.md — scoping and authorization for regulated engagements
• External resources:
  • PCI Security Standards Council: pcisecuritystandards.org
  • PCI-DSS 4.0 Quick Reference: PCISSC document library
  • Stripe docs (security section): stripe.com/docs/security
  • Stripe CLI: stripe.com/docs/stripe-cli
  • Adyen docs: docs.adyen.com
  • PayPal Developer: developer.paypal.com
  • EMVCo specifications: emvco.com
  • 3-D Secure 2.x spec: EMVCo 3DS
  • Apple Pay developer: developer.apple.com/apple-pay
  • Google Pay developer: developers.google.com/pay/api
  • OWASP API Security Top 10: owasp.org/API-Security
  • PSD2 SCA guidance (EBA): eba.europa.eu
• Core system files: SOUL.md, TOOLS.md, IDENTITY.md