Passer au contenu principal
Tout se joue dans la sandbox, sur 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.
1

Envoyer la vente

Envoyez POST /v1/ventes avec le compteur de test 09900000000, qui réussit toujours.
POST https://sandbox.umeme.app/v1/ventes
L’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 :
La réponse arrive tout de suite :
200 OK
ACCEPTEE veut dire que la vente est prise et le portefeuille débité, pas encore qu’elle a réussi.
2

Umeme vend auprès du fournisseur

Rien à faire pendant ce temps. Dans la sandbox, le compteur 09900000000 réussit en 3 s ; en production, une vente SOCODE prend environ 4 s.
3

Recevoir le statut final

Umeme envoie un POST signé à votre URL de rappel. Son corps est celui de GET /v1/ventes/{uuid} :
POST https://votre-serveur.example/rappels/umeme
Remettez le jeton à votre client, avec son reçu. Avant de croire un rappel, vérifiez sa signature : c’est l’objet du guide Recevoir et vérifier les rappels.Pas de rappel ? GET /v1/ventes/{uuid} donne la même réponse, à tout moment.

Et voilà !

Vous avez vendu de l’électricité SOCODE et reçu le jeton. Rendons maintenant la vente dynamique.

2. Demander les informations au client

Votre client choisit le compte, saisit son compteur et le montant. Voici comment construire cet écran.
1

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.
GET /v1/configuration
2

Demander le compteur et le montant

Un écran simple suffit :Montants en dollars, deux décimales au plus. Ne présélectionnez aucun compte : c’est votre client qui sait ce qu’il paie.
3

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.
GET /v1/compteurs/09900000000?compte=SOCODE&montant=5
4

Créer la vente

Générez un uuid neuf, enregistrez-le avec la commande, puis envoyez la vente comme à la section 1.

Et voilà !

Votre écran de vente est dynamique. Voyons comment éviter qu’une vente soit rejetée.

3. Éviter les rejets

Un rejet arrive à la soumission : HTTP 200, statut REJETEE et un code dans motifRejet.code. Rien n’est débité. La plupart se préviennent avant l’appel.
1

Le compte est fermé

SERVICE_INDISPONIBLE. Relisez GET /v1/services avant d’afficher l’écran, et masquez un compte fermé.
2

Le montant sort des limites

MONTANT_HORS_LIMITES, MONTANT_SOUS_MINIMUM. Bornez la saisie avec la configuration et le minimum du compteur.
3

Le compteur n'est pas valable

REFERENCE_INVALIDE, COMPTEUR_INCONNU, COMPTEUR_BLOQUE. Vérifiez-le avant de vendre (section 2, étape 3).
4

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.
5

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.
6

Pas de réponse, ou une erreur 5xx

Ne concluez pas : consultez GET /v1/ventes/{uuid}. Seul NON_TROUVEE prouve que la vente n’existe pas ; renvoyez-la alors, avec le même uuid.

Et voilà !

Vos ventes ne sont plus rejetées pour des raisons évitables. Passons aux échecs.
motifRejet.message est écrit pour vos équipes et peut changer. Montrez à votre client un message tiré du code.

4. Gérer les échecs

Une vente ACCEPTEE peut échouer chez le fournisseur. Elle passe alors ECHOUEE, le portefeuille est déjà remboursé, et il reste à prévenir votre client.
Un échec est définitif. Une nouvelle tentative est une nouvelle vente, avec un nouvel 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.
1

Traiter chaque statut, même inattendu

2

Enregistrer l'uuid avant l'appel

3

Reprendre les ventes en attente

Et voilà !

Aucune vente ne se perd, aucune n’est vendue deux fois.

6. Ventes en réconciliation

Quand Umeme n’a pas pu confirmer une vente auprès du fournisseur, elle passe EN_RECONCILIATION. Rien à faire : Umeme vérifie, automatiquement puis à la main, et le rappel part dès le résultat.
Ne relancez pas la vente : ce serait la vendre deux fois. Prévenez votre client que le résultat arrive ; cela peut prendre plusieurs heures.
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

Jouer chaque issue : échec, réconciliation, revue manuelle.

Recevoir et vérifier les rappels

La signature par clé publique, étape par étape.

Codes d'erreur

Tous les codes de rejet et d’échec, et leur sens.

Mise en production

La liste de contrôle avant de passer aux clés umeme_live_.