...
Après avoir traité le paiement, la plateforme de paiement notifie le résultat du paiement à la boutique. Pour ce faire, la plate-forme de paiement appelle URLNotify via HTTP POST. Il s'agit d'une communication entièrement distincte qui n'a rien à voir avec la connexion initiale entre le magasin, le client et la plate-forme de paiement. Les paramètres sont transmis dans le corps HTTP sous la forme d'une chaîne de paramètres cryptée par Blowfish. Le type de contenu est application/x-www-form-urlencoded; charset=iso-8859-1. Par conséquent, les valeurs standard pour l'analyse des formulaires HTML sont utilisées.
...
Si l'URLNotify de la boutique n'est pas accessible (par exemple, état HTTP 500/404), la notification est répétée 8 fois. Dans ce cas, le client transmet au magasin est avant la demande d'URLNotify. Par conséquent, le magasin doit analyser et comparer les deux messages d'état provenant d'URLNotify et de la transmission (URLSuccess, URLFailure).
Répétition | Temps d'attente | Temps après la première notification |
|---|---|---|
0 | Instantly | 0 |
1 | 00:01 h | 00:01 h |
2 | 00:08 h | 00:09 h |
3 | 00:27 h | 00:36 h |
4 | 01:04 h | 01:40 h |
5 | 02:05 h | 03:45 h |
6 | 03:36 h | 07:21 h |
7 | 05:43 h | 13:04 h |
8 | 08:32 h | 21:36 h |
Temps de répétition de l'avis respectivement calculé après la première tentative ratée.
...
Pour plus de détails, veuillez consulter le site : www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1
Synthèse des méthodes POST et GET utilisées lors de l'envoi de la notification du résultat du paiement
Paiements carte | Méthode POST (3DSV2) |
Moyens de paiement alternatifs | Méthode GET |