Plafonds et quotas

Quatre plafonds différents peuvent refuser le même appel. Chacun renvoie un code de statut distinct. Ce code vous indique immédiatement le plafond atteint.

Les quotas du plan constituent un cinquième type. Ils refusent la ressource plutôt que le montant. Vous ne pouvez plus créer de liens de paiement ni de factures lorsque le quota du plan est épuisé.

Montants par devise

Un même tableau régit les deux directions. POST /payments et POST /transfers utilisent les mêmes plafonds par devise. Un payout est donc refusé avec les mêmes valeurs qu'un paiement du même montant. Les montants utilisent les unités principales.

Quatre-vingt-douze devises possèdent des limites, pas seulement celles affichées ci-dessus, et l'API refuse un montant qui en sort.

Lorsqu'un montant dépasse les limites, l'appel n'atteint jamais le prestataire.

Réponse 422 pour un paiement de 10 XAF

{

"code": 422,

"status": "Unprocessable Content",

"message": "Amount must be between 25 and 2000000 XAF.",

"errors": {

"amount": [

"The amount must be between 25 and 2000000 XAF."

]

}

}

Le même refus sur POST /transfers contient Transfer amount must be between …, avec les deux mêmes valeurs.

Un débit Mobile Money possède son propre plafond

Le plafond de la devise limite le montant total du paiement. Le plafond Mobile Money limite un seul débit sur un portefeuille et sa valeur est bien plus basse.

Un débit Mobile Money supérieur à ce plafond est refusé pendant le traitement, pas à la création. Le paiement reste pending et peut faire l'objet d'une nouvelle tentative.

Réponse 422 pour un débit Mobile Money de 900 000 XAF

{

"code": 422,

"status": "Unprocessable Content",

"message": "This transaction amount exceeds the per-transaction limit for cm.mtn. Use split_count or split_amounts to split the payment.",

"payer_message": "This amount is above the limit for this payment method. Use a smaller amount or another method.",

"errors": {

"request": [

"This transaction amount exceeds the per-transaction limit for cm.mtn. Use split_count or split_amounts to split the payment."

]

}

}

Un paiement au-dessus du plafond peut être réglé en deux à quatre débits, chacun sous le plafond, une fois les tranches activées : Paiements fractionnés décrit les appels. Un débit unique au-dessus est refusé, en live comme en sandbox : rien ne fractionne un paiement de lui-même.

Montants autorisés pour votre compte

Votre compte a ses propres plafonds au-delà des limites par appel : plafonds unitaire, quotidien et mensuel pour les fonds entrants, puis les trois mêmes pour les fonds sortants. Ils dépendent de votre vérification, de votre activité et de l'évaluation des risques faite par Wajub, pas de votre plan. Vos plafonds actuels sont affichés dans le Dashboard ; écrivez au support pour les relever.

Une fois votre compte vérifié, tout dépassement d'un plafond apparaît comme un refus.

Réponse 402 pour un paiement supérieur au plafond unitaire

{

"code": 402,

"status": "Payment Required",

"error_code": "limit_exceeded",

"message": "Transaction amount 180 000 XAF exceeds your single-transaction limit of 150 000 XAF. Please contact support to increase your limit.",

"payer_message": "This payment exceeds the amount this merchant can currently accept."

}

Les compteurs quotidiens et mensuels utilisent les paiements live crédités dans la devise concernée. Ils se réinitialisent à minuit UTC et le premier jour du mois. Les compteurs de payouts additionnent les transferts pending, processing, review et succeeded. Un payout soumis à une vérification consomme donc toujours le quota du jour.

Les fonds sont retenus avant leur retrait

Un paiement crédité arrive dans pending_balance, puis passe dans available_balance à la fin de la période de retenue. Sa durée de base dépend du réseau utilisé pour recevoir les fonds.

La retenue de votre compte peut être plus courte ou plus longue que la durée par défaut, selon votre activité et l'évaluation des risques faite par Wajub.

Les payouts possèdent leurs propres contrôles

Deux mécanismes interviennent entre la requête de payout et l'envoi des fonds. Ils sont indépendants des plafonds de montant ci-dessus.

La fréquence compte ce qui a été accepté, pas ce qui a été tenté. Un payout refusé pour n'importe quelle raison, plafond de fréquence compris, n'occupe aucune place dans l'heure : réessayer un payout refusé ne prolonge donc jamais l'attente. Un lot est un seul appel : il occupe une des six places quel que soit son nombre de lignes, et la rend s'il n'envoie finalement rien. Chaque ligne ajoute tout de même son montant aux 3 000 000 XAF. Un payout dans une autre devise est converti en XAF au taux de Wajub avant d'être ajouté. La relance d'un lot dont des lignes sont déjà parties n'est jamais refusée en bloc : ces lignes reviennent telles quelles, et seule une ligne encore à envoyer est refusée quand il ne reste plus de place. Les deux plafonds sont fixés par compte, et seul Wajub peut les relever.

Un payout retenu n'a pas échoué. Il reste dans l'état review et se poursuit après son approbation. Traitez review comme un état normal dans votre rapprochement, pas comme une erreur.

Quotas des plans

Le plan régit les ressources et le débit, jamais les montants.

Les quotas de liens et de factures comptent uniquement les liens et les factures live. Toute création au-delà de ces quotas renvoie 403. Les liens et les factures n'existent qu'en live : avec une clé sandbox, l'API répond 403 (This feature is only available in live mode.).

Requêtes par minute

Trois compteurs s'appliquent à chaque appel fait avec une clé, et le premier dépassé provoque le refus. Tous les trois suivent votre plan : une clé peut consommer tout le budget de l'équipe, et une équipe Enterprise n'a de plafond sur aucun d'eux.

Les plafonds par endpoint sont des parts des 120 requêtes par minute du plan d'entrée, et ils suivent le plan : trois fois plus sur Growth, six fois plus sur Scale. Chaque appel sur la ressource compte, lectures comprises.

Un appel a son propre plafond fixe, sur tous les plans, Enterprise compris : POST /beneficiaries/{id}/verify, qui demande à un opérateur le nom derrière un numéro, accepte 10 vérifications par minute et 200 par jour et par compte en live, et 10 par minute en sandbox.

Limites de requêtes présente les en-têtes de réponse et les deux formes du corps d'une réponse 429.

Limites des champs

Voici les limites de validation que vous risquez le plus de rencontrer. Elles proviennent directement des règles des requêtes.

Livraison des webhooks

Répondez avant l'expiration du délai pour éviter une nouvelle livraison. Vous devez donc accuser réception avant de lancer le traitement.