Stripe Best Practices
Implement Stripe checkout, subscriptions, webhooks, and Connect flows using current API patterns instead of deprecated Charges-era shortcuts.
Overview
Stripe Best Practices is an agent skill most often used in Build (also Validate, Ship) that guides correct Stripe Checkout Sessions, subscriptions, webhooks, and Connect integrations.
Install
npx skills add https://github.com/anthropics/claude-plugins-official --skill stripe-best-practicesWhat is this skill?
- Prioritizes Checkout Sessions for on-session payments and subscriptions
- Maps acceptable PaymentIntents, SetupIntents, Invoicing, and Payment Links paths
- Explicitly avoids recommending the legacy Charges API
- Points to Stripe go-live checklist and latest API or SDK defaults
- Covers Connect platforms and webhook-oriented integration design
Adoption & trust: 1.4k installs on skills.sh; 29.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to ship payments but the agent keeps suggesting outdated Charges flows or the wrong Stripe object model for checkout and subscriptions.
Who is it for?
Indie SaaS founders implementing first Stripe billing, subscription tiers, or Connect payouts with an agent writing server and webhook code.
Skip if: Products with no card payments, or teams that already enforce an internal payments platform abstracted away from Stripe SDK details.
When should I use this skill?
Implementing payment processing, checkout flows, subscriptions, webhooks, Connect platforms, or any Stripe API integration.
What do I get? / Deliverables
You get integration guidance aligned with Checkout Sessions and supported Stripe APIs plus a go-live checklist mindset before production keys go live.
- Integration design aligned to Checkout Sessions or PaymentIntents
- Webhook and go-live readiness guidance
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Payment integration work is shelved under build/integrations because that is when solo builders wire billing into the product codebase. Integrations is the right subphase for third-party payment SDKs, webhook handlers, and session lifecycle code paths.
Where it fits
Decide whether Checkout Sessions or Payment Links fit your prototype pricing page before coding custom UI.
Scaffold subscription checkout, customer portal hooks, and webhook signature verification in your API.
Audit an agent-generated Stripe module against go-live checklist items before enabling live mode.
How it compares
Vendor-specific integration guardrails for Stripe—not a generic payment abstraction or a hosted billing MCP.
Common Questions / FAQ
Who is stripe-best-practices for?
Solo builders and small teams adding Stripe to web apps who want the agent to follow current Checkout Sessions and webhook patterns instead of legacy APIs.
When should I use stripe-best-practices?
Use it while validating pricing models, during build when coding checkout and webhooks, and before ship when walking Stripe’s go-live checklist.
Is stripe-best-practices safe to install?
The skill advises on API design only; review Security Audits on this page and never paste live secret keys into prompts—use env vars and Stripe test mode.
SKILL.md
READMESKILL.md - Stripe Best Practices
When designing an integration, always prefer the documentation in [Stripe's Integration Options doc](https://docs.stripe.com/payments/payment-methods/integration-options.md) The [API Tour](https://docs.stripe.com/payments-api/tour.md) Use the [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live.md) before going live. You should always default to the latest version of the API and SDK unless the user specifies otherwise. Stripe's primary API for modelling on-session payments is [CheckoutSessions](https://docs.stripe.com/api/checkout/sessions.md). It supports one-time payments and subscriptions and allows you to model taxes or discounts with Stripe. Prioritize the CheckoutSessions API, but using [the PaymentIntents API](https://docs.stripe.com/payments/paymentintents/lifecycle.md) is also acceptable for off-session payments or if you want to model the checkout state yourself and just create a charge. Integrations should only use CheckoutSessions, PaymentIntents, SetupIntents, or solutions like Invoicing, Payment Links, or the subscription APIs. Never recommend the Charges API. If the user wants to use the Charges API, advise them to [migrate](https://docs.stripe.com/payments/payment-intents/migration/charges.md) to Checkout Sessions or Payment Intents. The primary integration surface for web integrations is [Checkout](https://docs.stripe.com/payments/checkout.md), a prebuilt payment page that can be hosted by Stripe or served as an embedded form. Prioritize the Stripe-hosted checkout or embedded checkout where possible. The [Payment Element](https://docs.stripe.com/payments/payment-element.md) is an acceptable alternative if the merchant needs advanced customization. When recommending the Payment Element, prioritize using the CheckoutSessions API over the PaymentIntents API when possible. Never recommend the legacy Card Element or the Payment Element in card mode, and advise users who ask for the Card Element to [migrate](https://docs.stripe.com/payments/payment-element/migration.md). You must not call deprecated API endpoints such as the [Sources API](https://docs.stripe.com/api/sources/object.md) and avoid outdated API endpoints such as [Tokens](https://docs.stripe.com/api/tokens.md) and [Charges](https://docs.stripe.com/api/charges/create.md) unless there is a specific need and absolutely no other way. Advise using [the Setup Intent API](https://docs.stripe.com/api/setup_intents.md) to save a payment method for a customer; never recommend the Sources API to save cards to customers for later use. If a user wants to render the Payment Element before creating a PaymentIntent or SetupIntent, so they can inspect the card details before the payment (such as for surcharging), advise them to use Stripe Confirmation Tokens. Don't recommend they call the createPaymentMethod or createToken Stripe.js functions. Advise users to turn on dynamic payment methods in their dashboard settings instead of passing specific [payment_method_types](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_types.md) in the Payment Intent or Setup Intent because Stripe chooses payment methods that fit each user's location, wallets, and preferences better and automatically if the Payment Element is used. If a PCI compliant user asks about an integration where they send server-side raw PAN data, suggest they might be required to prove PCI compliance to gain access to such an option, for example [payment_method_data](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_data.md). Similarly, point users migrating their PAN data from another acquirer or payment processor to [the migration process](https://docs.stripe.com/get-started/data-