stripe-best-practices

Installation
Summary

Authoritative guidance for implementing Stripe payment integrations across all use cases.

  • Prioritizes Checkout Sessions API for on-session payments and subscriptions; recommends Stripe-hosted or embedded Checkout as the primary web integration surface
  • Covers payment flows, subscription models, webhooks, Connect platforms, and fund management with explicit guidance on modern APIs versus deprecated endpoints
  • Includes pre-launch checklist requirements, PCI compliance considerations, and migration paths from legacy Charges, Sources, and Card Element implementations
  • Advises using dynamic payment methods, Confirmation Tokens for pre-authorization inspection, and Billing APIs for recurring revenue models like SaaS
SKILL.md

When designing an integration, always prefer the documentation in Stripe's Integration Options doc The API Tour Use the Go Live Checklist 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. 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 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 to Checkout Sessions or Payment Intents.

The primary integration surface for web integrations is Checkout, 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 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.

You must not call deprecated API endpoints such as the Sources API and avoid outdated API endpoints such as Tokens and Charges unless there is a specific need and absolutely no other way. Advise using the Setup Intent API 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 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.

Related skills

More from anthropics/claude-plugins-official

Installs
1.4K
GitHub Stars
19.2K
First Seen
Jan 19, 2026