Comprendre le paiement sur le web

Tâchons de comprendre un peu mieux comment se déroule un paiement sur le web. Vous allez voir, ça ne fait pas trop mal. Sachez qu'accepter un paiement en ligne nécessite deux choses :

D'abord, un contrat de vente à distance (VAD) à conclure auprès d'une institution financière (une banque, donc) et qui donne le droit d'encaisser des sommes pour des paiements réalisés à distance (sur un site web, dans notre cas). C'est cette banque qui, via le réseau des institutions financières, communiquera avec la banque du client, et transfèrera la somme payée sur votre compte marchand. On parle d'acquéreur.

Ensuite, un terminal de paiement électronique (TPE) qui permet à nos clients de saisir leurs informations de paiement. Dans notre cas, notre TPE sera virtuel, et peut être constitué d'un simple formulaire. On appelle ça une passerelle de paiement. La passerelle de paiement est responsable de la communication entre votre site marchand, le client et les institutions bancaires, applique différents filtres destinés à prévenir la fraude, et fournit différents services tiers au marchand. On parle de collecteur.

La plupart du temps, les banques qui vous proposent des contrat VAD fournissent une passerelle de paiement basique, mais il est également possible de passer par un prestataire tiers qui assure cette fonction et communique directement avec votre banque. Parmi ces prestataires, Ogone, Atos, Paybox, etc.

Les avantages de passer par une passerelle tierse sont multiples : pouvoir personnaliser sa page de paiement, disposer d'une interface et de rapports plus complets, possibilités plus ou moins avancées de remboursement des transactions, avoir accès à un support plus réactif, proposer des moyens de paiement alternatifs, gérer les paiements récurrents, avoir un système anti-fraude plus avancé, etc.

Notez qu'obtenir un contrat VAD n'est pas forcément facile, les banques étant généralement assez frileuses et peu enclines à distribuer leur confiance à des nouvelles entreprisees. Notez également que les coûts d'activation ne sont pas négligeables ; la mise en place peut coûter plusieurs centaines d'euros, plus un abonnement mensuel, plus une commission sur chaque transaction. Ça reste la solution la plus avantageuse lorsqu'on traite de gros volumes de paiements.

Paiements online sans contrat de vente à distance

La souscription d'un contrat VAD, qui nécessite de débourser des centaines d'euros, batailler avec des banquiers et remplir moult paperasse n'est pas vraiment compatible avec la mise en production rapide d'un MVP. Sans parler de l'implémentation de la solution technique de la passerelle de paiement sélectionnée ; d'expérience, elles sont toutes plus tordues les unes que les autres. D'ailleurs, rien qu'à voir leurs sites calamiteux, on se doute bien que ces gens ne tournent pas rond.

Il existe une solution alternative qui permet de se passer de contrat VAD : il s'agit de requérir les services d'un prestataire qui servira de proxy entre le système de paiement et vous. Le plus connu de ceux là étant bien entendu Paypal.

Paypal fournit une passerelle de paiement, mais à l'issue de la transaction, l'argent n'est pas déposé sur votre compte marchand, mais bel et bien sur le compte de Paypal. En gros, votre client paie Paypal, et Paypal vous paie ensuite, vous dispensant du fameux contrat de vente à distance.

L'utilisation de Paypal (ou l'une de ses alternatives) peut présenter quelques avantages. La création d'un compte est beaucoup moins contraignantes, et les coûts d'initialisation sont nuls.

En revanche, les inconvéniants sont nombreux. D'abord, les frais de transaction sont plus élevés. Ensuite, la solution est techniquement loin d'être simple à mettre en œuvre, et ni le site labyrinthique ni la documentation cryptique n'y améliorent quoi que ce soit. Et puis, Paypal est mondialement (et tristement) célèbre pour disposer d'un support client exécrable, et régulièrement cloturer des comptes sans vraies raison valables. Or, tant que votre argent durement gagné n'aura pas été viré sur votre compte banquaire, l'épée de Damoclès pendouillera au dessus de votre tête.

Ah, j'oubliais : le formulaire de paiement est moche, long comme le bras et anti-ergonomique au possible. De quoi faire augmenter en flèche votre taux d'abandon de panier.

Et si vous disiez adieu à vos clients ?

