Guide B2B tourisme
Ordinateur portable affichant une carte et un itinéraire, visuel généré par IAVisuel IA · Provenance

Standards et continuité · Fiche de contrôle

Contrôler un montant entre offre et API de paiement

Le même montant traverse plusieurs systèmes. Chaque passage doit conserver sa devise et sa convention pour que la finance puisse expliquer les écarts.

Publié le . Méthode éditoriale à adapter à votre produit et à votre organisation. Source de référence : Adyen : codes monétaires et unités mineures, consultée le 4 octobre 2026.

Définir ce que la fiche doit permettre de vérifier

Identifiez le champ et l’opération qui reçoivent la valeur. Un catalogue peut fournir un décimal tandis que le prestataire de paiement attend un entier en unité mineure. La documentation de ce prestataire prime pour son interface ; ne généralisez pas une règle d’une API à une autre.

Adyen publie une table de précisions et signale des divergences avec ISO 4217. Les exemples de cette fiche servent à préparer une recette arithmétique ; ils ne sont ni des taux de change ni des tarifs de voyage. La conversion et les frais doivent faire l’objet de règles séparées.

Huit champs à rapprocher de leurs preuves

Gardez la source et la date de vérification à côté des informations collectées. Sur téléphone, les contrôles se lisent en cartes.

Contrôler un montant entre offre et API de paiement : données et contrôles
ChampÀ collecterTest ou rapprochement
DeviseCode transmis avec chaque montant.Rejeter une devise absente ou inconnue au lieu de choisir EUR par défaut.
UnitéEntier ou décimal, unité principale ou mineure.Relire le contrat d’interface pour cette opération précise.
PrécisionNombre de décimales autorisé.Tester EUR, JPY et KWD selon la convention du prestataire.
ArrondiÉtape, sens et règle de calcul.Comparer somme des lignes et total ; expliquer tout écart.
Taxes et fraisMontants inclus, exclus ou payables sur place.Distinguer somme à encaisser et coût total annoncé au voyageur.
ChangeMontants source et cible, taux daté et frais.Reconstituer le calcul sans employer un taux actuel à la place du taux retenu.
RemboursementMontant et règle applicables à l’opération.Tester plusieurs remboursements partiels et leur cumul.
RapprochementOffre, transaction et écriture de règlement.Relier les valeurs par références ; conserver les écarts qualifiés.

Trois erreurs qui fragilisent le dossier

  • Multiplier chaque montant par 100.
  • Arrondir plusieurs fois sans conserver la règle.
  • Comparer des valeurs sans leur devise.

Transmettre un résultat exploitable

Remettez un dictionnaire par champ, prestataire et opération. Joignez les conversions testées, la source de la règle et les écarts de rapprochement encore ouverts.

Choisir un registre de contenus, médias ou recette · Préciser les responsabilités du parcours

Questions fréquentes

Pourquoi le montant 1234 ne suffit-il pas ?

Sa signification dépend de la devise et de la convention de l’API. Il doit être accompagné de ces informations.

ISO 4217 suffit-il pour configurer le paiement ?

Vérifiez aussi la documentation de l’opération, qui peut imposer une convention particulière.

Un remboursement doit-il suivre le taux du jour ?

La règle dépend du contrat et de l’opération. Conservez le calcul retenu et sa source plutôt que de choisir silencieusement un taux.

Approfondir ce contrôle

Toutes les fiches de contrôle · Méthode des sources

Passer à la vérification

Des fiches de contrôle pour ce sujet

Champs à collecter, tests, erreurs fréquentes et consignes de transmission pour travailler sur un dossier concret.

Toutes les fiches de contrôle →