paymentslisted

# Payments & Billing — Moving Money Without Losing It A practical guide to integrating a payment provider such that money is never double-charged, never silently lost, and always reconcilable. Stack-agnostic; recipes target Stripe as the reference provider, with Adyen / Braintree / PayPal noted where the model differs. The governing mindset: **a payment bug is a money bug, and money bugs are visible to finance, regulators, and angry customers.** ## When to Use This Skill - Wiring a first charge / checkout — payment intents, hosted fields, confirmation flow. - Handling a provider webhook (`payment_intent.succeeded`, `charge.refunded`, `invoice.paid`). - Designing a subscription, metered/usage billing, free trial, proration, or dunning flow. - Making money movement idempotent — a retried request must never charge twice. - Issuing refunds, handling disputes/chargebacks, partial captures. - Reconciling provider state against an internal ledger; closing the books. Skip when: the work is a generic non-money API endpoint (api-design) or generic auth/injection hardening (security-web) with no money movement — those skills own that. This skill is specifically the financial-correctness layer. ## The Five Money-Correctness Invariants These override convenience every time: 1. **Never trust a client-sent amount.** The price is computed server-side from the cart/plan, never read from the request body. A client that POSTs `{"amount": 1}` for a $1000 order must be charged $1000. This