Intégrer FacilyPay by Oney sur du Magento : un conseil FUYEZ !

nov 04, 2015
KaipiYann

Je n’écris pas souvent pour partager mes découvertes ou  dernières astuces de code que j’ai utilisé, mais là, je ne pouvais pas sereinement garder cette expérience pour moi tant il me semble important que toi, développeur Magento (ou Prestashop) qui vient de tomber sur cette article, saches à quoi t’en tenir si tu souhaites intégrer le paiement en plusieurs fois FacilyPay by Oney sur le site Magento de ton client.

En effet, cela fait un peu plus de 8 ans que je développe des sites, j’ai commencé à faire du Magento quand le projet était encore en version béta, et pourtant depuis tout ce temps je n’avais jamais vu une solution aussi pénible à mettre en place et un process aussi absurde pour avoir le « privilège » d’utiliser leur solution.

Le lancement

Dès le début du projet il faut s’accrocher parce que tout est compliqué…Mon client avait pris contact avec FacilyPay by Oney pour demander à intégrer leur solution. Il voulait dans un premier temps juste avoir des infos sur l’intégration pour que je puisse évaluer la complexité de l’intégration. Il aura donc fallu que mon client signe un accord de confidentialité, puis signe les contrats d’adhésion (qu’il fallait renvoyer par courrier bien entendu), puis complète des tableaux excel incompréhensibles, pour enfin recevoir un guide technique en PDF. Pourquoi est ce que la documentation technique est si secrète ? On se demande.
Nous avons donc reçu la documentation technique pour Java au lieu de celle de Php mais il ne m’aura pas fallu bien longtemps à lire la doc pour me rendre compte que la solution FacilyPay by Oney est loin, très loin, je dirais même dans une galaxie très lointaine, de l’API Rest pourtant assez standard aujourd’hui… nous y reviendrons plus tard.

Après quoi mon client a reçu un premier mail détaillant le processus d’installation de la solution…et maintenant que j’y repense dès cet email nous aurions du fuir ! En gros l’ingénieur commercial, qui n’a sans aucun doute d’ingénieur que le nom, nous explique les étapes :

- Intégration Technique : L’équipe de déploiement doit envoyer un kit de qualification pour pouvoir intégrer.
- Qualification : L’équipe de déploiement va nous donner des scénario de tests techniques et opérationnels à effectuer. Ca c’est l’étape la plus sympa !
- La mise en avant : Oney explique que pour BOOSTER ton chiffre d’affaire il faut bien mettre en avant Oney…parce que le client trop pauvre pour acheter tes produits il faut lui dire le plus tôt possible qu’il peut payer à crédit ! Bah oui… Et on te dit surtout qu’on te donnera donc les préconisations marketing de mise en avant.
- La formation : Oney va former les équipes à utiliser leurs outils de back office…Là aussi on aurait dû penser que si il y a besoin de se former c’est surement que c’est pas tout à fait intuitif comme interface…mais bon c’est pas moi qui m’en servirai après tout !
- La mise en ligne : Une fois que tout sera validé tu recevra le kit de Production…le GRAAL quoi !

Pas mal d’étapes dans l’intégration, mais surtout notre ami l’ingénieur commercial, nous explique qu’il faut faire un conf call d’environ 1h pour expliquer le processus et qu’il faut leur dire quand est ce que l’on va pouvoir effectuer l’intégration technique…Donc tu as déjà passé 1h à lire leur process par email mais ca ne suffit pas ! On t’explique que de toutes façons tu ne peux pas  démarrer avant d’avoir fait ce call, sans quoi tu ne reçois pas le kit d’intégration. On t’explique également qu’ il faut réserver un SLOT comme ils disent chez Oney, c’est à dire donner une estimation de quand tu vas finaliser l’intégration, parce que tu ne peux pas ennuyer le service Deploiement quand tu veux ! Quand je vous dit que c’est une privilège de pouvoir utiliser leur solution !

Je reçois alors le premier mail de l’ingénieur commercial qui se permet de me tutoyer dès le premier mail, alors qu’il ne me connait ni d’Eve ni d’Adam, mais c’est sans doute pour donner à FacilyPay by Oney un côté StartUp, jeune et cool….Celui-ci souhaite fixer le rendez-vous téléphonique le « Welcome Rendez-Vous » comme ils disent…et au bout de 3 jours on m’appelle sur mon téléphone parce que je n’ai pas répondu assez vite à leur gout..

