Liste de contrôle avant le passage en Réel

Le mode Test et le mode Réel sont deux applications distinctes, avec leurs propres identifiants, clés, réglages et données. Rien de ce que vous configurez en mode Test n'est repris. Parcourez cette liste en mode Réel avant d'encaisser de vrais paiements.

1. Confirmez l'adresse e-mail du propriétaire de l'équipe

Une application Réelle ne fonctionne qu'une fois que le propriétaire de l'équipe a confirmé son adresse e-mail. En attendant, les requêtes en mode Réel renvoient 403 avec le code email_unverified, et les clients ne peuvent pas payer. Le mode Test fonctionne sans cela.

{
  "code": "email_unverified",
  "error": "the team owner must verify their email to use live"
}

2. Connectez un prestataire de paiement

Une application Réelle encaisse les paiements via votre propre compte pawaPay, Notch Pay ou Flutterwave. Dans le tableau de bord, ouvrez Paramètres, puis Paiements, et connectez-le.

Utilisez des identifiants de production. Si vous avez testé avec le bac à sable de votre prestataire, ces identifiants ne fonctionnent pas ici : les clés de bac à sable Notch Pay et les clés de test Flutterwave échouent avec le code provider_live_credentials_required, et pawaPay refuse un jeton de bac à sable avec provider_credentials_rejected. pawaPay ne crée un jeton qu'une fois qu'une URL de rappel est définie, alors définissez d'abord une URL temporaire, puis remplacez-la à l'étape 3.

Sans prestataire, les pages de paiement hébergées et les paiements renvoient 422 avec le code not_accepting_payments.

{
  "code": "not_accepting_payments",
  "error": "this app isn't accepting payments yet"
}

Voyez Connecter un prestataire de paiement pour les identifiants dont chaque prestataire a besoin.

3. Définissez l'URL de rappel du prestataire

Cette étape est obligatoire. Après votre connexion, la page Paiements affiche une URL de rappel du prestataire. Collez-la dans le tableau de bord de votre prestataire, pour que les paiements se mettent à jour dès que les clients les valident. Tant qu'elle n'est pas définie, les paiements peuvent ne pas se mettre à jour dans Abuna, et les factures payées peuvent rester ouvertes.

• pawaPay : ouvrez Configuration du système, puis URL de rappel, et collez-la comme URL de rappel des Dépôts, à la place de l'URL temporaire.
• Notch Pay : ouvrez Paramètres, puis Webhooks, ajoutez un point de terminaison avec l'URL, et activez les événements de paiement. Si Notch Pay affiche ensuite une autre clé de hachage pour ce point de terminaison, saisissez-la dans Abuna comme clé de hachage Webhook.
• Flutterwave : ouvrez Paramètres, puis Webhooks, collez l'URL, et saisissez le même hachage secret que celui entré dans Abuna. Cochez Activer les nouvelles tentatives de webhook et Activer le webhook pour les transactions échouées, puis enregistrez.

Faites ensuite vous-même un petit paiement en mode Réel pour confirmer la connexion : ouvrez l'un de vos liens de paiement Réels et payez depuis votre propre téléphone. La page Paiements indique En attente de la première mise à jour tant que votre prestataire n'a pas signalé ce paiement. Voyez Définir l'URL de rappel du prestataire.

4. Ajoutez un contact d'assistance

Une application Réelle n'accepte des paiements qu'une fois qu'elle a un e-mail d'assistance ou une page d'aide. Dans le tableau de bord, ouvrez Paramètres, puis Général, et remplissez Assistance client. Le mode Test et le mode Réel le partagent. Tant qu'il n'est pas défini, les pages de paiement et les liens de paiement renvoient 422 avec le code not_accepting_payments.

Tant qu'il n'y a pas de contact d'assistance, personne n'est annulé pour non-paiement, et les factures de renouvellement restent ouvertes. Une fois que vous en ajoutez un, les clients avec un renouvellement impayé obtiennent un délai de paiement complet à partir de ce moment.

5. Passez à l'ID et à la clé de votre application Réelle

