Stripe + Webtwizz

Standard Stripe is what most SaaS apps use. You collect money on your own Stripe account, customers pay you, you pay yourself. Built for direct-to-consumer or B2B subscriptions.

Stripe Connect is for marketplaces and platforms, you sit between buyers and sellers, take a cut, and pay out the rest. Examples: a freelance marketplace (you take 10%, the freelancer gets 90%), a coaching platform (each coach has their own Stripe account), a SaaS where each tenant gets their own Stripe.

Webtwizz uses Stripe Connect OAuth for the integration because Connect's read_write scope is a superset of what standard Stripe needs. Connect works seamlessly for both. Your STRIPE_ACCOUNT_ID env var is the connected account; for a non-marketplace app you just ignore it.

Three Connect models to know: - Standard accounts. Sellers fully manage their own Stripe dashboard. Easiest to set up. Right for "creators get paid" platforms. - Express accounts. Sellers see a slimmed-down dashboard. Right for marketplaces where you want to abstract Stripe away from sellers. - Custom accounts. You handle everything via API; sellers never see Stripe. Highest compliance burden but max control. Right for high-volume marketplaces.

Webhook handling is where most SaaS launches break. The patterns that matter:

Verify the signature on every request. Set STRIPE_WEBHOOK_SECRET in env vars, then verify in the handler with stripe.webhooks.constructEvent(payload, sig, secret). Unsigned/invalid requests must be rejected, anyone can hit your endpoint URL otherwise.

Handle the three events that matter most for subscriptions: checkout.session.completed (initial purchase), customer.subscription.updated (plan changes, cancellation scheduled), customer.subscription.deleted (subscription ended). Skipping any of these creates billing-state drift.

Idempotency. Stripe will retry webhooks on failure. Use the event ID as a dedup key, drop the event into a "processed_events" table with the Stripe event ID, ignore if already there. Otherwise a retried event will double-grant credits.

Don't downgrade on subscription.updated when cancellation is scheduled. The user paid through the period. Wait for subscription.deleted (or check current_period_end) to actually flip access off.

Ask Webtwizz "scaffold a Stripe webhook handler for subscription events with idempotency and signature verification" and it generates all of this correctly. The boilerplate that used to eat a weekend.