Dans ce tutoriel, vous construirez MailKit, une plateforme d’emails transactionnels où les clients paient à l’avance pour un ensemble de crédits email. Le plan offre une allocation mensuelle d’emails ; lorsque les clients sont à court, ils peuvent acheter un pack de recharge au lieu d’attendre le prochain cycle. Chaque envoi déduit automatiquement un crédit.Documentation Index
Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
Use this file to discover all available pages before exploring further.
Ce tutoriel utilise Resend comme fournisseur d’email. Son niveau gratuit (3 000 emails/mois) est suffisant pour construire et tester l’ensemble du flux sans compte payant. La méthode fonctionne avec n’importe quel fournisseur ; remplacez
resend.emails.send par SendGrid, Postmark, SES, ou votre propre relais SMTP.- Créer un droit de crédit personnalisé (emails) dans votre tableau de bord
- Attacher des crédits à un plan d’abonnement et à un produit de recharge unique
- Envoyer de vrais emails via Resend et débiter un crédit par envoi via une entrée de registre
- Interroger un solde de crédits en direct depuis votre interface
- Vérifier correctement les webhooks Dodo et gérer
credit.balance_lowpour en avertir les clients avant qu’ils n’atteignent zéro
Ce que Nous Construisons
Voici le modèle de tarification pour MailKit :| Produit | Prix | Emails |
|---|---|---|
| Plan MailKit | 19 $/mois | 5 000 emails/cycle |
| Pack de Recharge | 9 $ en une fois | +5 000 emails |
Avant de commencer, assurez-vous d’avoir :
- Un compte Dodo Payments (le mode test est suffisant)
- Un compte Resend gratuit et une clé API
- Node.js 18+ et des notions de TypeScript
Étape 1 : Créer Votre Droit de Crédit Email
Le droit de crédit définit l’unité que votre plateforme vend : dans ce cas, un envoi d’email.
- Connectez-vous à votre tableau de bord Dodo Payments
- Cliquez sur Produits dans la barre latérale gauche
- Sélectionnez l’onglet Crédits
- Cliquez sur Créer un Crédit
Email Credits
Type de Crédit : Sélectionnez Unité Personnalisée
Nom de l’Unité : email
Précision : 0 (un email est toujours une unité entière ; vous ne pouvez pas envoyer un demi-email)
Expiration des Crédits : 30 days (l’allocation de chaque cycle se réinitialise)
La précision ne peut pas être modifiée après la création. Pour les unités discrètes comme les emails, messages, ou sessions, 0 est correct.
Nous n’activerons pas le report ou les dépassements dans ce tutoriel ; l’objectif est le flux CBB le plus simple possible. Vous pourrez revisiter ces paramètres plus tard lors de l’attachement des crédits.
Cliquez sur Créer un Crédit. Ouvrez le crédit et copiez son ID. Vous en aurez besoin pour les requêtes de solde backend. Il ressemble à cent_xxxxxxxxxxxx.
Votre droit Email Credits est prêt. Ensuite : les produits qui accordent des crédits aux clients.
Étape 2 : Créer le Plan et le Pack de Recharge
Vous allez créer deux produits : un plan d’Abonnement récurrent et une recharge Paiement Unique. Le plan accorde 5 000 emails à chaque cycle ; la recharge en ajoute 5 000 supplémentaires à la demande. Tous deux attachent le même droitEmail Credits.
Ce tutoriel déduit les crédits avec des entrées de registre directes au lieu de compteurs basés sur l’utilisation. Les entrées de registre sont immédiates (le solde se met à jour en millisecondes), ne nécessitent pas de configuration supplémentaire, et conviennent lorsque chaque action utilisateur équivaut exactement à un crédit. Si vous préférez la déduction automatique à partir d’événements d’utilisation ingérés (pratique pour des unités pondérées comme « jetons » ou « MB traités »), voir Facturation Basée sur les Crédits → Facturation Utilisation avec Crédits pour le modèle basé sur le compteur.
Plan MailKit (19 $/mois, 5 000 emails)
- Accédez à Produits → Créer un Produit
- Remplissez les détails du produit :
MailKit Plan
Description : 5,000 transactional emails per month.
- Sélectionnez Abonnement comme type de produit
- Définissez le prix récurrent :
19.00
Cycle de Facturation : Monthly
Devise : USD
Faites défiler jusqu’à Droits → Crédits → Attacher et configurez :
Droit de Crédit : Email Credits
Crédits émis par cycle de facturation : 5000
Seuil de Faible Solde : 20 (pourcentage ; déclenche credit.balance_low lorsque le solde passe sous 20 % de l’allocation du cycle, soit 1 000 emails)
Importer Paramètres de Crédit par Défaut : activé (utilise l’expiration de 30 jours de l’Étape 1)
Cliquez sur Ajouter au Produit, puis Enregistrer le produit. Copiez l’ID du produit (pdt_xxxxxxxxxxxx).
Plan : 19 $/mois → 5 000 emails rafraîchis chaque cycle.
Pack de Recharge (9 $ en une fois, 5 000 emails)
- Accédez à Produits → Créer un Produit
- Remplissez les détails du produit :
Email Top-Up Pack
Description : Add 5,000 emails to your MailKit balance instantly.
- Sélectionnez Paiement Unique comme type de produit
- Définissez le prix :
9.00
Devise : USD
Dans Droits → Crédits → Attacher :
- Droit de Crédit :
Email Credits - Crédits émis :
5000
Étape 3 : Configurer le Backend
Construisez maintenant le serveur Express qui gère le paiement, l’envoi, les requêtes de solde, et les webhooks.package.json :
tsx exécute directement TypeScript sans étape de compilation ou tsconfig.json, ce qui est parfait pour un tutoriel. Pour la production, ajoutez un tsconfig.json et un script build.
Créez .env :
.env
DODO_WEBHOOK_KEY à l’Étape 4 après avoir créé le point de terminaison. La clé API Resend provient de resend.com/api-keys.
Ajoutez .env à .gitignore immédiatement. Ne jamais commettre des clés API.
Créez server.ts à la racine du projet :
server.ts
express.json() analyse et re-sérialise le corps, ce qui casse la vérification de la signature. Définissez /webhooks/dodo avec express.raw() avant la ligne app.use(express.json()).
Backend prêt : abonnement, recharge, solde, envoi, et traitement des webhooks sont tous connectés.
Créez public/index.html :
public/index.html
Étape 4 : Connecter le Point de Terminaison Webhook
L’événementcredit.balance_low vous permet d’avertir les clients avant qu’ils ne soient à court. Sans cela, la première fois qu’ils remarquent le problème est lorsqu’un email échoue à envoyer.
Les webhooks nécessitent une URL publique. Utilisez ngrok (ou tout tunnel) pendant le développement :
https://1234abcd.ngrok-free.app).
- Allez à Développeurs → Webhooks → Ajouter un Point de Terminaison
- URL :
https://1234abcd.ngrok-free.app/webhooks/dodo - Événements : abonnez-vous à
credit.added,credit.balance_low, etcredit.rolled_over - Sauvegardez, puis copiez la clé de signature dans votre
.envcommeDODO_WEBHOOK_KEY - Redémarrez votre serveur
Étape 5 : Tester le Flux Complet
MailKit running on http://localhost:3000. Ouvrez-le dans votre navigateur.
- Dans la section 1, entrez un email et un nom de test, cliquez sur Obtenir le lien de paiement
- Ouvrez le lien, complétez le paiement avec une carte de test
- Après le paiement, trouvez le
customer_iddans votre tableau de bord sous Clients
- Collez le
customer_iddans la section 3 - Laissez
toréglé surdelivered@resend.dev(la boîte de réception sandbox de Resend qui accepte tout) - Cliquez sur Envoyer
- Allez à Clients → [Client] → Crédits → Crédits Email
- Cliquez sur Ajuster le Solde et débitez
4000 - Envoyez un email de plus via la démo
- Collez le
customer_iddans la section 4 - Cliquez sur Acheter 5 000 emails, complétez le paiement test
- Actualisez le solde, et il saute de 5 000
credit.added se déclenche avec grant_source: one_time. La recharge s’ajoute aux crédits d’abonnement ; les deux pools sont consommés en FIFO (le plus ancien crédit non expiré en premier).
Débitez le solde manuellement à zéro, puis essayez d’envoyer un email de plus. Vous obtiendrez :
Résolution des Problèmes
La signature est calculée sur le corps brut de la requête HTTP.express.json() analyse et ré-sérialise la charge, ce qui casse le HMAC. Assurez-vous que /webhooks/dodo est enregistré avec express.raw({ type: 'application/json' }) au-dessus de la ligne app.use(express.json()), et que DODO_WEBHOOK_KEY correspond à la clé de signature affichée sur la page de détail du point de terminaison.
Trois choses à vérifier, dans cet ordre :
- Le client a complété le paiement (les crédits sont émis après un paiement réussi, pas à la création de la session)
CREDIT_ENTITLEMENT_IDdans votre.envcorrespond au crédit attaché au produit (les ID non conformes écrivent silencieusement sur le mauvais crédit)- Le
customer_idque vous fournissez provient de Dodo (la tablecustomersdans le tableau de bord), pas de votre propre base de données
onboarding@resend.dev délivre uniquement à l’email sur votre compte Resend ou à delivered@resend.dev. Pour envoyer à quelqu’un d’autre, vérifiez un domaine et utilisez une adresse from dessus.
Ce que Vous Avez Construit
Email Credits, défini une fois et attaché à la fois au plan d’abonnement et au pack de recharge.
19 $/mois accordent 5 000 emails par cycle. Les clients savent pour quoi ils paient, vous connaissez votre coût maximal.
Un produit unique qui accorde 5 000 emails. Il s’ajoute aux crédits d’abonnement sans changement de plan requis.
Un seul appel createLedgerEntry après chaque envoi. Pas de compteur, pas de latence d’agrégation, idempotent en cas de nouvelle tentative via l’identifiant de message Resend.
Lisez la documentation complète CBB pour les modes de report, dépassement, gestion du registre, et l’intégralité de l’API.
Besoin d’aide ?
One reusable credit unit
Email Credits, defined once and attached to both the subscription plan and the top-up pack.Subscription with prepaid allowance
$19/month grants 5,000 emails per cycle. Customers know what they’re paying for, you know your worst-case cost.
Top-up pack
A one-time product that grants 5,000 emails. Stacks on subscription credits with no plan change required.
Instant ledger debits
A single
createLedgerEntry call after each send. No meter, no aggregation lag, idempotent on retry via Resend’s message id.Credit-Based Billing Reference
Read the full CBB documentation for rollover, overage modes, ledger management, and the complete API surface.