Je viens de terminer l'intégration d'une solution de paiement en ligne pour un client. Comme celui-ci possédait déjà un compte à la Banque Nationale du Canada, la solution retenue fût celle du fournisseur Global Payments auquel elle est affiliée.
Avant d'amorcer le travail, j'ai eu à communiquer avec Global pour ouvrir un compte sandbox afin de faire des tests de programmation et simuler les transactions. Pour obtenir des renseignements et la documentation technique, j'ai eu à laisser un message à trois personnes dont seule la dernière retourna mon appel.
Le vendeur qui m'a rappelé n'avait aucune notion technique et se préoccupait davantage me promouvoir les différents services plutôt que de répondre à mon besoin. Au bureau
de Global Payments au Québec, je me suis fait dire par une autre employé que le seul technicien qui pouvait m'aider était en vacances et que je devais attendre son retour(!). Lui non plus n'a pas donné suite à ma requête.
C'est si difficile d'obtenir une réponse facilement ? J'ai donc poussé ma chance plus loin et je crois m'être retrouvé à parler à quelqu'un au bureau régional en Ontario qui m'a dit d'envoyer un courriel au support technique, puis j'ai échangé des communications avec des gens de l'entité GlobalPay (selon l'adresse courriel) pour enfin obtenir l'accès par
l'intermédiaire d'une autre entité nommée CRESecure située à Atlanta aux États-Unis... C'est vrai que c'est la période de l'année où débute la série Mondiale de baseball mais ce n'est pas une raison pour que tout le monde se relance la balle.
Je croyais que mes ennuis s'arrêteraient là mais non. Lors de la phase de développement, j'intégrais la solution nommée SecureForm qui permet à un hébergeur qui n'a pas de certification PCI (Payment Card Industry) de déléguer la responsabilité de saisir les informations de la carte de crédit à une passerelle hébergée chez un fournisseur accrédité comme Global Payments, sans jamais que le site marchand ne manipule le numéro de la carte de crédit sur ses serveurs.
Or la documentation m'a fait rager car elle comporte son lot d'erreurs. Par exemple, à la page 36 de 55 du document PDF Global Transport Secure Form Implementation Guide v.1.pdf, sous la section intitulée Global Transport Secure Direct Services, j'ai compté trois erreurs techniques. La dernière révision date pourtant de juillet 2013...
À titre de référence, voyez la capture ci-dessous.
 | |
| Cliquez pour agrandir |
Erreur # 1 : URL de l'environnement de développement (sandbox)
 |
| Cliquez pour agrandir |
Pour valider une transaction auprès de Global, on prend la peine d'indiquer explicitement une note comme quoi l'URL à appeler ne doit pas se terminer par une barre oblique lorsqu'on est en mode test. Jusqu'à ce que je me rende compte par Fiddler que Global a eu la brillante idée de faire une redirection 301 vers la nouvelle URL qui comprend le slash...
Erreur # 2 : GET ou POST ?
 |
| Cliquez pour agrandir |
La validation doit se faire par une requête POST. Est-ce que je rêve ou l'exemple montre une requête GET ? Après tests, je confirme que la méthode à utiliser est bien un POST.
Erreur # 3 : Paramètre de validation
 |
| Cliquez pour agrandir |
Celle-ci est la pire de toutes car elle n'est pas évidente à trouver mais j'ai pu la déduire. Alors que la requête de validation ne fonctionnait pas, j'avais remarqué que les noms des paramètres ne suivaient aucun standard de nommage, passant du camelCase (CRESecureId) à l'underscore (total_amt). Après avoir bidouillé un peu et essayé de comprendre pourquoi le paramètre orderId n'était pas pris en considération (validation échouée), je me suis risqué à renommer le paramètre passé à order_id pour voir, juste au cas-où. Et ça s'est mis à fonctionner à merveille.
Une fois tout le processus fonctionnel, je me suis dit que j'allais leur rendre service en leur adressant un courriel pour communiquer les erratums du document. La réponse que j'ai reçu m'invita à m'adresser à un autre département.
Come on Global Payments, c'est quoi ce niaisage ?
Bonjour,
Puisque selon ton billet la manière d'écrire la requêtes POST dans la documentation n'est pas bonne, comment est-ce qu'elle aurrait du être écrite?
Je pose la question, car j'ai eu moi aussi à écrire de la documentation sur une requête POST et c'est exactement la manière dont je l'ai écrite.
En PHP, lancer un post avec CURL.
Si la page qui traîte la requête est en PHP, ça va fonctionner autant avec un GET que POST si on récupère les paramètres avec $_REQUEST plutôt que $_POST.
En fait, il aurait dû être écrit que les paramètres doivent être passés dans le corps (body) de la requête POST et encodés sous forme URL (clé=valeur&clé=valeur). L'URL quant à lui aurait dû être totalement dépourvu de paramètre query string.
Généralement, lorsqu'on travaille en PHP, avec l'extension curl, on peut passer un tableau associatif $clé => $valeur de cette façon :
$formbody = array('key1' => 'value1', 'key2' => 'value2');
curl_setopt($ch, CURLOPT_URL,"http://www.example.com/index.php");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($formbody ));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$server_output = curl_exec($ch);
Anecdote sympa qui illustre bien le travail "caché" du développeur.
9 fois sur 10, ça consiste à travailler sur les 'merdouilles' des autres ou a poser des rustines.