Stripe en dev

Ce qu’il faut retenir. Rebond est la plateforme Stripe ; chaque club a son propre compte Stripe (Connect Standard), sur lequel les joueurs paient directement. En local, une sandbox Stripe tient le rôle de la plateforme, et bo stripe connect y rattache le compte du club de dev. La décision est dans l’ADR-0015.

Qui est qui

• La plateforme : la sandbox « Rebond dev ». Ses clés sont celles de .env.local (STRIPE_SECRET_KEY) ; elle ne détient jamais l’argent des clubs.
• Les clubs : des comptes connectés Standard dans cette sandbox, un par club (club_payment_accounts). Le paiement d’un joueur est un débit direct sur le compte du club ; Rebond peut y prélever sa commission (application_fee_amount, PLATFORM_FEE_BP, 0 par défaut).
• Pas de deuxième sandbox par club. Une autre sandbox ne sert qu’à un autre environnement (staging).
• Jamais de compte Express ou Custom, même en dev : Stripe y refuse les débits directs pour les nouvelles plateformes.

Un compte a un statut, qui vient toujours de Stripe (account.updated, ou « Vérifier » dans Réglages › Club) : pending (configuration à terminer), active (les cartes passent), restricted (Stripe demande un complément). Seul un compte active ouvre le paiement par carte aux joueurs.

Les deux clés

Clé	D’où elle vient
STRIPE_SECRET_KEY	la sandbox, Développeurs › Clés API (sk_test_…)
STRIPE_WEBHOOK_SECRET	bo stripe listen l’affiche au démarrage (whsec_…)

Elles vont dans .env.local, à la racine du dépôt principal (chaque worktree y pointe). .env.local ne remplace jamais une variable déjà exportée par le shell : bo doctor le signale (WARNING the shell exports …), sans afficher de valeur. Un STRIPE_WEBHOOK_SECRET périmé dans un profil shell fait refuser chaque événement en 400.

En staging et en production, Stripe signe les événements de la plateforme et ceux des comptes connectés avec deux secrets différents : le second va dans STRIPE_CONNECT_WEBHOOK_SECRET. pnpm bo deploy webhooks enregistre les deux webhooks par l’API, à la version d’API du SDK, et écrit leurs secrets dans .env.staging.local sans les afficher. En local, stripe listen n’en a qu’un, qui vérifie les deux.

Rendre le club local encaissable

stripe login                 # une fois, puis : stripe switch (choisir la sandbox)
pnpm bo stripe connect       # crée ou rattache le compte du club bo, attend le clic
pnpm bo stripe listen        # dans un autre terminal, pendant bo dev

bo stripe connect :

1. active Connect sur la sandbox (stripe tools enable_connect, sans effet la deuxième fois) ;
2. crée un compte Standard français prérempli avec l’identité de test de Stripe (né le 1er janvier 1901, adresse address_full_match, IBAN de test, MCC 7941) ;
3. affiche le lien d’onboarding : il ne reste qu’à accepter les conditions sur la page de Stripe, la seule étape que le titulaire d’un compte Standard doit faire lui-même ;
4. attend que les paiements soient ouverts (charges_enabled), puis enregistre le compte comme active et note son identifiant dans .env.local (BO_STRIPE_TEST_ACCOUNT).

Ce clic se fait une fois par sandbox : bo e2e setup rattache ensuite le compte à chaque fois (« payments: card payments on acct_…1234 »), dans tous les worktrees. Sans BO_STRIPE_TEST_ACCOUNT, la commande le dit : « cash-only ». Pour rattacher un compte qui existe déjà : bo stripe connect --account acct_… ; --no-wait affiche le lien sans attendre. Un compte resté en attente avec une mauvaise adresse : bo stripe connect --club <slug> --replace --email <adresse> en crée un nouveau et supprime l’ancien (jamais un compte déjà activé, ni le compte partagé BO_STRIPE_TEST_ACCOUNT).

bo doctor résume : « payments: platform test keys · club account acct_…1234 active », ou « none (bo stripe connect) ».

Ce que ne font ni la CI ni l’e2e

Aucun test ne parle à Stripe. Les tests du domaine utilisent acct_test_bo et un fournisseur simulé ; l’e2e et les parcours du site lancent l’API avec FAKE_PAYMENTS=true : un Stripe simulé en mémoire (un compte est actif dès sa création, l’onboarding et le paiement reviennent aussitôt sur leur adresse de retour), qui vérifie quand même la signature des événements (l’e2e signe les siens), et un seed sans compte. Ce drapeau est refusé hors des hôtes locaux et avec REAL_PAYMENTS. Le Stripe simulé ne crédite rien : un paiement revient sur sa page de succès sans événement checkout.session.completed. En local, Playwright réutilise l’API de bo dev si elle tourne : les tests qui ont besoin du Stripe simulé (payments-connect.spec.ts, le parcours « Ouvrir le paiement en ligne ») se mettent alors de côté en le disant ; arrêtez bo dev pour les lancer. bo site journeys (et bo site shots) échoue au contraire sur un tel parcours : lancez FAKE_PAYMENTS=true bo dev pour le capturer, comme le fait le workflow site. Les réponses de Stripe sont enregistrées dans packages/stripe/src/fixtures/.