stripe-checkout-and-pricing-model-defaults

Stripe Checkout And Pricing Model Defaults

Use this skill when the task is about pricing-model setup or Checkout implementation choices.

Scope

• products and prices as the billing catalog
• recurring pricing model selection
• Checkout Sessions as the default integration API
• hosted checkout as the default first implementation
• checkout success and cancel flow boundaries

Routing cues

• create products or prices, pick flat-rate vs per-seat vs usage-based pricing, set up Checkout, create checkout sessions, enable promo codes, collect tax, or decide between hosted checkout and more custom payment UI -> use this skill
• once the task becomes mostly about webhook processing, event verification, or post-checkout state sync -> use stripe-webhook-first-billing-state
• once the task becomes mostly about subscription lifecycle semantics, retries, proration, or entitlements -> use stripe-subscriptions-lifecycle-and-entitlements
• once the task is really about self-serve plan management after checkout -> use stripe-customer-portal-defaults

Default path

1. Model the catalog with Products and Prices first.
2. Give durable prices stable lookup keys and keep price IDs server-controlled.
3. Prefer hosted Checkout Sessions for the first production implementation.
4. Create Checkout Sessions on the server using existing price IDs rather than trusting client-supplied amounts.
5. Use success and cancel URLs for navigation only.
6. Handle provisioning, subscription activation, and internal billing-state updates in webhook handlers.

When to deviate

• Use a more custom payment UI only when hosted checkout is a proven product mismatch.
• Create dynamic prices only when the business model truly requires per-quote or highly variable pricing.
• Reach for usage-based pricing only when usage measurement is part of the actual business model, not because it sounds flexible.
• Keep one-time and recurring purchases separate unless a combined cart is a real requirement.