Cet article a pour but d'ouvrir le débat au sujet des APIs de paiement que les marchands doivent implémenter pour accepter les cartes Titres-Restaurant en e-commerce.
Tout d'abord avant de continuer la lecture de ce post nous vous invitons à lire
cet article. Après l'avoir lu (si vous m'avez suivi jusqu'au bout), vous comprenez maintenant que le sujet n'est pas simple.
Un certain nombre de nos clients restaurateurs nous ont remonté avoir été interpellés pour ne pas implémenter nos solutions Lyra (PayZen & Lyra Collect) avec comme arguments:
- Edenred a le monopole du marché
- L'API d'Edenred est Plug&Play
- C'est simple comme un bonjour.
Le monopole:
Tout d'abord, même si Edenred est une entreprise avec une part de marché importante en France (environ 1/3 du marché), il existe 3 autres émetteurs de Titres-Restaurant: Natixis intertitres, Sodexo et UP qui présentent donc 2/3 du marché.
Et nous pouvons nous féliciter d'avoir 3 champions internationaux: Edenred, Sodexo et UP.
Natixis Intertitres (qui est notre fournisseur chez Lyra) reste une entreprise franco-française sans ambition internationale à ce jour.
Ces 3 champions internationaux ont su adapter leur système d'information aux règles locales de tout type de bénéfices salariés soit par du développement local dans les pays où ils opèrent, soit par de la croissance externe. Edenred a par exemple racheté récemment Good Card au Brésil. Ces 3 entreprises sont des champions français en Amérique latine, en Inde, en Europe...
Lyra offre une solution permettant de couvrir toutes les cartes Titres-Restaurant MasterCard, Visa et Conecs de tous les émetteurs. Des propres dires d'Edenred, cela représente déjà actuellement 85% de leurs cartes en circulation et bientôt 100% quand toutes leurs cartes seront hybrides. (à la fois Mastercard et Conecs). Quant aux autres émetteurs, cela représente déjà 100% de leurs cartes.
Donc en implémentant uniquement l'API d'Edenred, vous vous rajoutez du travail d'intégration (cf ci-dessous), vous vous privez des 3 autres émetteurs ainsi que d'un accès à près de 100% du marché des cartes Titres-Restaurant actuellement en service.
Dans le cas de l’API Edenred :
Toute l’analyse et les développements associés spécifiques aux cartes Titres-Restaurant sont laissés à la charge des e-Commerçants dont le métier n’est pas le paiement (exemple du paiement complémentaire, du redressement,…).
L’API Edenred ne gère que les cartes d'Edenred et ne gère pas les cartes des 3 autres émetteurs (2/3 du marché). Il faudra donc faire des développements complémentaires pour intégrer les autres émetteurs.
L’API Edenred n’est donc pas plug and play
mais génère en réalité beaucoup plus de travail et plusieurs intégrations pour un accès à une part minoritaire du marché des Titres-Restaurant contrairement au solution Lyra.
Plug & play:
Documentation
Lyra met beaucoup d'énergie à fournir ses documentations en 4 langues. Nous nous respectons les cultures locales et considérons que tout le monde ne lit pas l'anglais. Donc nos clients français trouveront une documentation en français et aussi en anglais pour intégrer les cartes Titres-Restaurant. Pas seulement en Anglais.
L'API de Lyra travaille une signature. Cela sert à quoi?
A vérifier que les données postées ne sont pas altérées par l'acheteur depuis son navigateur.
Dans le cas d'Edenred, il n'y a pas ce type de contrôle. Nous vous invitons à contrôler que le montant renvoyé dans ce qu'ils appellent l'url de webhook est bien le montant de l'aller. A noter que toutes les plateformes de paiement parlent plutôt d'IPN (instant payment notification) et pas de webhook.
Comme l'IPN (le webhook) est un processus critique, Lyra a mis en place des mails d'alerte en temps réel lorsqu'elle est en échec (et oui nos chers marchands ont des serveurs qui ne répondent pas toujours) et en cas d'échec nous savons activer un procesus de rejeu automatique.
Il nous semble que rien de cela n'existe dans l'IPN (webhook) d'Edenred.
Lyra permet de faire un traitement sur l'url de retour (celle qui est appelée quand on clique sur le bouton retourner à la boutique) et qui contient les mêmes paramètres que l'IPN.
Dans le cas d'Edenred, nous ne savons pas car ce n'est pas bien documenté. On sait juste que cela renvoie success ou failure. Donc l'usage du contrôle de l'IPN est obligatoire entre autre à cause du contrôle sur montant!
Imprécisions
J'aime bien relire nos documentations avant publication car je n'aime pas qu'on nous pose des questions en cas d'imprécision. Il est possible d'appeler l'API d'Edenred en précisant la langue du client et même en définissant la spécificité locales (français de France versus français du Canada par exemple)
Il est important de pouvoir parler de carte restaurant, de carte à bouffer ou de carte à grailler. (et pas à gratter. On n'est pas à la française des jeux)
- L'exemple donné dans la définition du paramètre est fr-FR.
- L'exemple donné dans l'exemple de code est fr-fr.
C'est peut-être pareil. Je n'ai pas été vérifié. Mais c'est imprécis.
La devise suit l'iso 4217. Mais il faut aller voir l'exemple de code pour savoir qu'il faut passer EUR.
Car l'iso 4217 peut être numérique ou alphanumérique. Là encore c'est imprécis.
Simple comme un bonjour:
Cette API permet d'accepter toutes les cartes Edenred. Cela ne fait aucune doute.
Mais en cas de solde insuffisant, elle ne permet pas de proposer un complément de paiement avec un autre moyen de paiement au client. Moyen de paiement qui peut-être un autre Titre-restaurant ou une carte de paiement (CB, Visa, AMEX, ..)
L'argument qu'Edenred présente contre Lyra est que cela ne sert à rien car 95% des paiements n'ont pas besoin de complément.
Qui a envie de perdre 5% du chiffre d'affaires?
Par ailleurs l'API renvoie un état pending.
Soit c'est accepté en temps réel, soit c'est refusé. Mais que fait-on du pending?
Il n'existe en plus aucune API pour aller vérifier l'état final et éventuellement l'annuler en cas de changement d'état.
Les solutions de Lyra sont simples car ils permettent d'accepter tous les émetteurs (sauf les cartes 2ème génération non hybride d'Edenred via Conecs, mais elles sont minoritaires).
Lyra permet de gérer le paiement du solde restant à payer en cas de solde insuffisant sur la carte Titres-restaurant.
Et comme les nouvelles cartes 2ème génération sont désormais des cartes mixtes / Hybrides (première génération et 2ème génération), elles seront acceptées sur le contrat d'acceptation CB. Ce qui laisse un peu de boulot à Edenred pour aller chercher sa commission d'interchange chez le marchand.
On laisse donc juger les e-commerçants restaurateur s'il y a lieu de faire une double intégration ou de faire confiance à Lyra.
Car Lyra supporte bien sûr CB, Visa, MasterCard mais aussi Amex, Diners, Discovery, JCB, le Wallet de Google Pay, les cartes Cora, etc...
Donc pourquoi développer 2 fois?
Moi j'ai choisi mais je ne suis pas impartial.
😉
Souvent les marchands souhaitent faire apparaître le nom de leur enseigne plutôt que le nom de leur société sur le relevé de leurs acheteurs lors d'un paiement carte.
