Skip to content

Checklist — Tests Stripe (DEV/TEST) — Yinshi

Objectif : exécuter une batterie de tests reproductibles (mode test Stripe) pour valider :

  • le checkout et la création d'abonnement
  • les scénarios d'échec de paiement (carte refusée, 3DS, fonds insuffisants, etc.)
  • les renouvellements / impayés / annulations
  • l'expiration et la perte d'accès premium
  • la cohérence des écritures Firestore (extension Stripe + Cloud Functions du repo)

Projet Firebase DEV/TEST : yin-shi-dev
PWA de test : https://yinshi-test.yinshi.app/
Stripe : mode Test

Pré-requis (avant de tester)

  • [x] PWA pointe bien sur DEV/TEST

  • Validation : dans les logs init Firebase (ou via projectId) on doit voir yin-shi-dev.

  • [x] Extension Stripe installée sur DEV/TEST (invertase/firestore-stripe-payments)

  • Validation : dans la console Firebase yin-shi-dev → Functions, voir des fonctions ext-firestore-stripe-payments-*.

  • [x] Cloud Functions "métier" du repo déployées sur DEV/TEST

  • Validation : dans la console Firebase yin-shi-dev → Functions, voir :

    • syncStripeToAppUser
    • syncStripeToAppUserOnCreate

  • [x] Cache PWA neutralisé (éviter les faux négatifs)

  • Validation : hard refresh + purge cache/service worker si nécessaire.

Où regarder (observabilité)

Côté Firestore (DEV/TEST)

  • [ ] customers/{uid}/checkout_sessions/{sessionId}

  • Indicateurs utiles : présence du champ url, statut mis à jour après paiement.

  • [ ] customers/{uid}/subscriptions/{subscriptionId}

  • Indicateurs utiles : status, current_period_end, cancel_at_period_end, etc.

  • [ ] app_users/{uid}

  • Indicateurs utiles :
    • app_user_role (attendu : Paid après abonnement actif)
    • app_user_currentPeriodEnd
    • app_user_updatedAt

Côté Cloud Functions (DEV/TEST)

  • [ ] Logs Functions (console Firebase → Functions → Logs)
  • Chercher : updated to role (mise à jour du rôle utilisateur).

Côté Stripe Dashboard (mode test)

  • [ ] Customer
  • [ ] Payments
  • [ ] Subscriptions
  • [ ] Events (utile pour diagnostiquer un scénario)

Rappels : comment utiliser Stripe Dashboard (mode test)

Passer en mode test

  • [ ] Dans Stripe Dashboard, activer le toggle Test mode.

Retrouver un utilisateur / un paiement

  • [ ] Customers : chercher par email (si disponible), sinon filtrer par date.
  • [ ] Payments : filtrer par date, cliquer sur le paiement pour voir les détails.
  • [ ] Subscriptions : vérifier le statut, les dates de période et l'historique.

Simuler des scénarios (moyens)

  • [ ] Via cartes de test : utiliser des numéros de carte Stripe test adaptés au scénario.
  • [ ] Via action sur subscription : annuler / reprendre / modifier (selon écrans disponibles).
  • [ ] Via events : consulter les événements générés (utile pour confirmer ce que Stripe a émis).

Note : les cartes test exactes peuvent évoluer ; se référer à la documentation officielle Stripe "Test cards" si besoin.

A) Tests Checkout & création d'abonnement

A1 — Checkout réussi (référence)

  • [ ] Préparation : créer un utilisateur neuf (ou supprimer l'ancien utilisateur DEV/TEST).
  • [ ] Dans la PWA : déclencher un checkout.
  • [ ] Payer avec une carte test "succès".

Vérifications Firestore

  • [ ] customers/{uid}/checkout_sessions/{id} existe et est mis à jour.
  • [ ] customers/{uid}/subscriptions/{id}.status == "active".
  • [ ] app_users/{uid}.app_user_role == "Paid".

Vérifications logs

  • [ ] Logs Functions : une entrée montrant la mise à jour du rôle.

A2 — Retour success_url / cancel_url

  • [ ] Vérifier que le retour Stripe redirige vers https://yinshi-test.yinshi.app/.
  • [ ] Vérifier que l'utilisateur reste connecté et que la PWA se met à jour (pas de cache).

B) Tests Échecs de paiement (carte refusée / auth)

B1 — Carte refusée (paiement échoue)

  • [ ] Dans la PWA : lancer le checkout.
  • [ ] Utiliser une carte test "declined".

Attendu

  • [ ] La PWA affiche une erreur claire ou un état d'échec.
  • [ ] Firestore : la subscription peut être absente ou status non actif (selon Stripe/extension).
  • [ ] app_users/{uid}.app_user_role ne doit pas devenir Paid.