Toujours est il que j’arrive enfin à me dégager du temps afin de regarder les docs qu’ils m’ont envoyés dans Basecamp et à fixer ce fameux rendez vous téléphonique obligatoire.
Alors pour intégrer j’ai donc reçu :

  • Un PDF du Guide Technique (celui du php cette fois…), 46 pages
  • Un PDF des préconisations de mise en avant, 44 pages
  • Un PDF sur la personnalisation graphique de leur formulaire, 18 pages
  • Un PDF d’explication générale sur les flux d’info, 5 pages…(c’est tellement pas clair leur flux qu’ils ont dû produire un PDF spécifique pour essayer de donner une explication cohérente).
  • Des zips contenant tout un tas de trucs graphiques, des logos, des bulles d’aide, des pictos…

Bref tu n’as pas encore commencé que déjà c’est une galère, tu as téléchargé 78Mo de docs  et perdu déjà quelques heures…
Ceux qui connaissent Stripe (ou équivalent) savent de quoi je parle quand je parle de simplicité d’intégration, je l’ai d’ailleurs dit à l’ingénieur commercial mais il n’était manifestement pas en capacité de comprendre de quoi je parlais et m’expliqua que c’est normal parce que chez FacilyPay il y a un système anti-fraude extraordinaire…bien entendu la réponse n’a rien à voir avec ma remarque, ce n’est certainement pas parce qu’un système est complexe qu’il doit être complexe à intégrer pour les clients ! A croire que chez FacilyPay by Oney personne a dû regarder ce que font les startups du paiement en ligne… pourtant Stripe c’est tout de même valorisé 5 milliards de $ au bout de 4 ans…juste parce qu’ils ont fait simple eux, ca devrait donner des idées !

L’intégration

Après avoir eu le call j’ai donc enfin pu commencer à bosser à l’intégration de Oney dans Magento. J’avais reçu la lib php qui permet de simplifier les appels à FacilyPay…Au premier coup d’oeil on voit que le code a été réalisé soit il y a 20 ans soit par un mauvais dév…mais fournir des fichiers php encodés en Windows 1252 c’est déjà assez pathétique non ou bien ils pensent que je vais faire tourner mon php sur un serveur windows ? Evidement pas de namespace, des fonctions avec des listes de 10 paramètres dont certain ne servent à rien puisqu’il faut mettre à chaque fois des constantes…Bref on dirait le code que j’écrivais il y a 15 ans !

Je réalise donc mon module de paiement FacilyPay pour Magento, en suivant bien la documentation qui n’est pas toujours très claire et qui est même quelque fois assez surprenante par exemple quand on t’explique qu’il est vivement conseillé de mettre en cache les résultats qu’ils te servent pour les simulations de crédit…Est-ce si compliqué que ca pour Oney de tenir la charge ? Comme si Google te demandais de pas faire de recherches trop rapprochées sur leur site.
Une fois le module réalisé et déjà pas mal testé je me prépare à finaliser. Je dois donc personnaliser un peu aux couleurs de mon client le formulaire FacilyPay sur lequel le visiteur du site sera envoyé pour finaliser son crédit. J’envoie donc le logo en gif comme demandé et à la bonne taille…et là on me répond qu’il faut un Gif transparent…Moi justement je voulais pas un Gif transparent parce que je voulais pas que le logo bave sur leur fond dégradé dégeu. Et techniquement un gif  transparent ou non cela ne change strictement rien et puis tout le monde sait que dans ce cas on utilise plutôt un PNG depuis 10 ans environ… chez Oney ils savent ptet pas encore que ça existe le PNG ? Je décide donc de leur renvoyer leur pack complet de style en l’ayant personnalisé et là on me répond que j’ai dû créer mon zip sur un mac et qu’ils n’arrivent pas à l’ouvrir….Jamais entendu ça non plus pourtant j’en ai envoyé des zip.

Je laisse donc tomber la personnalisation de l’interface et passe aux tests de qualification. Moi personnellement c’est la première fois que je vois un truc pareil, la logique voudrait que je test mon code en effectuant quelques test pour être sur que tout se passe bien jusqu’à chez Oney puisqu’il n’est pas dans mon intérêt de mettre en ligne un module qui bug le site de mon client. Par exemple chez Paybox et d’autres que j’ai installé, si tu as réussi à aller jusqu’à la transaction ils te laissent passer en production. Bah chez Oney c’est beaucoup beaucoup plus compliqué que ca ! On te donne un fichier Excel (encore un doc à télécharger, on aura utilisé tout le pack office !), dans lequel tu trouves des test à effectuer, par exemple voici une des indications données :

« Adresse de facturation ≠ adresse de livraison / montant de la commande contient des décimales
Civilité = madame –> nom de jeune fille obligatoire lors de l’affichage du formulaire »

