Aller au contenu
ENFR
Obtenir des clés de test

Factures

Une facture demande à un payeur un montant pour une date d’échéance. Futa lui fait un seul lien de paiement à usage unique à la fois, pour tout le montant, et l’envoie au payeur par SMS, par WhatsApp, par les deux ou par aucun, puis le relance comme le dit la politique de relance du lot. Les factures vont par lots : une clé crée un lot, envoie ses factures par tranches, lit ce que chaque tranche a rejeté, puis envoie le lot. Dans le bac à sable, tous les canaux et tous les participants sont synthétiques : aucun message n’atteint un téléphone et aucune facture ne déplace d’argent réel.

Les portées

Section intitulée « Les portées »

Deux portées de clé ouvrent les routes de facture /v1 : invoices:write crée, remplit, envoie et annule les lots et lance les relances du bac à sable, et invoices:read lit les lots et les factures. Seul un Propriétaire ou un Admin donne à une clé l’une d’elles ; la clé d’amorçage du bac à sable et les clés émises par l’équipe de Futa n’en ont aucune.

Ce qu’est une facture

Section intitulée « Ce qu’est une facture »
  • Un montant, une devise, une échéance. Le montant est en unités mineures entières de sa devise, USD ou CDF, comme tout montant de /v1 : des cents pour l’USD et, pour le CDF, un multiple de 100, des francs entiers. 35000000 vaut 350 000 francs et 1500 vaut 15,00 dollars. Un montant décimal est refusé.
  • Un seul lien payable à la fois. Chaque facture se paie par un lien fixe, à usage unique, pour tout son montant, et au plus un de ses liens est payable à la fois. Une relance après l’échéance porte un nouveau lien qui remplace le premier. links les liste dans l’ordre, le premier et chaque remplaçant, et payable_link_id désigne celui qui est payable, null quand aucun ne l’est. Le lien d’une facture n’est pas l’un de vos liens de paiement : /v1/payment-links y répond 404.
  • Payée seulement quand Futa le dit. Une facture est PAID dès que l’un de ses liens a été payé, comme le switch le répond : GET /v1/invoices/{id} lit son paiement en direct à chaque appel. Tant qu’une tentative est en attente ou incertaine, elle est VERIFYING (« En vérification »), ni payée ni échouée. Ne marquez jamais une facture payée, ni échouée, avant que la réponse de Futa le dise : aucun compte n’est déduit et aucun état n’est optimiste.
  • Pas de webhook à elle. Le paiement de chaque facture payée émet payment.approved, comme tout paiement.

Envoyer un lot par l’API