B2 — Fonds insuffisants

  • [ ] Checkout → carte test "insufficient_funds".

Attendu

  • [ ] Pas de passage à Paid.
  • [ ] Stripe Dashboard → Payment doit être en échec.

B3 — 3D Secure requis (authentication)

  • [ ] Checkout → carte test nécessitant 3DS.
  • [ ] Terminer le challenge.

Attendu

  • [ ] Si le challenge est validé : mêmes validations que A1.

B4 — 3DS échoué / abandonné

  • [ ] Checkout → carte test 3DS.
  • [ ] Échouer ou abandonner le challenge.

Attendu

  • [ ] Pas de passage à Paid.

C) Tests cycle de vie de l'abonnement

C1 — Annulation en fin de période (cancel_at_period_end)

  • [ ] Provoquer une annulation (via PWA si écran disponible, sinon via Stripe Dashboard → Subscription → Cancel).

Vérifications

  • [ ] customers/{uid}/subscriptions/{id} reflète l'annulation planifiée.
  • [ ] Tant que la période n'est pas terminée : l'utilisateur peut rester Paid.

C2 — Annulation immédiate

  • [ ] Dans Stripe Dashboard : annuler immédiatement.

Vérifications

  • [ ] L'abonnement passe à un statut non actif.
  • [ ] Après propagation : app_users/{uid}.app_user_role doit finir en Expired (ou non Paid) selon la logique métier.

C3 — Renouvellement (cycle normal)

  • [ ] (Si possible) attendre/forcer un renouvellement test.

Vérifications

  • [ ] Stripe : facture payée.
  • [ ] Firestore : current_period_end mis à jour.
  • [ ] app_users/{uid} reste Paid.

D) Tests impayés (dunning) / paiement en retard

D1 — Renouvellement échoué puis récupéré

  • [ ] Simuler un échec au renouvellement (carte qui échoue), puis corriger le moyen de paiement.

Vérifications

  • [ ] Stripe : invoice en échec puis payée.
  • [ ] Firestore : subscriptions reflète l'état.
  • [ ] app_users/{uid}.app_user_role : vérifier si un downgrade temporaire est attendu ou non.

D2 — Impayé persistant (unpaid)

  • [ ] Laisser l'échec persister.

Vérifications

  • [ ] Stripe : subscription devient unpaid/past_due selon config.
  • [ ] Firestore : status reflète cet état.
  • [ ] app_users/{uid}.app_user_role : vérifier la transition attendue (souvent Expired après fin de période).

E) Tests d'expiration / perte d'accès premium

E1 — Expiration après fin de période

  • [ ] Provoquer un current_period_end dans le passé (via attente ou scénario Stripe approprié).

Vérifications

  • [ ] app_users/{uid}.app_user_role devient Expired.
  • [ ] La PWA bloque les features premium si elles sont réservées.

Note : si un cron/planificateur est requis pour mettre à jour des expirations, vérifier la présence de la fonction planifiée et son exécution.

F) Tests portail client (Customer Portal)

F1 — Accès portail

  • [ ] Depuis la PWA, ouvrir le portail (si écran disponible).

Vérifications

  • [ ] Stripe ouvre le portail.
  • [ ] On peut voir l'abonnement.

F2 — Changement moyen de paiement

  • [ ] Dans le portail : changer la carte.

Vérifications

  • [ ] Stripe enregistre la carte.
  • [ ] Les paiements suivants utilisent le nouveau moyen.

G) Tests remboursements / litiges (si applicable au scope)

G1 — Remboursement (refund)

  • [ ] Dans Stripe Dashboard : Payment → Refund.

Vérifications

  • [ ] Stripe : refund visible.
  • [ ] Définir l'impact métier attendu sur le rôle (souvent : pas d'impact immédiat si période en cours, ou annulation selon politique).

H) Tests robustesse (régression / anti-faux négatifs)

H1 — Re-test après purge cache PWA

  • [ ] Purger cache / désinscrire SW, recharger.
  • [ ] Vérifier que les écritures Firestore et le rôle sont cohérents.

H2 — Re-test sur navigateur privé / autre navigateur

  • [ ] Tester le même scénario sur un navigateur vierge.

Critères d'acceptation (DoD)

  • [ ] Les scénarios A (succès), B (échecs) et C/D/E (lifecycle) ont un résultat cohérent.
  • [ ] Chaque test a une trace vérifiable (Stripe Dashboard + Firestore + logs Functions).
  • [ ] Le passage Paid est confirmé après checkout réussi.
  • [ ] La perte d'accès (annulation/expiration) est cohérente avec la logique métier.

Notes / résultats (à remplir)

  • Date :
  • Version PWA test :
  • UID(s) testés :
  • Observations :
  • Anomalies :