Les paiements en ligne sont devenus quelque chose d'aussi familier que le Wi-Fi à domicile et l'Internet mobile à haut débit. Et ils continuent d'évoluer, de plus en plus de services peuvent être payés en quelques clics ou à partir d'applications mobiles, et ici aussi les paiements automatiques, les rappels, le contrôle des coûts et bien plus encore.
Dans la poursuite de la fonctionnalité, n'oubliez pas l'utilisateur, car notre tâche principale est de lui faciliter la tâche d'effectuer n'importe quel paiement dans n'importe quel scénario. Cela signifie que le formulaire de paiement doit être aussi clair que possible et offrir également à l'utilisateur des options pour résoudre les problèmes s'ils surviennent soudainement.
Je m'appelle Georgy Konnov, je suis directeur du développement des produits pour le commerce électronique chez QIWI, et aujourd'hui je vais vous expliquer comment nous avons développé un formulaire de paiement que n'importe quel magasin peut rapidement connecter pour accepter les paiements.
Sous la coupe - sur la conversion, la motivation des utilisateurs, notre protocole, la charité et l'open source.
Bien entendu, l'un des principaux indicateurs du succès d'un mode de paiement est la conversion. Eh bien, sérieusement, si vous avez créé une belle forme impressionnante en utilisant les dernières technologies et les guides des meilleures entreprises, mais cela ne rapporte pas bêtement en raison d'une faible conversion - cela signifie que vous avez fait des ordures, pas un formulaire de paiement.
Presque tout le monde dit maintenant que le taux de conversion des formulaires de paiement est d'environ 99%, voire plus. Ce n'est pas le cas.
Si nous mesurons et évaluons honnêtement la motivation même des gens à effectuer des paiements, vous pouvez voir que cela dépend beaucoup de la catégorie de paiement (si elle est mesurée depuis l'ouverture du formulaire de paiement jusqu'à ce que le paiement soit effectué). La motivation maximale est de terminer le processus de paiement où l'utilisateur a déjà passé un certain nombre de procédures complexes - identification et ainsi de suite, divers paiements B2B et le même renouvellement de domaine, par exemple. Ensuite, la personne a ouvert le formulaire avec un désir clair de renouveler le domaine (sinon il tombera) ou d'effectuer un paiement important - et il le fera.
Mais s'il s'agit d'un achat régulier, alors vous pouvez facilement perdre immédiatement un quart des clients dans le processus de paiement. Ici, la conversion est déjà de l'ordre de 75 à 85%.
Il y a plusieurs raisons. S'il s'agissait d'une sorte d'achat spontané («Je suis fatigué, j'achèterai de l'or rapidement et je me plierai»), alors le client peut ne pas avoir assez d'argent. Ou sur la dernière fenêtre, il verra à nouveau le montant qui est déjà prêt à être débité de son compte, et décidera que ce n'est pas mauvais sans or. Et fermera le formulaire sans effectuer le paiement.
Et cela ressemble à des biens réels - des champs supplémentaires peuvent être distraits ici, une personne veut enfin acheter un aspirateur, et le formulaire demande son numéro de téléphone, son courrier et le surnom de son chat (nous sommes ici spécifiquement pour les demandes de formulaire de paiement, pas pour le compte personnel d'un magasin qui nécessite une série de données pour la livraison et le suivi des commandes). Ou tout va bien avec le formulaire, mais en regardant le prix, la personne décide de vérifier les prix sur le même marché plus avantageusement, et quitte le formulaire.
Il était cependant un peu surprenant de constater un comportement similaire lors du paiement des services éducatifs. Il semblerait que la détermination soit clairement plus élevée que le désir d'acheter quelque chose pour vous-même en allant sur le site Web du magasin à partir d'une lettre avec le sujet "Seulement aujourd'hui, une remise de 80% sur tout *!".
* pour presque tout
** sur ces deux fers et reconstruit SEAutrement dit, la personne vient de choisir le bon cours pour la spécialité souhaitée, a ouvert le formulaire de paiement - et toujours les mêmes chiffres de conversion sont petits, comme dans la charité.
Tel que mesuré
La plupart prennent des mesures comme celle-ci.
Il existe une telle entité comme une transaction. Cela peut être réussi ou échoué. S'il n'y a soudainement pas d'argent dans le compte du client, une erreur s'affiche que le formulaire ne peut pas affecter. Eh bien, pas d'argent et non, ne le donnez pas. Ou une erreur technique s'est produite. En conséquence, il s'avère que sur le nombre total de paiements avec cette approche, 98-99 sont considérés comme réussis.
Mais si vous mesurez à partir du moment où le formulaire de paiement est ouvert jusqu'à ce que le paiement soit réussi, les chiffres seront différents.
Nous avons lié toute cette histoire aux comptes. Il y a une facture, au moment de l'ouverture du formulaire elle est exposée et vit 45 jours. Autrement dit, une personne peut retourner au même mode de paiement dans ces 45 jours et le compléter si, pour une raison quelconque, elle change d'avis plus tôt. Cela nous permet de voir la conversion complète, même si la personne est revenue après quelques jours - un seul compte et le montant total est obtenu. Eh bien, comme le montre la pratique, les gens peuvent donc assez souvent retourner au processus de paiement.
À propos des rappels
Les rappels sont une autre histoire. Nous avons essayé différentes mécaniques ici. Chose attendue est allé avec web push. Par exemple, il y avait une personne sur le site Web du magasin, a composé un panier, a reçu une facture dans le formulaire de paiement, qu'il n'a pas payée, et a fermé la fenêtre - puis il a reçu le push Web "Payer la facture". Une telle chose est ennuyeuse. De plus, la diffusion Web sans contexte adéquat est déjà perçue comme du spam.
Eh bien, 10% des utilisateurs souscriront à une telle poussée. Ensuite, 10% les traverseront. En général: pour un site moyen, compte tenu du trafic, de tels chiffres ne font pas du web push le canal de rappel le plus utile. Et si vous prenez également en compte que la base de ces canons par mois est de 15% pourrie ...
Mais ce qui fonctionne avec un bang - si une personne au moment du paiement montre son paiement oublié précédent, cela est perçu comme un rappel utile.
Par exemple. Va te faire foutre acheter un nouveau jouet dans Steam. J'ai choisi, commencé à passer une commande, j'ai réalisé qu'il n'y aurait pas assez d'argent maintenant, ou j'ai simplement décidé de la reporter pour plus tard. Une semaine plus tard, je suis allé acheter une mèche à Ali, vous effectuez un paiement, puis le formulaire pour vous - "Pst, vous vouliez acheter un jouet il y a une semaine, regardez." Et ces utilisateurs vont généralement effectuer le paiement précédent.
En chiffres - web push apporte 3 roubles à la liste de diffusion.
Un rappel similaire est de 60 roubles.
Ces mécanismes fonctionnent pour les fournisseurs connectés au portefeuille. Et cela s'avère une telle situation gagnant-gagnant, lorsque chaque fournisseur connecté peut augmenter la conversion d'un autre.
Fonctionnement du protocole
Auparavant, nous venions d'avoir un protocole de bourse, j'ai déjà écrit à ce sujet
ici .
Il n'y avait qu'un
portefeuille . Et cette année, nous avons annoncé un nouveau protocole dans lequel désormais Wallet, et l'acquisition, et le commerce mobile, et les versements selon notre conscience, seront un tas d'autres méthodes de paiement. Tout cela dans une seule solution, dans un seul protocole.
Notre objectif était de faire des statistiques transparentes pour tout le monde. Par conséquent, nous avons laissé des comptes, ce qui nous permet de suivre la conversion réelle du magasin de la manière la plus transparente possible, plutôt que technique. Et nous avons ajouté toutes les mécaniques qui contribuent à augmenter le chiffre d'affaires. Tous clés en main.
De l'extérieur, cela peut sembler assez simple - mettez une forme de paiement et ayez juste le temps de compter l'argent. Mais en fait, il s'avère que l'acheteur n'a peut-être pas de fonds sur la carte. Eh bien, ça arrive.
Et ici, sous la forme, nous proposons immédiatement une alternative dans de tels cas. Pas assez pour payer? Regardez, il est possible de payer rapidement à partir de notre téléphone mobile par SMS. Ou, en général, selon Conscience Ou autre chose.
Il est important que le client voit dans ce cas non seulement un problème, mais aussi des options pour le résoudre. Autrement dit, en l'absence d'argent, ce n'est pas «Pas assez d'argent» comme une erreur qui ne mène qu'à fermer la fenêtre ou à essayer d'entrer une autre carte, mais à proposer immédiatement d'autres modes de paiement sans déployer l'utilisateur.
Cette approche augmente la conversion finale en paiements réussis. Parce que pour augmenter la conversion, vous ne pouvez pas vous concentrer sur le taux d'acquisition. En général, toute tentative de se concentrer sur le taux est une tentative de concurrencer une grande banque verte, qui a le coût d'acquisition le plus bas, comme elle peut se le permettre.
Mais vous pouvez participer à la conversion en paiement. Il est beaucoup plus facile de l'augmenter de 2-3 à 3-5 pour cent que d'essayer de réduire le taux d'acquisition (qui est déjà dans la région 2).
Par conséquent, nous avons décidé de simplifier la partie informatique autant que possible et d'ajouter toutes les mécaniques disponibles à la caisse. Le prendre et le connecter rapidement - et tout a fonctionné pour vous.
Pas un seul web
À mon avis, seuls les paresseux n'ont pas parlé du rôle des téléphones mobiles dans les achats en ligne. Je vais donc répéter la thèse bien connue et ajouter un peu de nos chiffres.
En 2015, nous avons reçu environ 10% des appels à partir de téléphones mobiles. Et il y avait des applications mobiles sympas dans le top 3 des marchés. Il y avait le choix - soit vu une application Web distincte pour mobile, soit effectuer un paiement adaptatif simple. Nous avons alors décidé de ne pas nous embêter et comme une expérience a fait une simple adaptation au mobile. Et depuis six mois, ce chiffre est passé de 10% à 30%.
Il y a un an - environ 40%.
Maintenant - 51-52.
En général, faire du shopping à partir de téléphones mobiles est en fait du dofiga. Par conséquent, nous avons fait une très bonne mise en page mobile. Nous avons constaté une augmentation des paiements, décidé de mener quelques études supplémentaires et discuté avec des partenaires du marché. Il s'est avéré que ceux qui se sont adaptés au mobile ont connu une croissance des ventes. Ceux qui ont marqué sur le mobile avaient environ le même 10%.
Voici d'ailleurs un schéma montrant la répartition des ventes selon que le magasin est adapté ou non. Il y a 14 grandes boutiques en ligne, que nous n'appellerons pas, mais savons simplement - grandes.
Qui a une application mobile - il a déjà 1,5 fois plus d'achats. Celui qui a une adaptation ou une application a également des améliorations de vente, tout comme une adaptation très légère.
Violet dans le diagramme sont des gars sans adaptatif. Mais même ils ne sont pas aussi tristes que le bleu - rien ne fonctionne sur ces téléphones mobiles.
Je voulais dire ça. Il n'est pas si nécessaire de faire une application mobile haut de gamme à la poursuite du trafic. Même l'application ne nie pas le fait que l'adaptation doit être faite. Même les adaptations de page les plus simples vous donneront déjà de bons résultats.
Nous avons fait le premier pas en 2015, comme je l'ai écrit ci-dessus. Et maintenant, nous avons une nouvelle version qui s'intègre bien sur le clavier à l'écran, fonctionne très bien avec les API Google et avec iOS en termes de cartes à saisie automatique. Et tout cela sur une base clé en main afin qu'il soit rapide et pratique. Et maintenant, nous avons une conversion sur les téléphones mobiles presque égale à celle du bureau. L'adaptation elle-même détermine comment elle doit maintenant apparaître sur quel écran.
Portefeuille et intégration
Le portefeuille n'est pas positionné comme le seul moyen de paiement. Vous n’avez pas à payer du tout. Vous pouvez simplement y associer des cartes ou accepter un paiement simplifié, auquel cas le portefeuille agira comme un accélérateur de paiements déjà familiers. Si nous voyons que l'utilisateur nous est exactement familier (pour un certain nombre de signes) - nous pouvons donner la possibilité de désactiver 3DS, par exemple. Bien sûr, ce n'est qu'une option, et si vous ne souhaitez pas désactiver la vérification supplémentaire, vous n'en avez pas besoin.
Nous nous souvenons de l'autorisation pendant six mois, à la fois par mot de passe et par SMS. Les sessions sont divisées en demi-jetons, c'est-à-dire la moitié du jeton avec nous et la moitié sur l'appareil de l'utilisateur. Si cela - la session en 1 clic peut être réinitialisée.
Le paiement de bout en bout fonctionne partout - par exemple, même dans l'application de téléphonie mobile AliExpress, notre formulaire s'ouvre, dans lequel tout est déjà rempli si l'acheteur l'a utilisé auparavant.
Nous avons décidé de prendre en charge la compatibilité descendante, et le nouveau protocole intégré fonctionne pour les partenaires qui ont introduit le protocole en 2010 et ceux qui ne l'ont installé qu'hier. Nous avons presque tous les ecommers actifs dans notre base de données. Et nous avons fait glisser toute cette base sur de nouveaux outils.
L'ancienne version était affûtée sous les bornes. Un homme a entré son numéro de téléphone, une facture a été émise et cette facture est apparue partout - sur le site, dans les terminaux, dans le téléphone portable. Différents fournisseurs ont alors mis dans quels chiffres différents des masques de saisie, ce qui n'a fait que compliquer l'intégration.
Dans la nouvelle version du compte, nous avons enregistré. La facture est émise sans aucun signe. Le fournisseur a donné le numéro de téléphone - OK, n'a pas transmis - nous travaillons sans lui. Le commerce mobile vous permet de facturer et de payer immédiatement, en combinant deux actions en une seule demande. Les partenaires n'ont pas à compliquer leur vie. Si quelque part il est possible de réduire le nombre de requêtes, alors on s'éloigne du reste canonique, ce qui simplifie la vie des développeurs lors de l'intégration.
D'ailleurs, l'intégration est également simplifiée au maximum. Le protocole a été conçu non seulement par des techniciens, mais également sous l'œil vigilant d'une entreprise. Et pas en termes de suivi et d'ajustement, mais en termes de prise en compte au départ de toutes les difficultés de l'entreprise et de simplification de toutes les futures intégrations. L'ancien protocole avait 5 paramètres - ID du fournisseur, mot de passe secret, ID d'autorisation, devise, mot de passe pour les notifications.
Dans le nouveau - 2 paramètres. Une clé publique pour les formulaires Web pouvant être diffusée à l'extérieur et une clé secrète utilisée dans l'API du serveur avec des droits d'accès complets, la possibilité d'annuler des transactions, d'effectuer des remboursements, etc.
De plus, nous avons rendu possible le transfert de données supplémentaires. Auparavant, vous deviez connaître l'ID de compte et le numéro de téléphone. Et maintenant, il y a des champs personnalisés - je veux que le fournisseur obtienne l'identifiant interne du client - s'il vous plaît. Il faut jeter un numéro de téléphone, une adresse de livraison - c'est tout. En général, pour ne pas écrire votre propre logique pour tout cela, vous pouvez simplement nous transmettre. Et dans toutes les notifications, après un paiement réussi, ces données seront retournées.
Le protocole est modulaire, vous pouvez remplacer tous les widgets et précommandes, nous les avons activement testés pour la charité.
Auparavant, tout était dans un monolithe. Dans lequel il y avait un traitement. Puis il a commencé à envahir les côtés avec des gadgets utiles supplémentaires. Il s'avère maintenant que le traitement est en réalité responsable de la réalisation des transactions. Soit dit en passant, pour les cartes, nous en avons écrit une nouvelle - accélérée afin de ne pas traîner l'héritage du temps.
Contributions caritatives
Il y a quelques années, nous nous sommes assis et avons réfléchi à la manière de combiner normalement et intégralement le paiement et le soutien des fondations caritatives. La toute première pensée est de simplement jeter un peu (par lui-même, si l'utilisateur le souhaite et la case à cocher correspondante) directement dans le chèque. Eh bien, c'est-à-dire que vous achetez une théière pour 5000 roubles, mettez une coche «Je veux aider» - et maintenant vous avez un chèque pour 5050, par exemple, vous payez. Total une transaction, dans laquelle une partie de l'argent va au magasin et une partie - au fonds.
Gizmo n'est pas évolutif à partir du mot en général. Le service comptable de l'entreprise à laquelle nous transférons s'affaisse - ici, dans de tels cas, il est nécessaire de conclure un triple accord complexe (nous, l'entreprise, le fonds).
Et le retour est difficile. Vous avez changé d'avis sur la théière, vous l'avez rendue. Et le montant pour la bouilloire et les frais sont allés en une seule transaction.
Nous avons donc décidé de faire comme ça.
Après paiement réussi, l'utilisateur est invité à faire un petit don en 1 clic. Un tel système fonctionne, environ 3 à 5% sont prêts à le faire. Voici le montant principal. Si elle ne dépasse pas largement 50 roubles, alors c'est OK et simple. Si plus, alors un contexte est déjà nécessaire où l'argent ira, et quoi pour le fonds, et ce qu'ils font, et ainsi de suite.
Les jeunes à cet égard sont plus simples - ils voient qu'il y a une marque A qu'ils croient (un magasin), ils voient la marque B, et tout va bien, ils traduisent. Et les personnes âgées ont besoin d'un contexte détaillé pour s'assurer que le fonds est réel et que ces 50 roubles ne sont pas destinés à une nouvelle BMW pour un employé du magasin.
Nous avons essayé de calculer les montants des dons de différentes manières. Par exemple, une personne a acheté quelque chose et après l'achat, 123 roubles resteraient sur son compte. Dans de tels cas, nous avons proposé d'arrondir et de transférer au fonds 3 roubles ou 23 roubles. Eh bien, quoi pour vous cette bagatelle de fer dans un portefeuille électronique, eh bien, la vérité.
Il s'est avéré qu'ici nous étions trop motivés et cette approche n'a pas très bien fonctionné. Où plus raides sont précisément de petits montants fixes. Habituellement, environ 5% du solde.
Les paiements de charité précédemment reconnus directement sur le site Web au fonds Khabensky étaient d'environ 20 par mois. Il est devenu environ 30 000 - 35 000 par mois. Nous l'avons commencé et avons pensé qu'il serait bien de montrer cela non seulement avec le paiement du portefeuille, mais aussi avec n'importe quelle autre carte et plus encore.
Nous avons finalement découvert que les gens n'ont pas besoin d'un tel paiement en 1 clic, s'ils veulent effectuer un paiement à partir de la carte, ils choisiront eux-mêmes la méthode. D'ailleurs, ils ont réduit l'hypothèse une semaine avant mai.
Au fait, vous pouvez essayer notre formulaire de paiement, et en même temps faire une bonne action en soutenant l'un des fonds:
- Foi - Soins systémiques aux hospices et à leurs patients
- Fondation Khabensky - aider les enfants atteints de maladies cérébrales graves
- {à tous - à plusieurs fonds caritatifs en parts égales à la fois
Et les propriétaires de sites peuvent aider n'importe quel fonds en affichant eux-mêmes un widget ou un lien:
widget.qiwi.com/vera ,
my.qiwi.com/bfkh ,
my.qiwi.com/vsem ou bien d'autres. Écrivez si vous le souhaitez.
Open source
Maintenant, vers l'open source, nous nous sommes déplacés assez activement. Nous avons publié de la documentation, des exemples, des SDK et des intégrations sur
https://github.com/QIWI-API/ . En lisant la
documentation , vous pouvez cliquer sur le bouton «éditer sur GitHub» et faire une demande de correction.
En général, nous essayons de faire glisser tout ce qui n'est pas en cours de traitement vers l'open source. Les
API GitHub QIWI et
GitHub QIWI ont pris vie. Nous voulons que les projets et les composants se trouvent séparément, et la documentation, les divers SDK et bibliothèques au-dessus de l'API QIWI - séparément. Nous portons beaucoup de choses sur GitHub.
Nous ouvrons l'API Wallet afin que toutes les opportunités disponibles au sein de l'entreprise soient ouvertes aux développeurs externes. Fondamentalement, QIWI se tourne maintenant vers BaaS, Bank as a Service. Et notre tâche ici est de rendre tous les sites simples, avec des pratiques courantes. Par conséquent, nous passons à l'open source.
Pour l'avenir
Nous voulons que tout soit excellent et travailler pour le paiement avec QIWI Wallet et l'utiliser pour un travail complet avec les cartes - tous ces rappels, les paiements oubliés, etc. Ajoutez des méthodes de facturation bancaire. Bien sûr - Apple Pay et Google Pay. , , , .
CMS-, QIWI . Wordpress , — .
54 2- .
Kassa.qiwi.com — . , .
, API,
, .
, , — .
PS , :
kassa.qiwi.com/teamReact JS- Java-. JS Fullstack
15, , , . , . :)