paymentslisted

Use to accept a ONE-TIME / on-demand payment for your own business with Stripe — the PaymentIntent-based flow and the four surfaces that sit on top of it. Covers choosing between Payment Links (no-code), Checkout Sessions (low-code, Stripe's default), Payment Element / Elements (custom UI), and raw PaymentIntents (max control); the PaymentIntent lifecycle & statuses; automatic vs manual (authorize-then-capture) capture; SCA / 3D Secure handling; and refunds vs cancel. For recurring charges route to stripe-suite:billing; for marketplace payouts route to stripe-suite:connect; for the authoritative fulfilment signal route to stripe-suite:webhooks. Triggers — "accept a payment", "one-time payment", "PaymentIntent", "client_secret", "confirm payment", "Checkout Session", "Payment Element", "Elements", "Payment Link", "capture / manual capture / authorize", "requires_action / requires_capture", "3D Secure / 3DS / SCA / next_action", "refund / cancel a payment". API version pinned 2026-06-24.dahlia.
Florkin/claude-stripe-skills · ★ 0 · Web & Frontend · score 70

Install: claude install-skill Florkin/claude-stripe-skills

# Stripe Payments (one-time payments) Accepting a single, on-demand payment for **your own** business. Every route below resolves to the same core object — the **PaymentIntent** — which tracks the money through its lifecycle. The four routes differ only in how much UI Stripe builds for you vs how much you build yourself. **Pinned Stripe API version: `2026-06-24.dahlia`.** Override per request with the `Stripe-Version` header; each webhook endpoint pins its own version at creation (independent of your SDK/API pin). Foundations (keys, idempotency, money model, errors, CLI, testing) come from **stripe-suite:integration** — don't re-derive them here. Not a one-time payment? **Recurring / subscription / trial / metered / invoice → stripe-suite:billing.** **Platform / marketplace / split funds → stripe-suite:connect.** New to Stripe? Start at **stripe-suite:integration**. All examples are SDK-neutral (raw REST + a one-line cross-SDK note). Nothing here is framework-specific. --- ## When to use / decision tree Two axes: **how much control** you need over the UI, and **how much code** you're willing to write. Default down the list — only move further down when a built-in you need is missing. | Route | Pick it when | Code | Detail | |---|---|---|---| | **Payment Links** | No dev resources; a shareable URL / QR / buy-button is enough (quick sell, donation) | None | `reference/checkout.md` | | **Checkout Sessions** | Fast online checkout; you want built-in tax, discounts, shippi