En bref
Guide les décisions d’intégration Stripe : environnement de développement et de test, choix d’API, Connect, facturation, taxe, Treasury, options d’intégration, migration d’API dépréciées, et sécurité (clés, permissions, webhooks, OAuth). On l’utilise pour planifier, construire, modifier, tester ou relire une intégration, y compris encaisser un paiement, monter une place de marché, poser des abonnements, collecter une taxe, ou créer des comptes connectés. Sauf consigne contraire, on vise la version d’API la plus récente indiquée par le skill (2026-10-28.endive au moment de la lecture) et le SDK à jour. Pour une intégration nouvelle, on utilise des bacs à sable séparés, pas le bac de test partagé du compte : un bac pour le développement local, un autre pour le CI. Le bac partagé ne reste que pour une intégration existante qui en dépend, ou lorsqu’une fonction requise n’est pas disponible dans les bacs généraux. On recommande une clé restreinte (préfixe `rk_`) plutôt qu’une clé secrète (`sk_`). On lit la référence du skill avant de répondre ou d’écrire du code. On n’inclut jamais `payment_method_types` dans un appel, sauf une intégration Terminal qui doit passer `card_present` ; pour une liste explicite, on utilise `allowed_payment_method_types`. Les webhooks ne sont jamais présentés comme facultatifs, et sont exigés pour les abonnements et les méthodes asynchrones : la délivrance se fait dans les gestionnaires `checkout.session.completed` et `checkout.session.async_payment_succeeded`, pas sur la page de succès. Avant d’activer `automatic_tax`, il faut une immatriculation active, sinon Stripe ne collecte aucune taxe tandis que l’on croit l’option allumée. Un paiement unique passe typiquement par Checkout Sessions ; une plateforme Connect, par Accounts v2 ; une facturation à l’usage nouvelle, par Metronome. Si l’on crée un bac avec `stripe sandbox create`, on n’utilise pas MCP tant que `stripe sandbox claim` n’a pas été fait. Les clés restent hors du fil et des journaux.
Ce que ça fait
- Cadre d’intégration Stripe : bacs séparés, clé restreinte, Checkout ou Connect selon le cas, webhooks obligatoires pour les flux asynchrones
- Pas de `payment_method_types` hors Terminal ; pas de taxe automatique sans immatriculation ; pas de secret dans le fil
Pour qui, et un exemple
Les développeurs qui planifient ou relisent une intégration Stripe — paiement, abonnement, place de marché ou taxe — et doivent choisir le bon environnement, la bonne API et les bons garde-fous.
Exemple de demande : « Pour cette nouvelle intégration de paiement, crée un bac à sable dédié, utilise Checkout Sessions, une clé restreinte, et pose les webhooks de délivrance, sans `payment_method_types`. »
Quand on planifie, construit ou relit une intégration Stripe, et non lorsqu’un skill plus étroit (doc, projets, mise à niveau d’API) suffit déjà à la demande. Exemple rédigé par iadujour.fr à partir du SKILL.md, non testé.
Installer
Claude Code : claude plugin install stripe@claude-plugins-official ; Codex : codex plugin add stripe@openai-curated ; Cursor : /add-plugin stripe ou la marketplace Cursor
claude plugin install stripe@claude-plugins-officialcodex plugin add stripe@openai-curated/add-plugin stripeFonctionne avec
- Claude Code
- Codex
- Cursor
- Grok Build
Source : README : procédures d’installation pour Claude Code, Codex, Cursor, Grok Build et le standard Agent Plugins.
Niveau : Débutant
S’utilise en langage naturel ; aucun prérequis de code n’est exigé par la description, au-delà du produit visé.
À savoir
Extrait du SKILL.md
La description d’origine, celle que l’agent lit pour décider de charger la skill (en anglais) :
Guides Stripe integration decisions across development and test environment planning (separate sandboxes vs the shared test mode sandbox), API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, tax and registrations (Stripe Tax, automatic_tax, product tax codes), Treasury financial accounts, integration options […]
Citée depuis le SKILL.md au commit 867a598 . Le dossier contient aussi 6 fichiers annexes (references/).
Le SKILL.md compte 61 lignes et 3 sections principales :
- Integration routing
- Critical rules
- Key documentation
Licence : MIT
Vérifiée le 10 novembre 2026 sur : fichier LICENSE du dépôt . Titulaire : Copyright (c) 2024–2025 Stripe.
La licence autorise la reprise : le texte intégral du SKILL.md est reproduit ci-dessous, sans modification, avec sa mention de licence.
Texte intégral du SKILL.md
Reproduit sans modification depuis stripe/ai (commit 867a598) , © Stripe, sous licence MIT (fichier de licence d’origine ).
Afficher le SKILL.md original (61 lignes, en anglais)
---
name: stripe-best-practices
description: >-
Guides Stripe integration decisions across development and test environment
planning (separate sandboxes vs the shared test mode sandbox), API selection
(Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2,
controller properties), billing/subscriptions, tax and registrations (Stripe
Tax, automatic_tax, product tax codes), Treasury financial accounts,
integration options (Checkout, Payment Element), migrating from deprecated
Stripe APIs, and security best practices (API key management, API key
permissions, webhooks, OAuth). Use when planning, building, modifying,
testing, or reviewing any Stripe integration, including choosing a development
environment, accepting payments, building marketplaces, integrating Stripe,
processing payments, setting up subscriptions, collecting sales tax, VAT, or
GST, creating connected accounts, or implementing secure key handling.
---
Latest Stripe API version: **2026-10-28.endive**. Always use the latest API version and SDK unless the user specifies otherwise.
Development and testing environment default: For new integration development, use separate [sandboxes](https://docs.stripe.com/sandboxes.md) instead of the account’s shared test mode sandbox. Sandboxes isolate settings and test data from live mode. Use separate sandboxes for local development and CI. When stronger isolation is useful, dedicate sandboxes to development teams or testing scenarios. Use the shared test mode sandbox only for an existing integration that depends on it or when a required feature doesn’t support general sandboxes.
Latest SDK versions:
| Language | Latest version |
| --- | --- |
| Ruby | 20.0.0 |
| Python | 16.0.0 |
| Node.js | 23.0.0 |
| PHP | 22.0.0 |
| Java | 34.0.0 |
| Go | 87.0.0 |
| .NET | 53.0.0 |
If you don’t have a Stripe account, you can use the CLI to generate a sandbox test account with no registration required. Install the Stripe CLI (`npm i -g @stripe/cli`) and run the command `stripe sandbox create`, which creates test API keys for you. When you recommend this, explain that [a sandbox is a Stripe test environment](https://docs.stripe.com/sandboxes.md).
If `stripe sandbox create` is used, don’t use MCP.
If you try to use MCP after running sandbox creation, first make sure `stripe sandbox claim` is run. Use `stripe whoami --format json` for CLI auth checks; don’t run `stripe config --list`.
API key default: Always recommend a [restricted API key (RAK)](https://docs.stripe.com/keys.md#manage-your-api-keys) (`rk_` prefix) over a secret key (`sk_` prefix).
## Integration routing
| Building… | Recommended API | Details |
| --- | --- | --- |
| One-time payments | Checkout Sessions | <references/payments.md> |
| Custom payment form with embedded UI | Checkout Sessions + Payment Element | <references/payments.md> |
| Saving a payment method for later | Setup Intents | <references/payments.md> |
| Connect platform or marketplace | Accounts v2 (`/v2/core/accounts`) | <references/connect.md> |
| Usage-based billing (new integration) | Metronome | <references/billing.md> |
| Subscriptions or recurring billing | Billing APIs + Checkout Sessions | <references/billing.md> |
| Sales tax, VAT, or GST compliance | Stripe Tax + Registrations API | <references/tax.md> |
| Embedded financial accounts / banking | v2 Financial Accounts | <references/treasury.md> |
| Security (key management, RAKs, webhooks, OAuth, 2FA, Connect liability) | See security reference | <references/security.md> |
Read the relevant reference file before answering any integration question or writing code.
## Critical rules
- *Before enabling `automatic_tax: { enabled: true }`* (or calculating tax for a custom PaymentIntent), read the [tax reference](references/tax.md) and confirm the user has an active registration. Without one, Stripe calculates and collects no tax while the user believes tax is on (the most common Stripe Tax mistake).
- *Never include `payment_method_types` in any Stripe API call*, with one exception: Terminal (in-person payments) integrations must pass `payment_method_types: ['card_present']` on the PaymentIntent. For all other integrations, omit this parameter entirely to enable dynamic payment methods, which enables you to configure payment method settings from the Dashboard and dynamically display the most relevant eligible payment methods to each customer to maximize conversion. To customize which payment methods you accept, use [payment_method_configurations](https://docs.stripe.com/payments/payment-method-configurations.md) or `excluded_payment_method_types` instead of `payment_method_types`.
- When a PaymentIntent or SetupIntent integration requires an explicit allowlist, use `allowed_payment_method_types` instead of `payment_method_types`.
- *Never present webhooks as optional.* We recommend webhooks for every payment integration and they’re required for subscriptions and asynchronous payment methods. Fulfillment belongs in a handler for both `checkout.session.completed` and `checkout.session.async_payment_succeeded` (gated on `payment_status`), not the success page. See <references/payments.md>.
- On API version `2026-03-25.dahlia` or later, pass the parameter `integration_identifier` to `checkout.sessions.create` to tag sessions with a custom label for tracking and comparing checkout flows in the Dashboard. The label should include a suffix of 8 random letters.
- *Always instantiate a `StripeClient` and call methods on that instance.* Do **not** use the deprecated global/module-level API key pattern (`stripe.api_key = …`, `Stripe.setApiKey`, `stripe.Key = …`, `StripeConfiguration.ApiKey = …`). The global pattern is deprecated in all current SDKs.
## Key documentation
When the user’s request does not clearly fit a single domain above, consult:
- [Integration Options](https://docs.stripe.com/payments/payment-methods/integration-options.md) — Start here when designing any integration.
- [API Tour](https://docs.stripe.com/payments-api/tour.md) — Overview of Stripe’s API surface.
- [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live.md) — Review before launching.
Dans l’annuaire
Cas d’usage et guides qui partagent un thème, un métier ou un outil avec cette skill.
Commentaires.
Un retour d’expérience, une question, une précision sur cette skill ? Les commentaires sont relus avant publication.
Commentaires publiés
Chargement des commentaires…
Laisser un commentaire
Charte de modération. Chaque commentaire est relu avant publication. Sont refusés : l’incitation à la haine, les propos injurieux ou discriminatoires, la publicité, le spam et les liens promotionnels, le hors-sujet et les données personnelles d’autrui.