payment-integration-disciplinelisted

# Payment integration discipline Scope: payment-integration-discipline — Stripe/RevenueCat integration shape, the mobile IAP regulatory surface, PCI-scope avoidance, and webhook idempotency. It does not own the legal/compliance judgment call on a given feature (that's `feature-legal-risk-checklist`, §5) or general error-handling mechanics beyond payment-specific idempotency (`error-handling-and-resilience` owns retries/timeouts/circuit breakers generally). **Any task that touches payments fires the forge-security review trigger.** Money/payment is a NAMED trigger in the verification-economics conventions (`docs/conventions.md`, "Verification economics — 2026-07-18") — a payment diff is reviewed by `forge-security` on that named trigger regardless of how small the change looks, the same way an auth/token/secret touch is. Don't assume a "just adds a field" payment change is exempt; the trigger is on the surface touched, not the diff size. This skill pairs with `skills/feature-legal-risk-checklist` — that skill's **Payments** risk area covers the compliance-checklist half (PCI-DSS scope minimization, what to disclose); this skill covers the engineering-integration half (how to actually keep raw card data out of your system, how to make webhooks safe). Run both on any payment-touching task, not either/or. ## 1. Stripe and RevenueCat — pick by surface, not by preference - **Stripe** (or an equivalent processor — Adyen, Braintree) is the default for **web/server-initiated pa