Section intitulée « Envoyer un lot par l’API »

  1. Le créer. POST /v1/invoice-batches avec invoices:write et une Idempotency-Key indique le libellé du lot, ses canaux (SMS, WHATSAPP, les deux, ou aucun : une liste vide fait les liens et n’envoie aucun message), sa politique de relance et combien de factures arriveront, au plus 50 000. Il répond 201 avec le lot, RECEIVING, et sa référence BI-…. Rien n’est envoyé et aucun lien n’existe avant l’envoi du lot. GET /v1/invoice-batches/{id} lit un lot, et GET /v1/invoice-batches les liste du plus récent au plus ancien, 100 par page.

    {
      "label": "Frais du 1er trimestre",
      "channels": ["SMS", "WHATSAPP"],
      "reminders": "BEFORE_AND_ON_DUE_DATE",
      "expected_invoices": 2
    }

  2. Envoyer ses factures par tranches. POST /v1/invoice-batches/{id}/invoices prend au plus 1 000 factures et 512 Kio par appel. Chaque facture a sa ligne line dans le lot, de 1 au nombre annoncé, chacune une fois ; une référence reference à vous, que la page du payeur affiche, et qui ne doit donc contenir aucune donnée du payeur ; son montant et sa devise ; son échéance due_date, un jour du calendrier de Kinshasa ; et, au choix, le nom name et le téléphone phone (E.164) du payeur, une description description et une customer_reference qui reste chez vous et n’est jamais envoyée au payeur. Sans description, le lien et chaque message disent « Facture » et la référence. Une facture mal formée refuse toute la tranche, 400 INVALID_REQUEST.

    {
      "chunk": 1,
      "invoices": [
        {
          "line": 1,
          "reference": "ELV-2026-0417",
          "name": "Famille Tshibanda",
          "phone": "+243810000001",
          "amount": 35000000,
          "currency": "CDF",
          "due_date": "2026-11-30",
          "description": "Frais 1er trimestre"
        },
        {
          "line": 2,
          "reference": "ELV-2026-0418",
          "name": null,
          "phone": "+243810000002",
          "amount": 1500,
          "currency": "USD",
          "due_date": "2026-11-30",
          "description": null
        }
      ]
    }

  3. Lire ce que chaque tranche a rejeté. La tranche répond par son reçu : ses lignes, celles qui sont prêtes, celles qui sont rejetées et chaque problème des rejetées, au plus quatre par ligne. Une référence qu’une ligne antérieure du lot ou une autre de vos factures détient déjà, casse ignorée, est INVOICE_REFERENCE_DUPLICATE ; une échéance hors de la plage du lendemain à 90 jours à Kinshasa, SYNTHETIC, est INVOICE_DUE_DATE_OUT_OF_RANGE ; un montant au-dessus de votre plafond par paiement en vigueur à l’arrivée de la tranche est MERCHANT_LIMIT_EXCEEDED ; et l’absence de téléphone alors que le lot a un canal est PHONE_MISSING. Un problème ne répète jamais un nom, un téléphone, une référence ni une description. Une facture rejetée n’est pas envoyée. Une fois toutes les factures annoncées arrivées, le lot est READY.

    {
      "batch_id": "00000000-0000-4000-8000-000000000101",
      "chunk": 1,
      "lines": 2,
      "ready": 1,
      "rejected": 1,
      "problems": [
        {
          "line": 2,
          "column": null,
          "field": "reference",
          "code": "INVOICE_REFERENCE_DUPLICATE",
          "value": null
        }
      ]
    }

  4. L’envoyer. POST /v1/invoice-batches/{id}/send à la version du lot l’envoie, ses messages dans la langue que le corps indique, fr s’il n’en indique aucune (ln, sw et en sont les autres). Il répond 202 aussitôt, avec le lot SENDING, puis fait le lien et le premier message de chaque facture prête. Chaque facture est jugée une fois de plus, le jour de l’envoi à Kinshasa : celle dont l’échéance est sortie de la plage, dont le montant dépasse le plafond en vigueur ou dont une autre facture ouverte a pris la référence depuis est REFUSED, son refusal disant pourquoi. Le lot est SENT une fois chaque facture créée ou refusée et chaque premier message arrivé à une issue.

    {
      "expected_version": 3,
      "language": "fr"
    }

  5. Lire ses factures. GET /v1/invoice-batches/{id}/invoices liste les factures d’un lot dans l’ordre des lignes, 100 par page, au choix d’un seul état state, du groupe NOT_PAID (UNPAID, VERIFYING et EXPIRED) ou du groupe UNDELIVERED, ou trouvées par q, le début d’une référence ou un téléphone écrit en entier, jamais un nom. Une liste montre la dernière lecture de chaque paiement ; une page d’un état peut contenir moins de factures qu’elle n’en a lu, ou aucune, et porter quand même un next_cursor : suivez-le jusqu’à ce qu’il soit null. GET /v1/invoices/{id} lit une facture, son paiement en direct, son téléphone masqué à ses quatre derniers chiffres.

    {
      "id": "00000000-0000-4000-8000-000000000201",
      "batch_id": "00000000-0000-4000-8000-000000000101",
      "line": 1,
      "position": 1,
      "reference": "ELV-2026-0417",
      "customer_reference": null,
      "name": "Famille Tshibanda",
      "phone": "+243•••••0001",
      "amount": 35000000,
      "currency": "CDF",
      "due_date": "2026-11-30",
      "description": "Frais 1er trimestre",
      "state": "PAID",
      "refusal": null,
      "links": [
        {
          "id": "00000000-0000-4000-8000-000000000301",
          "code": "LK-7Q2M-K9TX",
          "sequence": 1,
          "status": "PAID",
          "created_at": "2026-11-04T09:00:00.104512Z",
          "expires_at": "2026-11-30T23:00:00Z",
          "cancelled_at": null,
          "paid_attempt": {
            "payment_id": "00000000-0000-4000-8000-000000000401",
            "reference": "FT-0000000000000000000000000000000A",
            "participant": "simulator",
            "approved_at": "2026-11-05T10:31:07.250031Z"
          }
        }
      ],
      "payable_link_id": null,
      "paid_at": "2026-11-05T10:31:07.250031Z",
      "delivery": {
        "state": "DELIVERED",
        "reason": null,
        "messages": [
          {
            "channel": "SMS",
            "kind": "REQUEST",
            "occurrence": 1,
            "state": "DELIVERED",
            "reason": null,
            "expiry_date": "2026-11-30",
            "sent_at": "2026-11-04T09:00:02.5Z",
            "updated_at": "2026-11-04T09:00:05Z"
          }
        ]
      },
      "created_at": "2026-11-04T09:00:00.104512Z",
      "updated_at": "2026-11-05T10:31:08Z"
    }

  6. Ou l’annuler. POST /v1/invoice-batches/{id}/discard à la version du lot annule un lot pas encore envoyé (« Annuler ») : il est DISCARDED, libère ses références et ne compte plus parmi vos lots ouverts. Rien n’en a jamais été envoyé, si bien que rien n’est annulé ailleurs.

    {
      "expected_version": 3
    }

