Foire Aux Questions

Les interfaces API (interfaces de programmation d'applications) permettent aux systèmes et aux applications de s'échanger des renseignements en temps réel.

Les interfaces API de BMO vous permettent de lier vos systèmes comptables, systèmes de gestion de trésorerie et autres programmes financiers à vos comptes des Services bancaires en ligne pour entreprises. Ainsi, vous avez accès à vos activités bancaires en temps réel et aux services de paiement dans les programmes que vous utilisez chaque jour, sans avoir à exporter des données, à télécharger des fichiers ou à ouvrir une session des Services bancaires en ligne pour entreprises. Vous pouvez également utiliser nos interfaces API pour créer vos propres fonctionnalités afin d'intégrer nos services bancaires directement dans vos propres applications et plateformes. Nos interfaces API font travailler vos données bancaires pour vous.

Les interfaces API de BMO vous permettent d'accéder aux données de vos comptes et aux services de paiement et de les utiliser quand vous le souhaitez et où que vous soyez. Des clients comme vous utilisent nos interfaces API pour:

• consulter les soldes de tous leurs comptes en temps réel;
• récupérer les soldes de fin de journée, de fin de mois et de fin d’exercice de tous leurs comptes;
• récupérer les historiques de leurs transactions;
• examiner des transactions en fonction d’un ensemble de critères précis;
• remplacer des fichiers BAI et d’autres rapports et processus de règlement.
• récupérer les images des chèques et d’autre articles déposés.
• valider les comptes tiers avant de créer des transactions
• envoyer ou percevoir des paiements
• traiter les achats intégrés à l'appli et approvisionner les portefeuilles digitaux
• recevoir des notifications sur l'état des paiements en temps réel par interface API, courriel ou message texte

Une fois que vous avez créé un compte sur le portail des développeurs BMO, vous pouvez :

• ajouter et gérer l'accès des membres de votre équipe
• explorer nos interfaces API et notre documentation détaillée
• utiliser notre Explorateur des interfaces API pour essayer nos interfaces API et obtenir des exemples de code
• accéder à vos identifiants bac à sable
• générer les jetons d'accès bac à sable
• connecter vos applications directement à notre bac à sable
• demander l'accès à notre environnement de préproduction
• gérer les données de test pour les tests de préproduction
• demander l'accès à l'environnement de production

Si vous êtes un client des Services bancaires en ligne pour entreprises, vous pouvez vous servir de nos interfaces API pour lier vos comptes de BMO et créer des paiements dans vos systèmes comptables, systèmes de gestion de trésorerie et autres programmes financiers.

Vous pouvez expérimenter en toute sécurité avec nos interfaces API dans le bac à sable et les tester dans l'environnement préproduction, et ce, sans frais. Lorsque vous serez prêt à lancer votre application,communiquez avec nous pour discuter la tarification.

Pour explorer nos interfaces API dans les environnements bac à sable et préproduction, vous devrez remplir une demande d'ouverture de compte d'organisation sur le portail des développeurs de BMO. Une fois votre demande examinée et approuvée, nous vous enverrons un courriel contenant vos identifiants d'ouverture de session et les instructions pour ajouter les membres de votre équipe.

Si vous faites une demande de compte d'organisation et que celle-ci est approuvée, nous vous enverrons deux courriels : le premier contiendra les renseignements relatifs à la configuration du compte et le second, un lien pour créer un mot de passe. Si vous ne voyez pas ces courriels, vérifiez votre courrier indésirable. Si vous ne les trouvez toujours pas, communiquez avec nous.

Pour essayer notre bac à sable dans votre propre application, vous aurez besoin d'une clé API. Cette clé API, ainsi que le code de client et le code secret client affichés sous « Mes applications », peuvent être utilisés directement dans votre application pour communiquer avec notre environnement bac à sable. En fonction de vos préférences linguistiques, vous pouvez choisir entre une clé API pour les réponses en anglais et une autre pour les réponses en français.

Une fois que vous disposez de votre clé API, utilisez notre interface API Autorisation ou rendez-vous sur notre Explorateur des interface API sur ce site pour générer votre jeton d'accès. Vous pouvez utiliser ce jeton et les autres identifiants bac à sable pour essayer n'importe laquelle de nos interfaces API.

1. Dans le portail des développeurs de BMO, sélectionnez votre nom d’utilisateur et cliquez sur Mes applis dans la liste déroulante.
2. Cliquez sur le bouton Enregistrer une appli.
3. Fournissez les renseignements demandés, puis cliquez sur Enregistrer une appli.

Une fois que vous avez votre clé, allez à notre bac à sable et générez un jeton d'accès. Vous pourrez utiliser ce jeton pour tester n’importe laquelle de vos applications enregistrées.

Votre clé API est l'un des identifiants que nous vous attribuons. Elle nous permet de vérifier votre identité et de déterminer quelle application tente de se connecter à nos interfaces API.

Dans notre bac à sable, la clé API peut être partagée pour toutes vos applications et se trouve sous « Mes applications » avec les autres identifiants. Nous proposons également deux clés API distinctes qui déterminent la langue dans laquelle vous souhaitez recevoir vos réponses de code.

Pour nos environnements de préproduction et de production, nous vous enverrons une clé interface API unique et distincte pour chaque application.

Vous pouvez utiliser les identifiants bac à sable de votre compte avec un nombre illimité d'applications. Il n'est pas nécessaire d'enregistrer des applications spécifiques à ce stade.

Une fois qu'une application est prête à passer à l'environnement de préproduction, il vous suffit d'en demander l'accès et nous enregistrerons votre application pour vous et vous communiquerons vos nouveaux identifiants. Il n'y a aucune limite au nombre d'applications que vous pouvez enregistrer en préproduction. Il en va de même lorsque vous passez en production.

Toutes nos interfaces API sont prises en charge par l’infrastructure OAuth 2.0 standard.

Pour être autorisé à faire des appels, reportez-vous à nos documents d’autorisation. Vous y trouverez tous les renseignements nécessaires à la mise en œuvre d’un flux OAuth à trois parties.

Vous devez générer et utiliser un jeton d’accès pour autoriser votre application à connecter à nos environnements bac à sable, préproduction et production. Vous pouvez générer des jetons d'accès bac à sable dans notre outil Explorateur des interface API sur ce site ou utiliser l'interface API Autorisation. Pour les environnements de préproduction et de production, vous devez générer vos jetons d'accès uniquement à l'aide de notre interface API Autorisation. Pour plus d'informations, veuillez consulter notre documentation sur l'interface API Autorisation.

Les identifiants à entrer varient selon que vous connectez à l'environnement bac à sable, préproduction ou production

Dans les environnements bac à sable et préproduction, tous les identifiants d'ouverture de session sont saisis automatiquement pour vous.

Une fois que vous êtes prêt à lancer votre application et à accorder l'accès à vos comptes, utilisez vos identifiants des Services bancaires en ligne pour entreprises existants.

Lorsque vous effectuez un appel dans notre système, en particulier un appel de type Search for Accounts, vous obtenez une liste des comptes autorisés. Pour des raisons de sécurité, ces comptes porteront un code unique différent du numéro de compte.

Pour connaître le compte associé au code obtenu, reportez-vous au champ du numéro de compte dans le corps de la liste.

Lorsque vous connecterez une application dans l’environnement de production, vous verrez les comptes que vous avez le droit de consulter dans les Services bancaires en ligne pour entreprises.

Dans le flux d’autorisation, vous pourrez choisir les comptes auxquels vous souhaitez donner accès.

En plus de l'interface API – Authorize qui permet un accès sécurisé de votre application à nos serveurs, vous n'aurez besoin que de l'interface API – Image Retrieval pour récupérer les images de dépôt.

Une fois que votre application a été authentifiée au moyen de l'interface API – Authorize, vous pouvez commencer votre recherche d’images de dépôt. Voici comment ça fonctionne :

• Obtenez une liste de vos comptes autorisés des Services bancaires en ligne pour entreprises.
• Précisez le numéro de compte, la plage de dates et le type d'article. Vous pouvez également ajouter d’autres critères de recherche.
• Dans l'index des images disponibles, choisissez celles que vous voulez récupérer.

Le processus est le même pour les articles canadiens et américains.

Vous pouvez demander des images d'articles déposés remontant à aussi loin que sept ans. Pour les conserver encore plus longtemps, vous pouvez utiliser l'interface API pour les télécharger et les enregistrer automatiquement dans vos propres archives.

En plus de l'interface API « Account Validation » pour vérifier le titulaire de comptes, vous aurez également besoin de l'interface API « Authorize » pour donner à votre compte un accès sécurisé à nos serveurs et de l'interface API « Encryption » pour chiffrer les renseignements confidentiels de bout en bout.

À l’heure actuelle, cette interface API prend en charge uniquement les comptes d’épargne et de dépôt aux États-Unis.

Chaque appel permet de valider jusqu'à 100 comptes. Il n'y a aucune limite pour les appels que vous soumettez.

Vous pouvez choisir de vérifier le titulaire du compte, le niveau de risque ou les deux. Il vous suffit de soumettre les renseignements que vous voulez que nous vérifiions.

Les paiements ACH peuvent toujours être rejetés en raison des validations d'affaires en aval qui ont habituellement lieu après l'acceptation de la demande initiale. Voici les raisons courantes de rejet :

• restrictions relatives à la banque bénéficiaire
• renseignements inexacts sur le bénéficiaire
• validations des limites
• vérification des sanctions

Si vous n'êtes pas en mesure de résoudre le problème, veuillez nous envoyer un courriel à

tps.apisupport@bmo.com

Les règles d'exploitation et les lignes directrices de la Nacha fournissent une liste définie des caractères spéciaux autorisés qui doivent être respectés lors du traitement des transactions.

L'utilisation de caractères non autorisés peut entraîner le rejet du lot ou du paiement. Consultez les spécifications de l’interface API ACH pour connaître tous les caractères spéciaux approuvés.

Aujourd'hui, nous avons la balise parent « Category Purpose Code » qui sert à indiquer l'objet du paiement, et ce champ est limité à 4 caractères.

Puisque la spécification Nacha des microdépôts exige que la phrase ACCTVERIFY soit ajoutée pour toutes les transactions de microdépôt, la balise enfant « Category Purpose proprietary » sera mise en correspondance avec la description de l'entrée de la société (Company Entry Description) avec une limite de 35 caractères.

Les transactions API de microdépôts des clients pourront ainsi être formatées conformément à la norme Nacha. Ce changement entrera en vigueur en juillet 2026. Il sera également pris en charge dans le Portail des développeurs de BMO aux fins de mise à l'essai à l'automne 2026.

Les paiements SVA peuvent toujours être rejetés en raison des validations d'affaires en aval qui ont habituellement lieu après l'acceptation de la demande initiale. Voici les raisons courantes de rejet :

• restrictions relatives à la banque bénéficiaire
• renseignements inexacts sur le bénéficiaire
• validations des limites
• vérification des sanctions

Si vous n'êtes pas en mesure de résoudre le problème, veuillez nous envoyer un courriel à

tps.apisupport@bmo.com

Les paiements instantanés peuvent toujours être rejetés en raison des validations d'affaires en aval qui ont habituellement lieu après l'acceptation de la demande initiale. Voici les raisons courantes de rejet :

• restrictions relatives à la banque bénéficiaire
• renseignements inexacts sur le bénéficiaire
• validations des limites
• vérification des sanctions

Si vous n'êtes pas en mesure de résoudre le problème, veuillez nous envoyer un courriel à

tps.apisupport@bmo.com

Oui, vous pouvez choisir la façon dont le lien d'exécution est envoyé. Nous pouvons soit vous renvoyer le lien directement à votre système, l'envoyer par courriel au répondant ou faire les deux. Cela vous donne un contrôle total et vous permet de supprimer la notification par courriel si elle ne correspond pas à votre expérience ou à votre flux de travail.

Oui, vous pouvez préciser le nom du demandeur affiché dans la charge utile.

Le paiement demeurera en attente jusqu'à ce que la question et la réponse soient répondues, jusqu'à l'expiration du paiement ou jusqu'à l'annulation du paiement.

Le destinataire a 3 tentatives.

L’interface API de Paiements instantanés règle les paiements au moyen du service Virement Interac. Les transactions Virement Interac sont des paiements définitifs et irrévocables. Cela signifie que, contrairement aux chèques ou aux dépôts directs, qui peuvent potentiellement être retournés ou annulés, les paiements instantanés ne peuvent pas être annulés. Il peut y avoir certaines exceptions, comme les fonds mal acheminés, les problèmes de fraude et les enquêtes liées à la LBA.

Interac a augmenté le nombre d'institutions financières en mesure de recevoir des paiements acheminés par numéro de compte. Vous trouverez la liste complète sur le site d’Interac. En même temps, le point de terminaison « Obtenir les options de paiement » vous permet de nous envoyer un appel API avec le numéro de compte du destinataire, et nous répondrons en temps réel si cette institution financière prend en charge l'acheminement du numéro de compte.

Même si la demande passe la validation du schéma et du format, les virements télégraphiques peuvent toujours être rejetés en raison des validations d’affaires en aval. Ces validations ont habituellement lieu après l'acceptation de la demande initiale.Les raisons courantes comprennent :

• BIC invalide ou inexistant
• restrictions relatives aux banques bénéficiaires
• limites de devises ou de corridors
• contrôle des sanctions
• absence de données de règlement requises

Un virement télégraphique peut demeurer à l'état d'attente ou de traitement en raison des heures limites, du traitement par une banque intermédiaire, de vérifications de conformité ou du calendrier de règlement en aval. Les mises à jour sur l'état sont fournies à mesure qu'elles sont accessibles par l'intermédiaire de l'interface API.

Chaque soumission de virement télégraphique doit inclure un « MessageIdentification », un identifiant d'interface API unique utilisé pour identifier la demande de paiement. La valeur ne doit pas contenir plus de 35 caractères et être unique au cours d'une période de 6 mois. Les soumissions en double ne sont pas permises et échoueront avec une réponse pain.002. Pour tenter de nouveau un virement télégraphique, les clients doivent soumettre une nouvelle demande au moyen d'un nouveau « MessageIdentification » unique.

Le bac à sable n'effectue pas de vérification complète des sanctions, ni de validation du réseau, ni d'acheminement en direct entre banques. Les défaillances de production sont souvent liées à des données bancaires réelles, à des vérifications de conformité ou à des restrictions relatives aux corridors qui ne sont pas entièrement simulées dans le bac à sable.

Le débiteur ultime (Ultimate Debtor) désigne la personne ou l'organisation qui fournit ultimement les fonds pour le virement télégraphique. Ces renseignements ne sont fournis que lorsque les droits appropriés sont activés. Si ces renseignements sont manquants, il est possible que l'établissement de votre organisation ne dispose pas des autorisations requises. Veuillez communiquer avec votre représentant pour confirmer votre configuration.

Remarque : Pour les types de clients Entreprises de services monétaires (ESM), Prêts pour paiement de paiement – Autre ou Expéditeur tiers de la Mise de paiement pour paiement de tiers, des renseignements sur le débiteur ultime sont requis. S'il n'est pas fourni, le virement télégraphique sera rejeté.

Non, les virements télégraphiques effectués au moyen de l'interface API ne s'affichent pas dans les Services bancaires en ligne pour entreprises.

Il est fortement recommandé de fournir l’adresse « Creditor Address » complète pour faciliter tout examen de conformité.

Clients américains – Seuls « Creditor Town Name/City » et « Country » sont des champs obligatoires (à compter de novembre 2026) lors de l'envoi d'un virement télégraphique national ou international (à l'extérieur du Canada).

Lorsque vous envoyez un paiement à un « Creditor » domicilié au Canada, l'adresse complète doit être fournie.

* L'environnement de préproduction valide actuellement l'adresse complète du Creditor pour tous les pays, même si ce n'est pas une exigence dans le cadre de l’environnement de production.

Clients au Canada – L'adresse complète du « Creditor » est obligatoire.

Les cours TTL pour les jetons sont identiques dans tous les environnements de bac à sable, de préproduction et de production :

• codes d'autorisation expirent après 5 minutes
• jetons d'accès expirent après 15 minutes
• jetons d'actualisation expirent après 1 mois

L'authentification pour les environnements de bac à sable et de préproduction repose sur la vérification des identifiants du client.

• Pour trouver vos identifiants de test de bac à sable, accédez au Portail des développeurs de BMO > Espace de travail > Mes applications.
• Pour les identifiants de test en préproduction, nous vous les enverrons par courriel. Consultez notre Guide du client OAuth

L'authentification en production repose sur des identifiants de production précis qui vous donnent accès à notre environnement de production. Vous les recevez par courriel sécurisé.

Oui, BMO émet un nouveau jeton d'actualisation chaque fois qu'un jeton est échangé au point de terminaison /oauth20/token. Le nouveau jeton d'actualisation est valide pendant 1 mois (30 jours). L'ancien jeton ne sera plus valide.

Si vos interfaces API ne sont pas utilisées activement pendant un certain temps, vos identifiants d'accès peuvent expirer pour des raisons de sécurité. Dans ce cas, vous devrez de nouveau suivre le processus d'autorisation et de consentement pour rétablir l'accès. Cela permet de s'assurer que les identifiants ne sont actifs que lorsqu'ils sont utilisés.

Les échecs de la vérification du consentement dépendent du type de paiement (rail de paiement) et du niveau auquel le consentement échoue.

• Si le consentement échoue au niveau de l'identifiant SBLE, le message complet échoue pour tous les types de paiement.
• Si le consentement échoue au niveau du compte, du numéro de compte SVA ou de l'ACH Company ID, le résultat dépend du type des paiements.
  • Dans le cas des transactions ACH, une omission de consentement au niveau de l'ACH Company ID entraîne l'échec seulement du lot concerné — et de toutes les transactions à son intérieur — et non l'ensemble du message.
  • Dans le cas des transactions SVA, des virements télégraphiques et du service Interac (paiements instantanés), une omission de consentement au niveau du compte entraîne l'échec de l'ensemble du message.

Le consentement est validé au moyen de correspondances exactes. Si le numéro de compte, l’ACH Company ID ou le numéro de compte SVA dans votre demande ne correspond pas exactement à ce qui a été autorisé au moment du consentement, la demande échouera. Cela comprend les différences de formatage ou de longueur.

Les charges utiles chiffrées doivent utiliser un encodage Base64. Si votre intégration utilise un encodage Base64URL, la demande pourrait échouer. Veiller à ce que le bon format d'encodage est important pour réussir le chiffrement et le déchiffrement.

Nous suivons un modèle où vous :

• Générez une clé de chiffrement du contenu (CEK) symétrique
• le chiffrez à l'aide de la clé publique de BMO (extraite du point de terminaison de la clé de chiffrement)
• envoyez la clé CEK chiffrée à BMO dans l'en-tête de x-crypto-key

BMO déchiffre la clé CEK avec sa clé privée et utilise la même clé CEK pour chiffrer la réponse qui vous est retournée. Comme vous avez créé la clé CEK et que vous la maintenez dans la main, vous pouvez déchiffrer la réponse à l'aide de cette clé.

Sommaire des directions clés :

• BMO → client : clé publique de BMO
• Client → BMO : clé CEK chiffrée
• Client garde : clé CEK (utilisé pour déchiffrer les réponses)

En production, chaque clé publique est valide pendant 120 jours. Pour assurer la continuité, BMO effectue automatiquement la rotation des clés de 7 à 10 jours avant qu'elles expirent.. Il incombe aux clients de récupérer et d'utiliser la nouvelle clé publique avant que l'ancienne clé expire.La réponse API de clé publique comprend un horodatage , afin que vous puissiez facilement savoir quand une actualisation est requise.

Façons recommandées de gérer la rotation des clés

Ces options garantissent que votre intégration continue de se dérouler sans interruption en raison de l'expiration des clés.

Option 1 : Mise en mémoire cache et actualisation (recommandée)

• Stockez la clé publique en toute sécurité.
• Surveillez l'horodatage.
• Récupérez une nouvelle clé avant que 'ancienne clé expire.

Option 2 : Récupération planifiée

• Récupérez la clé publique selon un horaire régulier (p. ex., quotidiennement ou hebdomadaire).
• Utilisez toujours la clé la plus récente rentrée par l'interface API.

Veuillez nous envoyer un courriel à

tps.apisupport@bmo.com

Les environnements de bac à sable et préproduction sont conçus pour soutenir les tests et l'intégration, mais ils ne se comportent pas toujours exactement comme la production.

Bien que l'intention soit d'assortir le plus possible, il peut y avoir quelques petites différences selon la version.

Si vous rencontrez un problème, veuillez consulter les guides de bac à sable et de préproduction.

Si vous n'êtes pas en mesure de résoudre le problème, veuillez nous envoyer un courriel à

tps.apisupport@bmo.com

Les schémas définissent la structure attendue des données — quels champs sont autorisés, lesquels sont requis, leur format et les règles qu'ils doivent suivre. Ils sont utilisés pour valider les demandes et les réponses,, en s'assurant que les données sont complètes, correctement formatées et uniformes afin que les systèmes puissent les traiter de façon fiable.

Vous pouvez accéder aux schémas en nous envoyant un courriel à tps.apisupport@bmo.com

À l'heure actuelle, les comptes virtuels ne sont pas pris en charge par les interfaces API de paiement ou de renseignements sur les comptes.

Non, le code d'utilisateur de bout en bout ne figurera pas sur votre relevé bancaire (code d'utilisateur unique par transaction).

Interac:

• Le code d'utilisateur de bout en bout figurera sur le relevé bancaire pour les paiements envoyés.
• Le code d'utilisateur de bout en bout ne figurera pas sur le relevé bancaire pour les transactions de demande de fonds traitées.

ACH : Le code d'utilisateur de bout en bout s'affichera dans vos rapports Pain.002 et Renseignements sur les comptes/BAI

SVA : Les 19 derniers caractères du code d'utilisateur de bout en bout seront mis en correspondance aux fins de traitement des paiements et figureront dans le site Références de l'émetteur dans les Services bancaires en ligne pour entreprises.

Virements télégraphiques : Le code d'utilisateur de bout en bout s'affichera sous la balise « RFB » par l'intermédiaire du service Renseignements sur les comptes/BAI

Il ne s'affiche pas dans les champs référence de la Banque ou du client

Les codes d'état de votre paiement indiquent à quel point se trouve votre paiement. Bien que les étapes de traitement puissent varier selon le type de paiement, les définitions ci-dessous s'appliquent uniformément à l'ensemble des types de paiement pris en charge.

Remarque : Tous les types de paiement ne prennent pas en charge tous les codes d'état. Certains états ne s'appliquent qu'à certains types de paiement, comme il est indiqué ci-dessous.

ACTC – Validation technique acceptée Le paiement a été reçue et réussie toutes les validations techniques et d'affaires requises. Il s'agit du premier état positif pour tous les types de paiement.

RJCT – Rejeté Le paiement a été rejeté et ne peut pas être traité ultérieurement. Cet état peut être retourné à n'importe quelle étape du cycle de vie des paiements, pour tous les types de paiement.

ACCP – Accepté (prétraitement terminé) Le paiement a réussi les validations et est prêt pour le traitement. Cet état s'applique uniquement aux paiements ACH.

ACSP – Règlement accepté en cours Le paiement est en cours de traitement ou de règlement. Cet état s'applique à tous les types de paiement.

ACSC – Règlement accepté et effectué Le traitement et le règlement des paiements ont été effectués avec succès par BMO. Pour le service ACH, le SVA et les virements télégraphiques, il s'agit de la dernière étape de traitement.

Remarque : Les paiements ACH et SVA peuvent toujours être retournés après cet état.

CANC – Annulé Annulation du paiement effectuée avec succès. Cet état s'applique au SVA, au service ACH et aux paiements Interac.

ACCC – Crédit accepté Le règlement a été effectué et le paiement a été traité du côté du bénéficiaire. Cet état ne s'applique qu'aux paiements Interac.

PATC – Vérification technique partiellement acceptée Un état d'acceptation partielle ou provisoire utilisé lors des processus d'annulation, de mise à jour ou de suppression. Cet état s'applique uniquement aux paiements ACH.

• L'en-tête facultatif indique l'application interne sous-jacente liée à l'interface API en question : REPLACE_THIS_VALUE' \ : Facultatif; indique si la demande provient d'une application interne BMO

  Valeurs:

  • Pour Paiements ACH, il doit être 80613
  • Pour Service de virement automatisé (SVA), il doit être 87335
  • Pour Virements télégraphiques, il doit être 87102
  • Pour Paiements instantanés (Interac), il doit être 87679
• en-tête 'x-fapi-customer-ip-address: REPLACE_THIS_VALUE' \ Facultatif, l'adresse IP publique pour l'utilisateur final
• en-tête 'x-fapi-customer-last-logged-time: REPLACE_THIS_VALUE' \ Facultatif, Horodatage du dernier accès d'un utilisateur
• 'en-tête 'x-fapi-customer-user-agent: REPLACE_THIS_VALUE' \ Facultatif, Décrit le type de client utilisé par l'OP (navigateur ou appli mobile). Le client peut remplir ce champ avec la chaîne d'en-tête User-Agent si le navigateur est utilisé. Si l'appli mobile est utilisée, le contenu x-fapi-customer-user-agent doit être différent des chaînes d'agent utilisateur basées sur le navigateur.
• en-tête 'x-fapi-financial-id: REPLACE_THIS_VALUE' \ est 001 pour tous les types de paiements
• en-tête 'x-fapi-interaction-id: REPLACE_THIS_VALUE' \ Requis. C'est un moyen d'identifier la demande. Cela donne un identifiant unique à l'appel API et, dans la réponse, nous retournerons le même identifiant. Ça facilite le dépistage et le débogage, surtout s'il y a beaucoup d'appels en même temps. Peut être la même chose que le code de demande X si aucun lien de session n'est requis
• en-tête 'x-request-id: REPLACE_THIS_VALUE’ \ Requis et unique par demande. Détermine chaque demande individuelle d'interface API aux fins de dépistage et de soutien

Le système est conçu pour reconnaître lorsqu'une même demande de paiement est soumise plus d'une fois.Si le numéro de message et tous les renseignements sur le paiement sont les mêmes, le paiement ne sera pas traité de nouveau. Le système affichera plutôt le même état qui a été fourni pour le paiement initial, ce qui permettra de traiter le paiement une seule fois.Si le même code de message est réutilisé, mais que les renseignements sur le paiement sont différents, la demande est traitée comme non valide et sera rejetée, car chaque code de message doit représenter un paiement unique