Notez que dans tous les cas mentionnés, votre client quitte votre site à un moment ou à un autre pour se rendre sur le site de votre passerelle de paiement. En gros, au moment critique, celui de la concrétisation de la commande, vous envoyez gaiement votre client durement converti dans le trou noir d'un service tiers, sur une page que vous pourrez plus ou moins configurer, mais qui ne sera jamais aussi bien intégrée que votre propre site.

Pourtant, j'ai envie de dire que du point de vue du client, « c'est pourtant pas compliqué bordel ! ». Ne serait-il pas tellement plus simple et ergonomique de saisir ses identifiants de carte bleue directement pendant le processus de commande, sur le site marchand auquel on accorde déjà notre confiance ? Prenez-cette capture du processus de paiement sur Capitaine Train. C'est quand même autre chose que le formulaire dégueulasse de Paypal.

Notez qu'en théorie, rien ne vous empêche d'assurer vous-même le rôle de passerelle de paiement, c'est à dire récupérer et stocker vous même les numéros de CB de vos clients, et communiquer directement avec la banque. Le problème est que ladite banque exigera alors que vous soyez certifié conforme au PCI DSS (Payment Card Industry Data Security Standard), ce que vous ne voulez probablement pas faire.

Stripe, la nouvelle alternative

Et s'il existait un moyen de combiner le meilleur de ces différents mondes :

• pouvoir inclure des formulaires de paiement directement sur mon site ;
• en moins de quelques heures ;
• sans se prendre la tête sur de la doc infâme et inutilement compliquée ;
• sans avoir à être certifié PCI DSS.

Depuis quelques mois, des concurrents de Paypal sont apparus, le premier d'entre eux étant Stripe.

Leur système est remarquablement bien conçu. Après avoir créé un compte sans qu'on vous demande l'âge de votre mère ni la religion de votre chien, vous communiquez avec leur système via une api tout ce qu'il y a de plus basique. Tenez, testez-donc cette commande dans votre terminal :

curl https://api.stripe.com/v1/charges \
   -u sk_test_mkGsLqEW6SLnZa487HYfJVLf: \
   -d amount=400 \
   -d currency=usd \
   -d "description=Charge for test@example.com" \
   -d "card[number]=4242424242424242" \
   -d "card[exp_month]=12" \
   -d "card[exp_year]=2014" \
   -d "card[cvc]=123"

Parallèlement, Stripe vous propose un mécanisme pour placer le formulaire de paiement sur votre site, mais sans que les informations de paiement ne transitent par votre serveur. Quelle est donc cette magie ? C'est trés simple :

1. Votre formulaire de paiement s'affiche sur votre site ;
2. À la validation du formulaire, les données sont envoyées chez Stripe en ajax ;
3. Si la requête est valide, Stripe répond avec un Token unique identifiant la transaction ;
4. À ce moment, le token est inséré dans le formulaire, qui est alors soumis naturellement ;
5. Notez que les champs qui concernent la carte bleue ne sont pas transmis ;
6. Côté serveur, vous récupérez le token en question ;
7. Vous l'utilisez pour confirmer la transaction : la carte est alors débitée.

L'intégration se fait de manière remarquablement simple, puisque des librairies sont disponibles pour la plupart des langages courants.

En revanche, si les coûts d'initialisation sont nuls, les frais de transaction restent non négligeables, et bien évidemment l'argent n'est pas directement versé sur votre compte. On n'a rien sans rien.

Stripe, c'est génial… si vous résidez aux États-Unis ! Et oui, pour le moment, il faut faudra un compte marchand États-Unien (?) si vous souhaitez utiliser Stripe. Il faudra donc nous rabattre sur…

Paymill, le même, mais pour les Européens

Le succès grandissant de Stripe fait des émules et Paymill, un concurrent européen, a vu le jour récemment. Notez qu'il s'agit d'un pur clone par Rocket Internet. Le fonctionnement est le même. Les fonctionnalités sont les mêmes. Le site ressemble trés franchement à l'original. Bref ! rien de trés dépaysant.

Comme j'ai pu intégrer Paymill sur DontForgetGrandma.com, j'aurai l'occasion de vous faire un retour plus détaillé dans un prochain article. Nous verrons également comment intégrer un formulaire de paiement dans un projet Django. D'ici là, portez vous bien.