Un lot donne ses comptes par état et ses totaux par devise, l’USD puis le CDF, chaque devise une fois, jamais additionnés ni convertis. Un total peut dépasser 2^53 : lisez-le comme un entier de 64 bits, jamais comme un nombre à virgule flottante. Le client TypeScript lit un montant exactement jusqu’à 2^53 − 1 unités mineures ; au-delà, il refuse la réponse plutôt que de l’arrondir, et refuse d’envoyer un tel montant. Pour lire exactement une telle réponse, appelez la méthode Raw de l’opération, getInvoiceBatchRaw par exemple, et lisez response.raw.text() avec un lecteur qui garde les entiers de 64 bits. Pour un envoi ou une annulation, le serveur a déjà fait l’écriture quand le client refuse sa réponse : lisez cette réponse brute, en renvoyant la même requête sous la même clé avec sendInvoiceBatchRaw ou discardInvoiceBatchRaw, qui la rejoue, ou relisez le lot avec getInvoiceBatchRaw, puis response.raw.text() ; ne renvoyez jamais l’écriture sous une nouvelle clé.

Les états d’un lot

Section intitulée « Les états d’un lot »
État Sens
RECEIVING Créé par l’API : ses factures arrivent.
MAPPING, VALIDATING Créé à partir d’un fichier dans le portail marchand : ses colonnes sont associées, puis ses lignes vérifiées.
READY Toutes ses factures sont arrivées ; il peut être envoyé ou annulé.
SENDING Ses liens et ses premiers messages sont en cours. Au-delà de 20 de vos lots en cours d’envoi à la fois, SYNTHETIC, un lot attend ici, dans l’ordre.
SENT Chaque facture est créée ou refusée et chaque premier message est arrivé à une issue.
SEND_FAILED Définitif. Le switch a refusé la requête de l’envoi, et l’envoi s’est arrêté : send_failure donne INVOICE_BATCH_SEND_FAILED, un correlation_id à citer au support et failed_at. Ses liens sont fermés et il n’est jamais relancé ; une fois ses liens fermés, chaque facture se lit PAID ou VERIFYING selon son paiement, CANCELLED sinon.
LAPSED Pas envoyé sept jours après sa dernière modification, SYNTHETIC. Rien n’en a jamais été envoyé.
DISCARDED Annulé avant d’être envoyé.

