payments
Payments
This skill turns an app into a SaaS that actually collects money — and does it without the classic bugs (fulfilling on the client redirect, double-granting access, unverified webhooks).
Analogy: the checkout redirect is the customer saying "I'll pay." The webhook is the bank confirming the money arrived. You ship the product when the bank confirms, not when the customer promises. Trusting the redirect is shipping on a promise.
The Stripe MCP split (read this first)
A Stripe MCP may be available (mcp__stripe__*). It is control-plane only: it creates products, prices, and payment links, and reads/updates subscriptions and customers. It cannot create Checkout Sessions or process webhooks.
So the architecture is hybrid:
- Delegate the catalog to the MCP — use it to create products, prices, and one-off payment links (the lowest-effort path for an MVP).
- Embed the integration code — Checkout Session creation, the webhook handler, and fulfillment must live in your shipped code, because the MCP can't do them.
If no MCP is present, create the catalog by hand in the Stripe dashboard or via the SDK; everything else below is identical.
Backend delegation: if you're on InsForge (see the data-modeling skill), its insforge / insforge-cli skills wire Stripe checkout, subscriptions, the customer portal, and the webhook handler for you — let them own the plumbing. The rules below still hold regardless (fulfill only on the webhook, verify the signature, stay idempotent); InsForge automates the wiring, it doesn't change what "correct" means. On Vercel/Node you write the handler yourself as shown. Never block on a missing skill.