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. Une devise absente du tableau n'est pas limitée à ce niveau. Seuls les plafonds du compte présentés plus bas s'appliquent alors.

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 Entity",

"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 Entity",

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

}

Le paiement fractionné permet de répartir un paiement entre deux et quatre débits. Le traitement des tranches fonctionne actuellement dans la sandbox. En mode live, considérez donc cette limite comme un plafond strict et utilisez un montant inférieur.

Montants autorisés pour votre compte

Six valeurs propres à votre équipe s'ajoutent aux limites par appel : plafonds unitaire, quotidien et mensuel pour les fonds entrants, puis les trois mêmes pour les fonds sortants. La vérification de conformité les détermine, pas votre plan.

Ces valeurs de base sont exprimées en XAF et ne s'appliquent jamais seules. Quatre multiplicateurs s'y ajoutent et se cumulent.

Une société vérifiée à faible risque dispose donc de 1,5 × 1,2 × 1,5 = 2,7 fois la valeur de base. Un marchand individuel en cours de vérification reste à zéro.

Une fois le plafond défini, tout dépassement 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 1 200 000 XAF exceeds your single-transaction limit of 500 000 XAF. Please contact support to increase your limit.",

"payer_message": "This payment could not be completed. Please try a smaller amount or contact the merchant."

}

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.

Votre niveau de risque multiplie cette durée par 0.5, 1, 2 ou 3. Le résultat reste compris entre 6 et 168 heures. Une équipe bénéficiant d'une dérogation explicite des opérations ignore entièrement ce calcul.

Les payouts possèdent leurs propres contrôles

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

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 lignes live. Toute création au-delà de ces quotas renvoie 403. Les liens et factures de la sandbox ne consomment aucun quota.

Requêtes par minute

Quatre compteurs s'appliquent à chaque appel et le premier dépassé provoque le refus. Ils ne sont pas interchangeables. Une requête sous le plafond de l'équipe peut toujours être refusée par celui de l'IP.

Les plafonds par endpoint correspondent à une valeur de base multipliée selon le plan.

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.