Les états d’une facture

Section intitulée « Les états d’une facture »

Chaque facture a un état de paiement, state (« Statut »), et à part un état d’envoi, delivery.state (« Envoi »). Un échec d’envoi ne fait jamais échouer une facture : elle reste UNPAID.

État Sens
READY Prête, son lot pas encore envoyé.
REFUSED Pas créée à l’envoi : refusal vaut INVOICE_DUE_DATE_OUT_OF_RANGE, INVOICE_REFERENCE_DUPLICATE ou MERCHANT_LIMIT_EXCEEDED.
UNPAID Créée, son lien payable attend le payeur.
VERIFYING Son lien le plus récent a une tentative en attente ou incertaine : ni payée ni échouée.
PAID L’un de ses liens a été payé ; paid_at dit quand.
EXPIRED « Expirée » : sa fenêtre après l’échéance s’est terminée sans paiement, ou, sans relances, son lien s’est terminé sans paiement après l’échéance. Elle n’est plus relancée et libère sa référence.
CANCELLED Son lot a fini SEND_FAILED et aucun de ses liens n’a été payé ni n’est en vérification : aucun ne peut plus être payé.

EXPIRED signifie que le temps de payer est passé, pas qu’un paiement a échoué. Un premier lien se termine à la fin de l’échéance J, ou 720 heures après sa création si cela vient avant ; sous une politique de relance, le lien de la relance après l’échéance se termine à J+8 à 09:00, heure de Kinshasa. Une facture payée ou expirée libère sa référence pour une nouvelle facture.

Envoi Sens
NONE Aucun message demandé : pas de canal, ou le lot n’est pas encore envoyé.
PENDING Un message n’a pas encore d’issue : HELD, ACCEPTED ou SENT.
DELIVERED Un message a atteint le payeur.
UNCONFIRMED Un message a été envoyé et aucun accusé de réception n’est venu.
UNDELIVERED Un message n’a atteint personne (INVALID_NUMBER, UNREACHABLE) ou n’a jamais été envoyé avant la fin de sa plage (SEND_WINDOW_CLOSED).
NOT_SENT Aucun message n’est parti : les canaux l’ont refusé, le nouveau lien d’une relance dépassait votre plafond par paiement (MERCHANT_LIMIT_EXCEEDED), ou sa facture ne pouvait plus être relancée quand il était dû (NOT_REMINDABLE).

Les relances

Section intitulée « Les relances »

La politique reminders d’un lot les choisit, et il lui faut un canal : une politique autre que NONE sur un lot sans canal est 400 INVALID_REQUEST.

Politique Relances
BEFORE_AND_ON_DUE_DATE « J−3 et jour d’échéance » : à 09:00, heure de Kinshasa, trois jours avant l’échéance et le jour même.
WEEKLY « Chaque semaine » : à 09:00, heure de Kinshasa, tous les sept jours du premier message jusqu’à l’échéance.
NONE « Aucune » : pas de relance.

