Dernière mise à jour 2/05/2014

Contenu

7. Retour d'information sur la transaction

Les informations transmises au marchand et à son client (lorsque le paiement est accepté, que le client a annulé le paiement ou que l’acquéreur a refusé le paiement plus que le nombre de fois autorisé) varient selon les paramètres définis par le marchand.

Meilleure pratique

Redirection avec paramètres sur accept-/exception-/cancel-/declineurl (voir Option mise à jour de la base de données) avec une demande d’informations après-paiement différée pour plus de sécurité (voir Requête de réponse directes (après paiement)).

Dans votre compte PostFinance, naviguez vers "Configuration" > "Information technique" > "Retour d'information sur la transaction". Veuillez configurer les paramètres comme décrit ci-dessous. : 

Redirection HTTP dans le navigateur :

Feedback on the redirection URLs

("Je veux recevoir les paramètres de transaction en retour dans les URL lors de la redirection.")

Requête directe HTTP serveur-à-serveur :

Deferred post-payment feedback

("")

7.1 Réaction par défaut

Lorsque le marchand n’a défini aucune réaction particulière, notre système affiche le message standard pour le client : « Your payment is authorised » (Votre paiement est autorisé)  ou « The transaction has been denied » (La transaction a été refusée). Ce message est intégré dans le modèle de page.

Sur cette page, nous ajoutons également un lien vers le site du marchand et/ou le catalogue du marchand grâce aux URL (HOMEURL et CATALOGURL) envoyés dans les champs masqués du formulaire de commande. Lorsque ces URL ne sont pas précisés dans les champs masqués, notre système utilise l’URL indiqué dans le module de gestion de votre compte. 

Les champs masqués utilisés pour transmettre les URL sont les suivants :

<input type="hidden" name="CATALOGURL" value="">
<input type="hidden" name="HOMEURL" value="">

Champ
Objet
CATALOGURL URL (absolu) de votre catalogue. Une fois la transaction traitée, votre client est invité à revenir à cet URL en cliquant sur un bouton.
HOMEURL

URL (absolu) de votre page d’accueil. Une fois la transaction traitée, votre client est invité à revenir à cet URL en cliquant sur un bouton.

Lorsque vous envoyez la valeur « NONE» (néant), le bouton ramenant le client au site du marchand est masqué.

7.2 Redirection en fonction du résultat du paiement

Dans les champs masqués de son formulaire de commande, le marchand peut envoyer 4 URL (ACCEPTURL, EXCEPTIONURL, CANCELURL et DECLINEURL) vers lesquels notre système redirige le client au terme du processus de paiement.

Le marchand peut aussi configurer ces URL sous l’onglet « Retour d’information sur la transaction », dans la rubrique « redirection HTTP dans le navigateur » de la page d’information technique.

Les champs masqués utilisés pour transmettre les URL sont les suivants :

<input type="hidden" name="ACCEPTURL" value="">
<input type="hidden" name="DECLINEURL" value="">
<input type="hidden" name="EXCEPTIONURL" value="">
<input type="hidden" name="CANCELURL" value="">

Champ Objet
ACCEPTURL URL de la page Web à présenter au client une fois le paiement autorisé  (statut 5), enregistré (statut 4), accepté (statut 9) ou en attente d’une acceptation (en attente, statut 41, 51 ou 91).
DECLINEURL URL de la page Web à présenter au client lorsque l’acquéreur refuse l’autorisation (statut 2 ou 93) plus que le nombre de fois maximum autorisé.
EXCEPTIONURL URL de la page Web à présenter au client lorsque le résultat du paiement est incertain (statut 52 ou 92).
Si ce champ est vide, l’accepturl sera présenté au client en lieu et place.
CANCELURL URL de la page Web à présenter au client lorsqu’il annule le paiement (statut 1).
Si ce champ est vide, le declineurl sera présenté au client en lieu et place.

Alerte navigateur

