sandbox.umeme.app, avec une clé umeme_test_…. Pas encore de clé ? Commencez par Démarrer.1. Une première vente, tout en dur
Commençons par tout coder en dur.Envoyer la vente
POST /v1/ventes avec le compteur de test 09900000000, qui réussit toujours.uuid vient de vous : générez un UUID v4 et enregistrez-le avant l’appel. Si la réponse se perd, c’est lui qui vous permet de retrouver la vente, sans jamais la vendre deux fois. Le montant est en dollars.Le même appel, dans votre langage :ACCEPTEE veut dire que la vente est prise et le portefeuille débité, pas encore qu’elle a réussi.Umeme vend auprès du fournisseur
09900000000 réussit en 3 s ; en production, une vente SOCODE prend environ 4 s.Recevoir le statut final
POST signé à votre URL de rappel. Son corps est celui de GET /v1/ventes/{uuid} :GET /v1/ventes/{uuid} donne la même réponse, à tout moment.Et voilà !
2. Demander les informations au client
Votre client choisit le compte, saisit son compteur et le montant. Voici comment construire cet écran.Afficher les comptes que vous pouvez vendre
GET /v1/configuration donne les comptes autorisés, les montants minimum et maximum, et ce qui reste de votre limite du jour. GET /v1/services dit lesquels sont ouverts en ce moment.Demander le compteur et le montant
Vérifier le compteur
GET /v1/compteurs/{reference}?compte=SOCODE&montant=5 renvoie le nom du client et le minimum du fournisseur. Affichez le nom : votre client confirme qu’il paie le bon compteur.Créer la vente
uuid neuf, enregistrez-le avec la commande, puis envoyez la vente comme à la section 1.Et voilà !
3. Éviter les rejets
Un rejet arrive à la soumission : HTTP200, statut REJETEE et un code dans motifRejet.code. Rien n’est débité. La plupart se préviennent avant l’appel.
Le compte est fermé
SERVICE_INDISPONIBLE. Relisez GET /v1/services avant d’afficher l’écran, et masquez un compte fermé.Le montant sort des limites
MONTANT_HORS_LIMITES, MONTANT_SOUS_MINIMUM. Bornez la saisie avec la configuration et le minimum du compteur.Le compteur n'est pas valable
REFERENCE_INVALIDE, COMPTEUR_INCONNU, COMPTEUR_BLOQUE. Vérifiez-le avant de vendre (section 2, étape 3).Le portefeuille ou la limite du jour ne suffit pas
SOLDE_INSUFFISANT, LIMITE_JOUR_ATTEINTE. Surveillez GET /v1/portefeuille et rechargez avant d’arriver à zéro.La même vente part deux fois
DOUBLON_IGNORE n’est pas un rejet : la vente existe déjà, ne refaites rien. Un uuid déjà utilisé pour une autre vente reçoit une erreur 409 UUID_REUTILISE : un uuid par vente.Pas de réponse, ou une erreur 5xx
GET /v1/ventes/{uuid}. Seul NON_TROUVEE prouve que la vente n’existe pas ; renvoyez-la alors, avec le même uuid.Et voilà !
4. Gérer les échecs
Une venteACCEPTEE peut échouer chez le fournisseur. Elle passe alors ECHOUEE, le portefeuille est déjà remboursé, et il reste à prévenir votre client.
uuid.5. Rester cohérent
Le réseau coupe, un serveur redémarre. Trois règles empêchent qu’une vente se perde, ou qu’elle soit vendue deux fois.Traiter chaque statut, même inattendu
Enregistrer l'uuid avant l'appel
Reprendre les ventes en attente
Et voilà !
6. Ventes en réconciliation
Quand Umeme n’a pas pu confirmer une vente auprès du fournisseur, elle passeEN_RECONCILIATION. Rien à faire : Umeme vérifie, automatiquement puis à la main, et le rappel part dès le résultat.
Pour vous entraîner : 09900000020 est retrouvée et réussit, 09900000021 passe en revue manuelle et échoue. Voir les compteurs de test.
7. Et ensuite ?
Compteurs de test
Recevoir et vérifier les rappels
Codes d'erreur
Mise en production
umeme_live_.