Sous l’une des deux premières, une relance de plus part à J+1 à 09:00 avec un nouveau lien qui se termine à J+8 à 09:00, SYNTHETIC. Une relance manquée, par un passage en retard ou une journée retenue, n’envoie que la dernière due, jamais deux.

  • La plage d’envoi. Futa appelle les canaux de 08:00 à 19:55, heure de Kinshasa, et chaque message porte 20:00 ce jour-là comme son dernier moment. Un message dû hors de la plage attend HELD avec SEND_WINDOW et part à l’ouverture suivante.
  • Le plafond journalier. Au plus 100 000 messages par marchand et par jour à Kinshasa, SYNTHETIC : les autres attendent HELD avec DAILY_CAP l’ouverture du lendemain, jamais refusés.
  • Les liens avant les messages. Avant qu’une relance ou un message retenu parte, le paiement de sa facture est relu et son lien remplacé si sa plage en demande un nouveau, si bien qu’un message porte toujours un lien qui dure jusqu’au jour qu’il nomme, expiry_date. Un message retenu dont la facture est d’ici là payée, en vérification, expirée ou annulée ne part jamais : il finit NOT_SENT avec NOT_REMINDABLE.

Dans le portail marchand, « Relancer les non payées » relance aussitôt les factures non payées d’un lot et « Renvoyer » renvoie une facture ; l’API n’a ni l’un ni l’autre.

Le lancement des relances du bac à sable

Section intitulée « Le lancement des relances du bac à sable »

Le bac à sable lance le calendrier des relances à la demande, si bien qu’un test n’attend pas. POST /v1/sandbox/invoice-reminders/run, avec une clé de test qui a invoices:write et une Idempotency-Key, le lance aussitôt en se plaçant à l’instant as_of, pour vos seuls lots. Seul le bac à sable la sert.

  • as_of est un instant de maintenant à 100 jours plus tard, SYNTHETIC ; en dehors, 400 INVALID_REQUEST.
  • Chaque facture ne reçoit que sa dernière relance due à as_of ou avant qui n’a pas encore eu lieu, enregistrée sous sa propre clé, si bien qu’un nouveau lancement n’enregistre rien deux fois.
  • La plage et le plafond sont jugés à as_of : un message hors de 08:00 à 19:55, heure de Kinshasa, ou au-delà du plafond, est enregistré HELD, et un lancement suivant dont l’as_of tombe dans la plage l’envoie. Un lancement dont l’as_of est 19:50 ou plus tard retient ainsi tous ses messages.
  • not_after. Un message qu’un lancement envoie porte 20:00, heure de Kinshasa, le jour d’as_of comme son dernier moment.
  • Les liens se terminent comme le dit la facture, jamais comme le dit as_of : un lien dure au plus 720 heures depuis sa création, si bien qu’un lancement loin en avant peut obtenir un lien qui se termine avant son calendrier.

Il répond par ce qu’il a enregistré, marqué synthétique : les lots qu’il a examinés, les relances qu’il a enregistrées et les factures qu’il a trouvées EXPIRED.

{
  "as_of": "2026-11-27T08:00:00Z"
}
{
  "as_of": "2026-11-27T08:00:00Z",
  "synthetic": true,
  "batches": 1,
  "reminders": 2,
  "expired": 0
}

L’idempotence

Section intitulée « L’idempotence »

Chaque écriture de facture prend une Idempotency-Key de 8 à 128 lettres sans accent, chiffres, _ et -, propre au marchand et à la clé qui l’envoie :

  • La création d’un lot et un lancement des relances. La même clé avec le même corps répond par ce qu’elle a créé, quoi qu’il se soit passé depuis ; un autre corps répond 409 IDEMPOTENCY_CONFLICT.
  • Un envoi et une annulation couvrent chacun un lot à la version envoyée : un renvoi exact rejoue la première réponse, et la clé utilisée pour un autre lot ou un autre corps répond 409 IDEMPOTENCY_CONFLICT.
  • Une tranche est connue par son lot et son numéro plutôt que par sa clé : la même tranche renvoyée ne change rien et répond à nouveau par son reçu, quelle que soit sa clé ; d’autres factures sous un numéro déjà reçu répondent 409 IDEMPOTENCY_CONFLICT.
  • Une réponse perdue, un délai dépassé ou 503 SWITCH_UNAVAILABLE vous laisse sans la réponse : renvoyez la même requête sous la même clé avec le même corps, jamais sous une nouvelle clé. Une tranche qui a reçu 503 n’a été gardée nulle part et est jugée à nouveau ; un envoi qui l’a reçu n’a rien fait et son lot reste READY à sa version ; un lancement qui l’a reçu s’est arrêté où il en était et n’envoie rien deux fois.