Lorsqu’un client quitte nos pages de paiement sécurisé pour revenir sur le site du marchand, il est possible que son navigateur l’avertisse qu’il va pénétrer dans un environnement non sécurisé (étant donné qu’il passé d’un environnement https://  à un environnement http://).

Lorsque nous détectons une redirection vers le site du marchand, nous pouvons afficher un message pour signaler au client qu’il est possible qu’un avertissement apparaisse (voir la première capture d’écran au chapitre Redirection en fonction du résultat du paiement), afin de lui éviter de s’inquiéter inutilement lorsque l’alerte apparaîtra dans son navigateur. Le marchand peut activer cette option sous l’onglet « Retour d’information sur la transaction », dans la rubrique « Redirection HTTP dans le navigateur » de la page d’information technique (« Je veux que PostFinance affiche, sur la page de paiement, un message court à l’attention du client lorsqu'une redirection vers votre site est détectée juste après le processus de paiement.»)

7.3 Option mise à jour de la base de données

Le marchand peut utiliser cette redirection sur ACCEPT-/EXCEPTION-/CANCEL-/DECLINEURL pour déclencher des tâches administratives automatiques, comme des mises à jours de bases de données. Lorsqu’un paiement est exécuté, nous pouvons envoyer les paramètres de la transaction sur les ACCEPT-, EXCEPTION-, CANCEL- or DECLINEURL du marchand.

Le marchand peut activer cette option sous l’onglet « Retour d’information sur la transaction », dans la rubrique « Redirection HTTP dans le navigateur » sur la Page d’information technique:

  • « Je veux recevoir les paramètres de transaction en retour dans les URL lors de la redirection.»

Notez que nous activons toujours la requête serveur-serveur (voir chapitre Informations sur la transaction transmises au client et au marchand) pour éviter les incohérences entre le paiement et la commande dues à une manipulation du client (ex: le client ferme son navigateur avant d'avoir reçu confirmation de l'autorisation)

7.3.1 SHA-OUT

Vous devez utiliser une signature SHA-OUT pour vérifier le contenu de la demande lorsque vous utilisez cette option pour empêcher que les clients falsifient les renseignements dans le champ URL et causent une mise à jour incorrecte de la base de données.

Si vous ne configurez pas de signature SHA-OUT dans votre compte, la liste de paramètres ne sera pas transmise dans nos requêtes sur vos URL.

La chaîne est créée en concaténant les valeurs des champs envoyés avec la commande (triés par ordre alphabétique, dans le format ‘paramètre=valeur’), séparés par une clé. Cette clé est définie dans les Informations techniques du marchand, sous l’onglet “Retour d’Information sur la transaction”, section “Tous les modes de soumission des transactions.”

Pour obtenir la liste complète des paramètres à inclure dans le condensé SHA, veuillez vous reporter à la Paramètres à inclure dans le calcul SHA-OUT.

Veuillez noter que ces valeurs sont toutes sensibles à la casse. 

Important

  • Tous les paramètres envoyés (et qui apparaissent dans la liste Paramètres à inclure dans le calcul SHA), seront inclus dans la chaîne.
  • Tous les paramètres doivent être classés en ordre alphabétique
  • Les paramètres qui n'ont pas de valeur ne doivent PAS être inclus dans la chaîne
  • Lorsque vous souhaitez transférer votre compte de Test vers l’environnement de production en utilisant le lien disponible dans le back-office, une signature SHA-OUT aléatoire sera automatiquement configurée dans votre compte de production
  • Même si certains paramètres sont (partiellement) envoyés en minuscules par notre système, lors du calcul du SHA-OUT tous les paramètres doivent être mis en majuscules.
  • Pour plus de sécurité, nous vous demandons d'utiliser des mots de passe SHA différents pour TEST et PROD. Remarquez que s'ils sont identiques, votre mot de passe TEST sera modifié par notre système (vous en serez évidemment averti)

Tout comme nous récréons le condensé pour valider l’input de la transaction avec le SHA-IN, vous devez reconstruire le hachage, en utilisant cette fois la phrase passe SHA-OUT et les paramètres obtenus de notre système.

Si le résultat n’est pas identique, il se pourrait que les paramètres de la demande aient été modifiés. Cette vérification permet de d’assurer de l’exactitude et de l’intégrité des valeurs de paramètre envoyées dans la requête.

Exemple d'un calcul SHA-1-OUT élémentaire



Paramètres :

ACCEPTANCE: 1234

amount: 15

BRAND: VISA

CARDNO: XXXXXXXXXXXX1111

currency: EUR

NCERROR: 0

orderID: 12

PAYID: 32100123

PM: CreditCard

STATUS: 9



Clé SHA-OUT :

Mysecretsig1875!?



Chaîne entière à hacher :

ACCEPTANCE=1234Mysecretsig1875!?AMOUNT=15Mysecretsig1875!?BRAND=VISAMysecretsig1875!?

CARDNO=XXXXXXXXXXXX1111Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?NCERROR=0

Mysecretsig1875!?ORDERID=12Mysecretsig1875!?PAYID=32100123Mysecretsig1875!?PM=CreditCard

Mysecretsig1875!?STATUS=9Mysecretsig1875!?



Condensé obtenu (SHA-1) :

209113288F93A9AB8E474EA78D899AFDBB874355

7.4 Requête de réponse directes (après paiement)

Après le paiement, notre système peut envoyer une demande http à un URL défini par le marchand et transmettre les données de transaction.

Ce processus permet au marchand de mettre à jour sa base de données en y intégrant le statut de la commande, etc. et de déclencher un processus de « fin de commande » (si cela n’a pas encore été fait après une redirection). C’est aussi une autre façon de générer une réponse personnelle pour le client en cas de besoins particuliers (si cela n’a pas encore été fait par le biais d’une redirection).

Notre demande http envoyée vers votre URL d’après paiement contiendra les mêmes paramètres d’informations que ceux décrits au chapitre Paramètres du retour d'information.

7.4.1 URL d’après-paiement

Si vous souhaitez automatiser vos tâches administratives, vous pouvez définir les URL de deux pages exécutables sur votre site sous l’onglet « Retour d’information sur la transaction », dans la rubrique « Requête directe http serveur-à-serveur » (champs URL) de la page d’information technique:

  • Vous pouvez par exemple indiquer l’URL sur lequel vous recevez les paramètres dans une demande lorsque le statut du paiement est accepté, en attente ou incertain.
  • L’autre URL sera par exemple celui sur lequel vous souhaitez recevoir les paramètres dans une demande lorsque la transaction a été annulée par le client ou refusée trop de fois par l’acquéreur (c.-à-d. plus que le nombre de tentatives de paiement autorisé, tel que défini sous l’onglet « Paramètres de transaction globaux », dans la rubrique « Tentatives de paiement multiples » de la page d’information technique).

Ces deux URL peuvent être différents, mais ils peuvent aussi être identiques. Vous pouvez aussi saisir un URL pour le premier cas et aucun pour le second.

N’indiquez aucun port dans votre URL ; nous n’acceptons que les ports 443 et 80.

URL d’après-paiement variables pour plusieurs shops

Si vous avez configuré une page d’après-paiement sur la page d’information technique de votre compte, mais que vous disposez de plusieurs boutiques qui sont chacune connectée à un répertoire déterminé pour recevoir les informations d’après-paiement, vous pouvez rendre une partie de votre URL d’après-paiement variable.

Cette partie variable peut aussi servir, par exemple, à « adapter » la demande d’informations pour inclure des informations sur la session, en les faisant passer comme une partie de l’URL plutôt que comme un paramètre supplémentaire. C’est le cas pour les plateformes Intershop ou les systèmes Servlets.

Le champ masqué à utiliser est le suivant :

<input type="hidden" name="PARAMVAR" value="">

Exemple:

URL d’après paiement sur la page d’information technique du marchand :
https://www.yourwebsite.com/<PARAMVAR>/yourpage.asp

Le champ masqué supplémentaire envoyé par le marchand est le suivant :
<input type="hidden" name="PARAMVAR" value="shop1">

Ce qui donne l’URL d’après paiement suivant pour la transaction :
https://www.yourwebsite.com/shop1/yourpage.asp

Important: Ne pas utiliser de caractères spéciaux dans le champ de PARAMVAR, car ils seront codées URL, ce qui pourrait créer des liens non valides..

7.4.2 Plannification de la requête d'informations

Sous l’onglet « Retour d’information sur la transaction », dans la rubrique « Requête directe HTTP serveur-à-serveur » de la page d’information technique de votre compte, vous pouvez définir le moment où la requête contenant les informations doit être envoyée :

  • Aucune :

    Le marchand ne peut choisir cette option car il est obligé de recevoir les requêtes serveur-serveur
  • Toujours différée (pas immédiatement après le paiement) :

    La requête contenant les informations est envoyée peu de temps après la fin du processus de paiement. Elle est alors une tâche de fond et ne peut pas servir à envoyer des informations personnalisées au client sur le site du marchand.

    Lorsque le marchand n’utilise pas sa page d’après-paiement pour définir une réponse personnalisée à envoyer à son client, il peut recevoir la requête contenant les informations en arrière plan et de façon différée.
  • Toujours en ligne (immédiatement après le paiement pour pouvoir personnaliser la réponse affichée pour le client) :

    La requête contenant les informations est envoyée « en ligne » entre le moment où notre système reçoit la réponse de l’acquéreur et le moment où il informe le client du résultat du paiement.

    Dans ce cas, le processus de paiement est plus long pour le client, mais le marchand peut envoyer une réponse personnalisée au client.

    L’inconvénient du processus d’information en ligne après paiement est que le système du marchand risque d’être compromis en cas de demandes trop nombreuses envoyées à sa page d’après-paiement (par ex., un volume de transactions par minute important) – cela peut entraîner des temps de réponse longs avant que le client ne reçoive les informations à l’écran.
  • En ligne mais passage par intervalles à une demande différée en cas d’échec des demandes en ligne :

    Cette option permet aux marchands qui ont besoin d’informations d’après-paiement en ligne (afin de personnaliser la réponse affichée au client) de disposer d’une option de repli en cas d’échec de la demande en ligne sur leur page d’après-paiement. Dans ce cas, nous effectuons un nouvel essai de demande d’informations toutes les dix minutes (maximum quatre fois) (différé). Cela permet au marchand d’éviter de passer à côté des informations de transaction en cas d’échec de la demande en ligne d’informations après-paiement en raison, par ex., de problèmes de serveur temporaires de son côté. Notre système affichera des informations standard sur la transaction pour le client (voir Réaction par défaut).

7.4.3 Réponse envoyée au client

Nous utilisons l’éventuelle réponse contenue sur votre page d’après-paiement pour afficher les informations (à la fin de la page de transaction) pour votre client.

Si votre page d’après-paiement répond au moyen : d’une page HTML (contenant une balise <html>) ou d’une redirection (HTTP 302 Object Moved), notre système envoie cette page HTML « telle quelle » au navigateur du client ou effectue la redirection, plutôt que de rediriger votre client au terme de votre processus d’informations après-paiement vers l’un des quatre URL que vous aurez éventuellement envoyés dans les champs masqués (ACCEPTURL, EXCEPTIONURL, CANCELURL et DECLINEURL, tels que décrits au chapitre Redirection depending on transaction result).

Vous pouvez aussi, si vous n’utilisez aucune des options mentionnées plus haut pour communiquer les informations à votre client, programmer votre page d’après-paiement pour répondre par quelques lignes de texte (pas de balise <html>) que nous intégrerons dans notre réponse standard, ou notre système se contentera d’afficher la réponse standard (comme indiqué au chapitre Réaction par défaut)

7.4.4 Requête http pour les changements de statut

Si vous souhaitez aussi recevoir une demande http différée en cas de changement de statut d’une transaction, vous pouvez indiquer un URL supplémentaire dans le champ sous l’onglet « Retour d’information sur la transaction », dans la rubrique « requête http les pour changements de statut » de la page d’information technique (et sélectionner une planification pour la demande).

Ce processus est similaire aux URL d’après-paiement, à la différence qu’il convient pour les processus d’arrière-plan éventuels.

Vous pouvez utiliser le même URL ici que celui défini dans la rubrique « Requête directe HTTP serveur-à-serveur  », mais rappelez-vous qu’il est vain de l’utiliser pour générer une réponse personnelle pour le client dans ce cas (arrière-plan).

7.5 Paramètres du retour d'information

Lorsqu’un paiement est exécuté, nous pouvons envoyer la liste de paramètres suivants:

Paramètre Valeur
ACCEPTANCE Code d’acceptation produit par l’acquéreur
amount
Montant de la commande (pas multiplié par 100)
BRAND
Marque de la carte (notre système se base pour cela sur le numéro de carte)
CARDNO
Numéro masqué de la carte
CN
Nom du titulaire de la carte/client
currency
Devise de la commande
ED
Date d’expiration
NCERROR
Code d’erreur
orderID
Votre référence de commande
PAYID
Référence du paiement dans notre système
PM
Moyen de paiement
SHASIGN
Signature SHA calculée par notre système (si configuré sur SHA-OUT)
STATUS
Statut de la transaction
TRXDATE
Date de la transaction

Exemple (GET request):

https://www.yourwebsite.com/acceptpage.asp?orderID=ref12345&currency=EUR&amount=25&PM=CreditCard&ACCEPTANCE=test123&STATUS=5&CARDNO=XXXXXXXXXXXX1111&PAYID=1136745&NCERROR=0&BRAND=VISA&ED=0514&TRXDATE=12/25/08&CN=John Doe

La liste des paramètres des informations peut être plus longue pour les marchands qui ont activé certaines options dans leurs comptes, comme le module de détection de fraude. Veuillez vous reporter à la documentation sur l’option concernée pour de plus amples informations sur les autres paramètres des informations liés à l’option.

7.5.1 Paramètres du retour d'information dynamiques

Vous pouvez également choisir quels paramètres sont envoyés avec la requête post-paiement. Pour faire ceci, rendez-vous dans l'onglet "Retour d'information sur la transaction" de votre information technique. Il y a là une liste de paramètres "Disponible" et "Sélectionné".

Utilisez tout simplement les flèches entre les deux listes pour faire basculer les paramètres d'une liste à l'autre.

N'oubliez pas de mettre à jour votre signature SHA-OUT afin de tenir compte des paramètres indiqués ici. Les paramètres qui ne sont pas sélectionnés ne figureront PAS dans le calcul SHA.

 

7.5.2 Paramètres du retour d'information

Le marchand peut nous envoyer deux paramètres supplémentaires dans les champs masqués du formulaire de commande afin de les récupérer en tant que paramètres des informations au terme du paiement. Les champs masqués suivants sont proposés :

<input type="hidden" name="COMPLUS" value="">
<input type="hidden" name="PARAMPLUS" value="">

Champ
Objet
COMPLUS
Champ servant à soumettre une valeur que vous aimeriez récupérer dans la demande d’informations.
PARAMPLUS

Champ servant à soumettre certains paramètres et leurs valeurs que vous aimeriez récupérer dans la demande d’informations.

Le champ paramplus n’est  pas inclus dans les paramètres des informations proprement dits ; les paramètres/valeurs que vous soumettez dans ce champ seront en revanche analysés et les paramètres ainsi obtenus, ajoutés à la demande http.


Exemple

Les champs masqués supplémentaires envoyés par le marchand sont les suivants :

<input type="hidden" name="COMPLUS" value="123456789123456789123456789">
<input type="hidden" name="PARAMPLUS" value="SessionID=126548354&ShopperID=73541312">

Entraîne une redirection avec paramètres des informations :

https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]
&COMPLUS=123456789123456789123456789&SessionID=126548354&ShopperID=73541312 

7.6 Réinitialisation du retour d'information

Si la demande de redirection/retour d'information n'a pas été exécutée, du fait d'une action du client entraînant le blocage de nos pages de paiement sécurisé (par ex. si le client a cliqué sur le bouton « retour » de son navigateur), nous pouvons réinitialiser la demande de post-paiement et/ou la redirection. Ainsi, votre client sera redirigé vers la page que vous souhaitez afficher et vos bases de données pourront être mises à jour.

Pour activer cette fonction dans votre compte, allez dans Configuration > Information technique > Retour d'information sur l... > Général et cochez la case "Je veux que PostFinance relance le processus de fin de transaction (requête/redirection post paiement) si nécessaire."

Il est possible que vous receviez plusieurs demandes de post-paiement pour le même identifiant de commande. En effet, la demande de redirection/retour d'information sera renvoyée si le client revient aux pages de paiement sécurisé à l'aide du bouton « retour » après avoir été redirigé vers votre site web.

Veillez à configurer votre script « Post URL » de façon à traiter ces « exceptions ». Par exemple, vous pouvez configurer votre script « Post URL » de manière à créer une ligne dans votre base de données pour chaque état de transaction renvoyé et/ou générer un e-mail pour informer le marchand d'une « exception » par rapport aux étapes prévues dans le processus de transaction.

Nous vous recommandons de ne pas écraser le premier message d'état de transaction que vous recevez par un autre message reçu par la suite pour le même identifiant de commande. Idéalement, il est conseillé de conserver toutes les réponses pour chaque commande, et d'appeler un processus permettant de les analyser et de les traiter comme il se doit.

Si vous ne cochez pas la case, le client qui clique sur le bouton « retour » pour revenir aux pages de paiement sécurisé verra s'afficher un message indiquant que le paiement a déjà été traité.

7.7 E-mails de confirmation

7.7.1 E-mails envoyés au marchand

Notre système peut vous envoyer un e-mail de confirmation de paiement pour chaque transaction (une option à configurer sous l’onglet « E-mails de transaction », dans la rubrique « E-mails pour le marchand » sur la page d’information technique).

Vous pouvez aussi recevoir des e-mails vous informant des changements de statut des transactions.

7.7.2 E-mails envoyés au client

Notre système peut envoyer un courrier électronique automatique à votre client pour l’informer de l’enregistrement de la transaction. Il s’agit d’un message standard et vous ne pouvez pas en changer le contenu.

Vous pouvez activer cette option dans la section „E-mails pour le client“ de l’onglet „E-mails de transaction“ de la page Information Technique.

Vous pouvez également choisir d’envoyer au client un courriel lorsqu’une transaction est confirmée (capture de données) et remboursée en cochant les cases correspondantes. En tant qu’expéditeur (« From ») de ces courriels, vous pouvez configurer l’adresse électronique à utiliser dans les courrriels relatifs à la transaction (Adresse e-mail de support à insérer dans les e-mails relatifs aux transactions). Si vous n’indiquez pas d’adresse électronique ici, nous utiliserons la première adresse saisie sous "Adresse(s) e-mail pour les e-mails relatifs aux transactions" à la section "E-mails pour le marchand".

Pour pouvoir envoyer des courriels de confirmation à votre client, vous devez indiquer son adresse électronique dans le champ masqué :

<input type="hidden" name="EMAIL" value="">

Champ
Description
EMAIL Adresse e-mail du client