Votre serveur choisit le mode selon l'ID d'application dans le chemin et la clé qu'il envoie. Changez les deux ensemble : l'ID de l'application Réelle, et une clé secrète qui commence par sk_live_.

curl https://api.abuna.app/v1/apps/8ddhXCDW/products \
  -H "Authorization: Bearer sk_live_..."

• Abuna affiche une clé secrète une seule fois, à sa création. Un propriétaire d'équipe peut en créer d'autres sous Paramètres, Clés d'API, et révoquer une clé qui fuite.
• Gardez les clés secrètes sur votre serveur. Ne les mettez jamais dans un navigateur ou une application mobile.

6. Créez vos produits et vos tarifs en mode Réel

Le mode Réel démarre vide. Créez à nouveau vos produits et vos tarifs dans l'application Réelle, et conservez leurs identifiants Réels. Les identifiants Test n'existent pas en mode Réel.

7. Configurez votre point de terminaison webhook Réel

Une application Test ne copie jamais le point de terminaison Réel, et l'application Réelle ne copie pas le vôtre depuis Test. En mode Réel, ouvrez Webhooks et définissez l'URL du point de terminaison. Elle doit être une URL https publique.

• Utilisez la clé de signature Réelle, qui commence par whsec_live_. Votre clé Test ne vérifiera pas les événements Réels.
• Vérifiez X-Abuna-Signature à chaque requête, acceptez tout v1 qui correspond, et rejetez un t décalé de plus de 300 secondes.
• Cliquez sur Envoyer un événement test et vérifiez que votre point de terminaison répond 2xx.
• Si un même serveur gère les deux modes, acheminez selon environment dans le corps signé, pas seulement selon l'en-tête X-Abuna-Environment.

Voyez Recevoir des webhooks pour la configuration complète.

8. Vérifiez vos réglages Réels

Le nom de votre application, le contact d'assistance et l'URL des conditions sont partagés par les deux modes. Ses URL de redirection, son délai de paiement et son point de terminaison webhook se règlent par mode. En mode Réel, ouvrez Paramètres, puis Général :

• Assistance client : un e-mail d'assistance ou une page d'aide, obligatoire avant qu'une application Réelle n'accepte des paiements. Il apparaît dans chaque e-mail client, et sur votre page de paiement hébergée, vos liens de paiement et votre espace client.
• URL de redirection : où la page de paiement hébergée renvoie les clients. Chacune doit être une URL https absolue. Les success_url et cancel_url que vous passez à une session de paiement doivent aussi être en https en mode Réel. Une URL localhost qui fonctionnait en mode Test renvoie 422.
• Renouvellements et délai de paiement : combien de jours, de 0 à 7, avant la fin d'une période payée la facture de renouvellement part (3 par défaut), et combien de jours, de 1 à 14, un client a pour payer un renouvellement après son début avant que l'abonnement soit annulé. Les deux s'appliquent aux factures émises après votre changement.
• Quand les clients annulent : si un client qui annule depuis l'espace client garde l'abonnement jusqu'à la fin de la période payée (par défaut) ou le perd immédiatement. Le mode Test et le mode Réel ont chacun leur propre réglage.

9. Vérifiez votre forfait

Seul le mode Réel compte dans votre forfait. Le forfait Gratuit permet 20 abonnés en mode Réel et 1 application par équipe. À la limite, les nouveaux clients ne peuvent pas s'abonner, et votre page de paiement hébergée leur dit que vous n'acceptez pas de nouveaux abonnés. Si vous en attendez plus, passez à un forfait plus grand avant de lancer.

10. Faites un vrai paiement

Abonnez-vous à votre propre produit avec un petit tarif, via une session de paiement, et payez-le avec votre propre portefeuille Mobile Money. Vérifiez que vous recevez l'e-mail de reçu, que votre point de terminaison reçoit session.completed, invoice.paid et subscription.paid, et que l'argent arrive sur votre compte prestataire. La page Paiements doit alors indiquer Mises à jour reçues.