Les refus

Section intitulée « Les refus »

Les refus propres à une route de facture répondent MerchantInvoiceError : un code stable sur lequel décider, avec les messages anglais et français de Futa. Les autres répondent le corps Error de la page Erreurs : sur chaque route de facture, 400 INVALID_REQUEST du framework, 401 INVALID_API_KEY, 403 INSUFFICIENT_SCOPE, 429 RATE_LIMITED et 500 INTERNAL_ERROR, et sur chaque écriture 413 REQUEST_TOO_LARGE au-delà de 16 Kio, ou de 512 Kio pour une tranche, et 415 UNSUPPORTED_MEDIA_TYPE. Une requête qui porte un en-tête X-Futa-, que seuls les services de Futa envoient, est refusée 400 avant que rien ne soit gardé.

{
  "error": {
    "code": "INVOICE_BATCH_LIMIT_REACHED",
    "message_en": "You already have 20 batches in preparation: send or discard one before creating another.",
    "message_fr": "Vous avez déjà 20 lots en préparation : envoyez-en ou annulez-en un avant d'en créer un autre."
  }
}
Route Ses propres refus
POST /v1/invoice-batches 400 INVALID_REQUEST ; 409 INVOICE_BATCH_LIMIT_REACHED : vos lots ouverts, MAPPING, VALIDATING, RECEIVING ou READY, ont atteint leur limite de 20, SYNTHETIC ; 409 MESSAGES_NOT_CONFIGURED : un canal choisi hors du bac à sable ; 409 IDEMPOTENCY_CONFLICT
GET /v1/invoice-batches 400 INVALID_REQUEST ; 404 INVOICE_BATCH_NOT_FOUND : le curseur n’est aucun de vos lots
GET /v1/invoice-batches/{id} 400 INVALID_REQUEST ; 404 INVOICE_BATCH_NOT_FOUND ; 503 SWITCH_UNAVAILABLE : la lecture n’a rien changé, relisez
POST /v1/invoice-batches/{id}/invoices 400 INVALID_REQUEST, une tranche numérotée au-delà des factures annoncées ou qui numérote deux fois une ligne ; 404 INVOICE_BATCH_NOT_FOUND ; 409 INVOICE_BATCH_TOO_LARGE : une ligne au-delà des factures annoncées, ou reçue dans une autre tranche ; 409 INVOICE_BATCH_CHANGED : le lot ne prend plus de factures ; 409 IDEMPOTENCY_CONFLICT ; 503 SWITCH_UNAVAILABLE
GET /v1/invoice-batches/{id}/invoices 400 INVALID_REQUEST ; 404 INVOICE_BATCH_NOT_FOUND ; 404 INVOICE_NOT_FOUND : le curseur n’est aucune des factures du lot
POST /v1/invoice-batches/{id}/send 400 INVALID_REQUEST ; 404 INVOICE_BATCH_NOT_FOUND ; 409 INVOICE_BATCH_NOT_VALIDATED : ses factures ne sont pas toutes arrivées, le mappage d’un fichier n’est pas confirmé, ou aucune n’est prête ; 409 INVOICE_BATCH_CHANGED : sa version n’est pas celle envoyée, ou il a été envoyé, annulé ou est caduc ; 409 MESSAGES_NOT_CONFIGURED ; 409 MERCHANT_NAME_INVALID : votre nom enregistré ne respecte pas la règle des textes, rien n’est fait ; 409 IDEMPOTENCY_CONFLICT ; 503 SWITCH_UNAVAILABLE
GET /v1/invoices/{id} 400 INVALID_REQUEST ; 404 INVOICE_NOT_FOUND ; 503 SWITCH_UNAVAILABLE : la lecture n’a rien changé, relisez
POST /v1/sandbox/invoice-reminders/run 400 INVALID_REQUEST, aussi pour un as_of hors de maintenant à 100 jours plus tard ; 409 IDEMPOTENCY_CONFLICT ; 503 SWITCH_UNAVAILABLE
POST /v1/invoice-batches/{id}/discard 400 INVALID_REQUEST ; 404 INVOICE_BATCH_NOT_FOUND ; 409 INVOICE_BATCH_CHANGED : sa version n’est pas celle envoyée, ou il est en cours d’envoi, a été envoyé, a échoué à l’envoi, est caduc ou a été annulé ; 409 IDEMPOTENCY_CONFLICT

