Stripe
AirtableTABLEAU DE SUIVI
Prérequis
- Base Airtable avec droits API (token personnel ou OAuth Make)
- Webhooks Stripe configurés vers Make ou API Next.js relais
- Convention de statuts paiement alignée avec le CMS commandes
- Champs client (e-mail, société) déjà modélisés en table liée
Le Dashboard Stripe est puissant pour les devs, mais opaque pour un PO qui doit croiser commandes site, statuts de paiement et relances client. Un flux webhook → Airtable crée un registre partagé : montant, statut, client, lien Stripe. Vous allez configurer Make pour alimenter des vues Kanban et filtres exploitables par le support.
Modéliser la base Airtable paiements
Table « Paiements » : `payment_intent_id` (unique), montant, devise, statut (select : succeeded, processing, failed, refunded), horodatage, mode test/live.
Liez une table « Commandes » via `order_id` ou « Clients » via e-mail / `stripe_customer_id`. Le PO filtre par statut failed pour les relances.
Ajoutez une formule « Lien Stripe » : `https://dashboard.stripe.com/payments/` & `{payment_intent_id}` pour accès rapide au détail.
Scénario Make webhook → Airtable
Make reçoit le payload (directement ou via votre API) après validation signature. Router sur `payment_intent.succeeded`, `payment_intent.payment_failed`, `charge.refunded`.
Module Search Records sur `payment_intent_id`. Branche trouvé → Update statut et date. Branche absent → Create avec métadonnées `order_id` du webhook Checkout.
Error handler vers Slack avec extrait JSON. Reprise via resend Stripe ou rejeu Make depuis incomplete executions.
Vues PO et reporting hebdo
Vue « Échecs 7 jours » : filtre statut failed, tri date desc — stand-up support client.
Vue « Test vs Live » : groupe par mode pour éviter de mélanger recette et production dans les KPI.
Interface Airtable lecture seule pour le client final : montants et statuts sans accès aux tokens API.
Croisez avec la fiche reporting Make si vous agrégez aussi les leads ou le CA hebdo.
Erreurs fréquentes
Create systématique sans Search : doublons à chaque retry webhook.
Montants en euros flottants au lieu de centimes entiers : totaux Airtable faux.
Oublier la colonne mode test : KPI production gonflés par la recette.
Token Airtable avec droits écriture exposé côté client.
Pas de lien vers commande CMS : le support ne retrouve pas le contexte livraison.
Ce qu’il faut retenir
Airtable = registre opérationnel partagé PO / support / dev.
Clé unique `payment_intent_id`, upsert Make, pas de données carte.
Vues échecs et séparation test/live pour le pilotage quotidien.
Complète le Dashboard Stripe, ne le remplace pas pour le debug technique.
FAQ
Next.js valide la signature puis appelle l’API Airtable : moins de latence, un seul hop. Make convient si le PO maintient déjà les scénarios sans deploy dev à chaque changement de champ.
Non au lancement. Importez un backfill ponctuel via Stripe API si le client exige l’historique ; ensuite seuls les webhooks alimentent la base.
Exportez les Invoices Stripe pour la compta ; Airtable sert au suivi opérationnel commande-paiement. Ne dupliquez pas la liasse fiscale dans Airtable.
