Produits Entr'ouvert » EOPayment

Toute d'abord j'ai écrit tout ça en 2012 et je ne l'ai jamais utilisé donc ce n'est plus très frais dans ma tête :)

Ceci étant dit c'est order_id que vous devez utiliser pour lier les requêtes de paiement avec les réponses. Le champ transaction_id sert normalement à renvoyer le numéro de transaction interne à la plateforme de paiement.

Le code du module SIPS est un peu difficile à suivre parce que l'API SIPS elle même utilise des termes identiques à ceux employés dans eopayment mais pour des choses différentes; ici le transaction_id dans eopayment est généralement un numéro unique dans le temps de transaction mais chez SIPS c'est un numéro unique sur 24H, à 6 chiffres. Dans la méthode request on génère alors deux choses, order_id qui sera le numéro de transaction coté commerçants unique dans le temps, et le transaction_id pour faire plaisir à l'API SIPS mais qui de mon point de vue ne sert à rien. (J'ai relu rapidement http://mojoh.free.fr/optimalog/rapport/guide_developpeur%20BANQUE%20POPULAIRE.pdf pour vous répondre, ce n'est peut-être plus à jour).

Vous voulez dire que le champ transaction_id envoyée dans la requête n'est pas le même que celui renvoyé par Mercanet dans réponse ?

Par souci de cohérence, je pense qu'il est préférable de renvoyer TRANSACTION_ID dans la réponse. De plus, il me semble que c'est le numéro qui est utilisé dans les journaux de transaction disponibles dans le backoffice Mercanet.

J'ai besoin de cet identifiant à des fins de rapprochement comptable entre les données stockées par ma solution et celles affichées dans le backoffice marchand. Je teste cette modification et vous tiens au courant.

Le mieux serait que vous proposiez un patch, comme je vous l'ai dit je ne maintiens plus cette partie, merci :) Mais clairement d'après la doc SIPS que je pointe plus haut transaction_id seul ne peut-être utilisé pour un rapprochement comptable, il n'a aucune garantie d'unicité. Il faut au minimum le coupler avec la date.

À noter aussi que l'intégralité des champs renvoyés pas SIPS se trouve dans response.bank_data.

Je proposerai un patch le cas échéant. Mais oui, l'unicité est garantie par le couple date/transaction_id qui sont tous les deux renvoyés avec la réponse.

Apparemment SIPS a changé son interface, j'ai implémenté la nouvelle dans sips2.py .

De mon côté je m'en suis sorti autrement, j'utilise le champ ORDER_ID qui apparaît bien dans les journaux générés par Mercanet.