J’effectue donc les tests demandés en faisant bien attention à mettre des données un peu compliquées avec des accents ou des caractères spéciaux, des nombres à virgule pour être sûr que tout se passe bien…je passe mes tests avec succès et informe l’équipe Deploiement. Réponse de l’équipe le lendemain : Il faut refaire les tests parce que mes données ne sont pas assez proche de la réalité…On me reproche donc par exemple d’avoir fait un test avec Mlle Yann René…Mais alors pourquoi ne pas m’envoyer carrément les données que je dois mettre dans le test ce serait plus simple non ? En en fait je pense qu’il faut comprendre que ces tests obligatoires ne servent pas à savoir si mon code envoie bien les données à Oney comme il faut mais ils servent à savoir si Oney arrive bien à traiter les données reçus…en gros ils testent leur système à eux ! D’ailleurs à plusieurs reprises je n’ai pas pu tester non plus parce que la plateforme de test n’était pas disponible. Mais Oney qui a toujours une bonne explication m’a rétorqué que :

l’accessibilité de la plateforme de recette est  »garantie » de 8h à 18h00 (hors incidents ou interventions planifiées). En dehors de ces heures, la plateforme peut être instable.

D’accord donc en gros chez Oney même les systèmes informatiques sont aux 35h !
Enfin Oney m’explique également qu’un des tests n’est pas valable parce que je n’ai pas envoyé les bonnes données alors que j’avais envoyé exactement ce qui était demandé dans leur doc…chez Oney même la doc de contient des erreurs !

einstein_2_things

Dans un premier temps j’ai refusé de refaire ces tests n’ayant pas vraiment de temps à perdre, mais c’était sans compter sur leur obstination à ne rien vouloir entendre…Ils ont été jusqu’à dire à mon client que le contrat était rompu, ils ont donc rien à faire de leur client ! Forcement quand je me retrouve à devoir expliquer en conf call à 5 personnes de différents services pourquoi je ne souhaite pas refaire les tests quand tout fonctionne et qu’il essayent de me donner des explications qui n’ont aucun sens pour essayer de justifier ce process stupide, ca m’agace. Ils auraient pu faire les tests qu’ils voulaient eux même puisqu’ils avaient accès…mais ils ont préféré faire un conf call à 5, puis ont menacé leur client de rompre le contrat !

Ils me forcent donc à refaire tous les tests alors que je sais très bien que de mon coté tout fonctionne très bien mais contrairement à eux moi je ne vais pas laisser tomber mon client. N’ayant pas que ça à faire non plus que des repasser vraiment 3 commandes complètes dans Magento surtout au risque de mettre encore des données pas assez réelles à leur goût, j’écris un mini script qui me permet d’envoyer en une ligne de commande les données qu’ils veulent recevoir…Absurde donc puisqu’en vrai je n’ai rien testé du tout de mon coté j’ai juste utilisé leur lib pour leur envoyer des données…et pourtant cette fois enfin ils ont validé !

Après quoi c’était au tour d’un autre service de vérifier ce que nous avions fait le département Marketing…bah oui parce qu’en fait Oney t’explique qu’ils te donnent des « recommandations de mise en avant » mais c’est en fait des obligations de mise en avant. Nous avions donc mis Oney uniquement sur la page des Checkout du site et un petit logo dans le footer à coté des logos des cartes bleues. Mon client ayant une image plutôt haut de gamme il ne souhaitait pas transformer son site en site discount. Nous en avions parlé dès le début bien expliqué que nous ne souhaitions pas que cela soit trop présent dans le site mais au final Oney a en fait imposé la présence sur toutes les page produits d’un picto pour signifier la possibilité du paiement en plusieurs fois. Ils ont également imposé un lien complètement absurde sur le logo du footer pour envoyer vers les CGU…alors qu’il y a un vrai lien juste à coté avec écrit CGU. Est ce qu’on peut me dire quel internaute va aller cliquer sur ce logo ? Surement personne à part chez Oney pendant leur test…

Bref après tout ça et donc un peu plus de 2 mois de galère la solution est enfin en production. Je pense que j’aurais pu mettre en ligne au bout de 6 jours mais on a perdu un temps incroyable à cause de ce process rigide, de leurs exigences absurdes et d’un trop grand nombre d’interlocuteurs.
Je n’ai pas étudié toutes les solutions de paiement en plusieurs fois qui existent sur le marché mais ce dont je suis sûr c’est qu’il est absurde de devoir passer autant de temps sur l’intégration d’une solution de paiement. Préférez au moins une solution capable de vous fournir un module pour Magento (ou Prestashop), par exemple la solution de Franfinance (que j’ai trouvé trop tard malheureusement), mais qui vous permettra surement d’éviter de devoir faire de nombreux test.
En tous cas je vous aurai prévenu, évitez FacilyPay by Oney !

 

Aucun commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>