Le lot ou la facture d’un autre marchand répond 404, comme un lot ou une facture inconnus. Seul SWITCH_UNAVAILABLE vous demande de renvoyer la requête, sous la même clé ; aucun refus n’invite à réessayer sous une autre clé.

Plafonds et conservation

Section intitulée « Plafonds et conservation »

Chaque plafond ci-dessous est celui du contrat ; ceux marqués SYNTHETIC sont des choix du bac à sable, pas des valeurs de production.

  • Un lot contient au plus 50 000 factures, envoyées par tranches d’au plus 1 000 factures et 512 Kio ; tout autre corps est lu dans la limite de 16 Kio.
  • Les lots ouverts, ceux MAPPING, VALIDATING, RECEIVING ou READY : au plus 20 par marchand, SYNTHETIC.
  • Une échéance est un jour de Kinshasa du lendemain de la vérification à 90 jours plus tard, SYNTHETIC.
  • Un lot pas envoyé devient caduc sept jours après sa dernière modification, SYNTHETIC.
  • Les messages : au plus 100 000 par marchand et par jour à Kinshasa, SYNTHETIC ; le lien d’après l’échéance se termine à J+8 à 09:00, SYNTHETIC.
  • Les textes : un libellé ou un nom d’au plus 100 points de code et une description d’au plus 200, une fois rognés de leurs espaces, sans caractère de contrôle, invisible ou de séparation de lignes ; une référence d’au plus 64 lettres sans accent, chiffres, _, ., / et -, commençant par une lettre ou un chiffre.
  • La conservation : les champs personnels d’une facture, name, phone, description et customer_reference, sont purgés 90 jours après sa clôture, PAID, EXPIRED, CANCELLED ou REFUSED, et la facture est gardée sans eux ; un lot caduc ou annulé est purgé 90 jours après sa clôture. Les deux SYNTHETIC.
  • Les frais : une facture n’en montre aucun.

L’envoi des messages

Section intitulée « L’envoi des messages »

Dans le bac à sable, les messages passent par des canaux SMS et WhatsApp synthétiques et n’atteignent aucun téléphone ; aucun transport ni expéditeur n’est encore nommé. Hors du bac à sable, un lot qui choisit un canal est refusé 409 MESSAGES_NOT_CONFIGURED. Un lot sans canal fait quand même ses liens et n’envoie aucun message.

Pas encore disponible

Section intitulée « Pas encore disponible »
  • SMS et WhatsApp réels. Les canaux sont synthétiques jusqu’au choix d’un transport.
  • Fichiers. Le dépôt d’un fichier à vos propres colonnes, le classeur des résultats et la feuille de QR à imprimer sont dans le portail marchand seulement ; l’API prend les factures en tranches JSON.
  • Relancer à la main. « Relancer les non payées » et « Renvoyer » sont dans le portail marchand seulement.
  • Participants réels. Le paiement d’une facture passe seulement par les participants synthétiques du bac à sable ; aucun fournisseur, facturier ni banque n’est nommé.
  • Un webhook de facture. Aucun : le paiement de chaque facture payée émet payment.approved.