Produits Entr'ouvert » EOPayment

Je vois dans la doc un champ associé captureDay, à voir si il ne faudrait pas gérer les deux en même temps. Aussi le paiement différé c'est une fonctionnalité qu'offre quasiment tous les backends je verrai bien cela géré de façon uniforme dans les paramètres passés à request(), mais en attendant il faudra enregistrer le même fournisseur avec les n configurations nécessaires sous forme de n régies.

De ce que je vois de commun entre SIPS et SystemPay, on peut avoir un mode validation immédiate ou manuelle et délai immédiat ou dans n jours, je proposerai deux paramètres sur requests validate=True et delay=0.

Pour l'utilisation du web-service de validation il semble qu'il faille conserver (au moins pour SystemPay) la date d'enregistrement de la transaction, VADS_TRANS_DATE coté SystemPay et Transaction_Date coté SIPS; je mettrai bien cette donnée dans un champ explicite de l'objet Response, nommé transaction_date comme on a déjà transaction_id. Le plus simple c'est que l'appelant conservant la totalité de l'objet Response() et qu'on passe cela aux différents appels de web-service cancel() / validate() comme premier argument, chaque backend y retrouvera ses petits.

Pour SIPS comportement des nouveaux arguments:

• validate=True delay=n => captureMode=AUTHOR_CAPTURE captureDelay=n
• validate=False delay=n => captureMode=VALIDATION captureDelay=n

Pour SystemPay:

• validate=True delay=0 => RIEN (normal)
• validate=True delay=n => vads_capture_delay=n
• validate=False delay=0 => vads_validation_mode=1
• validate=False delay=n => vads_validation_mode=1 vads_capture_delay=n

Après il va falloir aussi gérer les codes de retour qui deviennent un peu compliqués car il y a trois étapes: capture, autorisation et remise en banque et dans le cas ou le délai est supérieur à 6 jours, l'autorisation est faite deux fois, à T=0 pour un montant faible à jour de remise en banque-6 pour le montant total. (capture, autorisation 2 euros, validation, autorisation montant total, remise en banque).