Requete idêmpotente
Vue d'ensemble
Une requête d’idempotence est un mécanisme utilisé pour assurer l’exécution d’une requête lorsque votre système ne parvient pas à recevoir une réponse, tout en garantissant que les requêtes en double ne sont pas exécutées. Cela est particulièrement utile lorsqu’un appel d’API est interrompu et qu’aucune réponse n’est reçue.
Si le terminal Moneris Go a déjà complété la transaction, il renverra les détails de la requête initiale. Si le terminal est encore en cours de traitement de la requête, il reprendra normalement.
Méthode d’intégration
Intégration Cloud
Se connecte à votre système PDV via Internet. Cela permet la synchronisation en temps réel des données de transaction sur plusieurs appareils et emplacements. Idéal pour les entreprises qui ont besoin de rapports centralisés et d’une infrastructure évolutive.
Intégration directe
Connecte le terminal Moneris Go directement à votre système PDV. Le système PDV envoie les détails de la transaction au terminal, qui traite le paiement. Une option fiable pour les entreprises disposant d’une configuration PDV existante prenant en charge la communication directe avec les appareils de paiement.
NOTE
Une méthode de requête est considérée comme « idempotente » si l’effet prévu sur le serveur de plusieurs requêtes identiques avec cette méthode est le même que l’effet d’une seule requête.
L’API Cloud de Moneris prend en charge l’idempotence afin de relancer en toute sécurité des requêtes sans exécuter deux fois la même opération sur l’hôte d’autorisation. Cela est utile lorsque votre appel API est interrompu et que vous ne recevez pas de message de réponse.
Par exemple, si une requête pour une transaction « achat » ne reçoit pas de réponse en raison d’une erreur de connexion réseau, vous pouvez relancer la requête avec la même clé d’idempotence pour garantir que le titulaire de la carte ne sera pas facturé deux fois.
L’idempotence est prise en charge uniquement pour les transactions suivantes:
- synchronisation (Sync)
- lecture (Scan)
- achat (Purchase)
- remboursement avec carte enregistrée (Card-on-file Refund)
- remboursement carte présente (Card Present Refund)
- annulation (Void)
- annulation du dernier achat (Void Last)
- consultation de solde (Balance Inquiry)
- préautorisation (Pre-Authorization)
- finalisation de préautorisation (Pre-Authorization Completion)
- activation/chargement (Activate/Load)
- désactivation (Deactivate)
- obtention des données de piste (Get Track Data)
- obtention du hachage (Get Hash)
- vérification de carte (Card Verification)
Scénarios de codes de réponse idempotents
Dans tous les cas suivants, on suppose que la nouvelle requête entrante possède une clé d’idempotence identique à celle de l’une des cent dernières commandes traitées.
| Scénario | Code d’état | En-tête d’état | Codes d’erreur | Paramètre |
|---|---|---|---|---|
| Nouvelle requête avec la même action et le même montant (si applicable) | 5206 | De l’enregistrement original | De l’enregistrement original | De l’enregistrement original |
| Nouvelle requête avec la même action mais un montant différent | 5462 | Enregistrement de transaction avec la même clé ID déjà existant | 5915 | Valeur en double. Le champ d’erreur indiquera « data.request[0] et idempotencyKey » |
| Nouvelle requête avec le même montant (ou aucun montant), mais des actions différentes | 5462 | Enregistrement de transaction avec la même clé ID déjà existant | 5915 | Valeur en double. Le champ d’erreur indiquera « data.request[0] et idempotencyKey » |
| Montants et actions différents | 5462 | Enregistrement de transaction avec la même clé ID déjà existant | 5915 | Valeur en double. Le champ d’erreur indiquera « data.request[0] et idempotencyKey » |
| Si une déconnexion survient entre le PDV et le terminal, le PDV peut renvoyer la requête initiale avec des données identiques. Le terminal acceptera la requête de transaction et poursuivra son traitement. | 5202 | Requête déjà acceptée | 5202 | Requête déjà acceptée |