Début 2017, nous, l'équipe de développement logiciel de QIWI Terminals, avons recueilli les souhaits des départements de l'entreprise - nous avons appris quelles tâches globales nos collègues aimeraient résoudre avec notre aide, afin que la vie devienne plus facile.
J'ai été très satisfait de la demande du service client qui travaille avec les appels et les réclamations des payeurs:
«Il y a un problème: le client effectue un paiement au terminal, mais il ne parvient toujours pas au traitement - soit le terminal pourrait se bloquer, soit Internet fonctionnant via le modem gsm est tombé. Et il s'avère que le client a un chèque, mais il n'y a pas de paiement dans le système. Ce serait bien dans de tels cas d'apprendre à effectuer des paiements à QIWI.
Il y a aussi un groupe de clients inquiets qui, immédiatement après avoir effectué un paiement, composent un numéro de centre d'appels pour s'assurer que tout va bien avec lui. Ce serait formidable de couper les os pour de tels appels. »Nous avions donc une tâche complexe: apprendre à créer un paiement en cas d'échec de communication avec le terminal et réduire le nombre d'appels entrants des clients en inventant un outil en libre service pour vérifier l'état du paiement. L'affaire est claire. Ils ont commencé à chercher une solution qui soit pratique pour le client et sans risques pour la sécurité.
Le client, selon la tradition, a offert son option - d'imprimer sur le reçu une séquence de caractères que le payeur pourrait dire à l'opérateur, et lui, à son tour, pour comprendre s'il s'agit de notre paiement ou non, filtrer la fraude ou effectuer l'opération manuellement.
Le concept de l'idée était clair, mais irréalisable, nous sommes donc allés un peu plus loin: nous avons décidé d'incorporer les données de paiement dans le code QR, de les imprimer sur le reçu et de dupliquer le terminal QIWI à l'écran pour plus de précision. En scannant le code QR avec la caméra de son appareil, le client peut connaître l'état de l'opération. Et en cas de non-paiement dans QIWI, le système le crée automatiquement. Ainsi, le client découvre non seulement si l'argent est arrivé, mais le conduit également de manière indépendante, quel que soit l'état du terminal.
À première vue, la solution était évidente: prendre une demande existante avec paiement, l'envelopper dans un code QR, écrire une page Web avec des informations sur les transactions et un microservice mandatant les demandes entre le terminal, le traitement et le Web. Il a été supposé que le projet fonctionnera sur les méthodes existantes d'authentification des terminaux et utilisera les méthodes de paiement existantes dans le traitement.
L'idée est venue tout de suite, révélant le potentiel créatif de l'équipe. Nous avons commencé à jaillir et à lancer des options supplémentaires jusqu'à placer un logo, un slogan et même de la publicité dans un code QR en plus des données de paiement:
Un projet pour quelques sprints, pas plus. Ça y était.
Première frustration
Nous avons pris un paiement existant et y avons formé un code QR:
En conséquence, même le dernier iPhone7 à l'époque ne pouvait pas le lire. Sur le chèque, le code QR, composé uniquement de données de paiement et de signature, tient à peine sur la moitié de la feuille A4. La ligne de demande de paiement était trop longue. Ce fut la première tristesse.
Il fallait résoudre deux problèmes principaux:
- réduire le nombre de caractères dans une demande de paiement, c'est-à-dire trouver une solution dans laquelle nous pouvons passer de la requête xml existante à une requête plus compacte;
- choisissez un algorithme de chiffrement et une longueur de clé qui fourniront une force et une fiabilité cryptographiques élevées avec une taille de signature plus petite.
Le critère pour évaluer le nombre optimal de caractères pour le code QR était un - il devrait être lu par les caméras de la plupart des téléphones mobiles.
En quelques réunions de travail, une solution a néanmoins été trouvée:
- au lieu de la requête xml, nous avons décidé d'utiliser une requête get avec des paramètres de paiement et des séparateurs entre eux;
- construit une signature sur les courbes elliptiques pour raccourcir la longueur.
L'avantage d'utiliser la get-request était que les caméras des téléphones portables ou des programmes spéciaux, en voyant le lien dans le code QR, l'ouvraient immédiatement dans le navigateur, ce qui permettait d'effectuer un paiement en une seule action. Pour réduire la taille de la requête get, nous avons dû remplacer le nom du paramètre par des délimiteurs.
À la suite de l'ensemble des actions, la demande de paiement a été réduite d'environ 1 100 à 200 caractères. De plus, j'ai dû appliquer le niveau de correction d'erreur le plus bas du code QR - L.
Pour la mise en œuvre, il a été nécessaire de développer des composants dans le système:
- créer une nouvelle api pour effectuer des paiements via un code QR;
- introduire un nouveau mécanisme pour travailler avec des clés cryptographiques entre le terminal et le traitement;
- mettre en œuvre un microservice sur lequel la fonctionnalité de proxy des demandes, la vérification de l'intégrité des données reçues, ainsi que la fonction de blocage des demandes suspectes et de collecte des statistiques d'opération seront suspendues;
- développer une page Web pour afficher les informations de paiement;
- Développer un système de limites et de contrôles pour un nouveau canal de paiement.
Au plan de travail existant:
Nous avions prévu d'ajouter une alternative:
Au cours du projet, il semblerait, petit, mais nécessitant de résoudre des problèmes, ce qui en fait a pris beaucoup de temps, reportant la date de lancement.
UX-recherche, ou le travail est venu d'où ils n'ont pas attendu
Je voulais tout faire comme les gens, alors ils ont fait appel à des spécialistes UX pour mettre en œuvre le projet afin de résoudre les problèmes:
- dans quelle partie de l'écran du terminal QIWI pour placer le code QR et comment expliquer son utilité au client?
- où placer le code QR sur le chèque et comment insérer des explications similaires?
- Comment faire une mise en page d'une page web avec le statut de paiement, pour qu'elle soit claire sur les guides de l'entreprise?
De toute évidence, pour la partie avancée des clients, des explications supplémentaires sur le code QR ne sont pas nécessaires, il suffit d'indiquer le résultat. Mais nous voulions couvrir cette partie des clients pour lesquels le QR code est une abréviation magique ou simplement un «carré noir». Ce sont eux qui, en fait, rompent la ligne du centre d'appels.
Pour le rendre beau et compréhensible, une interview a été réalisée au sein du focus group qui nous intéresse avec des résultats inattendus ...
La brièveté est comparable à l'épargne
Cela s'est avéré effrayant - le public dont nous avions besoin ne comprenait pas toujours le sens du mot «Scan» et ses dérivés. Par conséquent, le libellé original «Scannez et découvrez le statut» a dû être abandonné. La solution était la capacité technique d'envoyer une photo du code QR par e-mail. Et il était également nécessaire de le dire brièvement et clairement, car le ruban de contrôle est le matériel consommable des propriétaires de terminaux et notre préoccupation pour les affaires de ces personnes est son économie. Par conséquent, le chèque ressemble maintenant à ceci:
Quant à l'affichage du code QR sur l'écran du terminal, il a été placé sur la dernière page du paiement - le dernier du scénario de paiement. Il est affiché au moment de l'impression du chèque et est essentiellement un duplicata électronique du code QR imprimé.
L'email est omniprésent
Dans le cadre de l'émergence d'un nouveau canal de traitement des QR codes sous forme d'e-mail, il est devenu nécessaire de développer une mécanique ayant pour fonction de reconnaître les QR codes intégrés dans des lettres et de générer une réponse avec le statut de paiement.
La fonction de reconnaissance des codes QR a été supprimée dans le microservice. Lors de la mise en œuvre initiale, le taux de reconnaissance était d'environ 65% dans l'échantillon de photographies présenté. Nous avons essayé de jouer avec la décoloration et l'augmentation du contraste - cela a donné environ + 20% de reconnaissance réussie.
La cerise sur le gâteau dans la tâche de reconnaissance des photos du code QR a été l'introduction de «l'intelligence naturelle» pour les cas difficiles et mal reconnus - la création des applications et leur traitement ont commencé à se faire en mode manuel:
La technique n'est pas des bagatelles
Les principaux développements de ce projet ont bien sûr concerné le microservice lui-même et le logiciel du terminal.
QIWI évolue activement vers une architecture de microservices afin de ne pas toucher le moteur massif. Le microservice vous permet d'apporter rapidement des modifications aux projets, d'effectuer des tests et de publier les versions. Par conséquent, dans quelques mois, nous avons écrit le nôtre. Nous y avons accroché tous les nouveaux développements majeurs qui ne pouvaient être réalisés:
- procuration des requêtes en analysant et en analysant les requêtes get entrantes, en les convertissant en xml pour le traitement,
- fonctionnalité pour limiter les demandes entrantes des terminaux,
- Fonctionnalité de reconnaissance de code QR,
- collecte de statistiques pour une analyse plus approfondie.
En plus de la mise en œuvre d'un nouveau mécanisme pour travailler avec des clés cryptographiques, les améliorations des terminaux ont touché l'application d'une nouvelle technologie pour l'impression des reçus.
La fonctionnalité de leur formation a été retirée du noyau principal du programme dans le plugin. Nous pouvions désormais apporter rapidement des modifications à la vérification, sans toucher à l'opérabilité du terminal dans son ensemble. L'impression d'un code QR, qui, à première vue, semble assez simple et se résume à l'impression d'une photo sur un chèque, n'est pas vraiment telle.
En effet, le réseau de nos propriétaires de terminaux compte environ 20 modèles d'une grande variété d'imprimantes et nous imprimons environ 40 types de reçus. Lorsqu'ils ont commencé l'implémentation, de nombreuses nuances sont apparues: soit les lignes et l'emplacement des objets dans le modèle de vérification ont commencé à flotter lorsque l'image a été ajoutée, puis certaines commandes se sont révélées sensibles à l'emplacement, puis le saut de ligne s'est transformé en onglet.
Nous avons commencé les tests, nous avons réalisé la nécessité d'un compromis - certains modèles d'imprimantes ont dû être exclus, car lors du test de toutes les configurations, un très grand nombre de cas sont sortis.
Pour les tests, nous avons décidé de choisir 6 modèles principaux, qui couvraient 91% du réseau d'agents. Et, bien sûr, au moment d'effectuer des tests aléatoires dans un environnement de combat, il s'est avéré que c'était sur des imprimantes anciennes qui couvraient environ 5% du réseau d'agents que des problèmes d'impression de reçus ont été découverts. Les modèles étaient si vieux que même sur le marché, ils ne pouvaient plus être achetés. J'ai dû chercher avec des partenaires. Désormais, le projet couvre 96% du réseau. Déjà un peu plus près de l'idéal :)
Pas un seul chèque
Parallèlement au placement des informations sur le code QR sur le chèque et la dernière page du paiement, une autre tâche a été évoquée - amener cette page à un aspect universel pour tous les projets de terminaux:
«En termes de pages d'achèvement de paiement dans les terminaux QIWI, tout était assez archaïque: publicité, bannières et envoi de reçus électroniques. À partir de cinq pages, les gars en ont créé une, universelle pour tous les paiements. » - Programmeur leader de l'équipe.
Maintenant, cette page universelle est utilisée dans différentes interprétations, sans enfreindre la règle de construction d'un script, fermant ainsi la dette karmique de l'équipe de développement.
Ainsi, le problème d'il y a dix ans a été résolu, auquel les mains n'atteignaient pas à chaque fois. Il y avait plusieurs tâches de longue haleine.
"Où est l'argent, Zin?" ou ce qui est en fin de compte
Le projet, conçu pour quelques sprints, a duré six mois, affectant les ressources de 10 salariés et la périphérie de l'agence d'externalisation.
En conséquence, après avoir mis en œuvre le projet sur 85% du réseau de terminaux, nous nous sommes surpris ainsi que le client - le service client. Le troisième jour du code QR, les collègues pensaient qu'une erreur système s'était glissée dans eux - des statistiques sur le nombre d'appels au centre d'appels avec la question "Où est mon paiement?" déjà baissé de 20%. Les clients ont commencé à scanner le code QR et à envoyer des reçus photo par e-mail, en découvrant le statut et en effectuant leur propre paiement. Et donc pour le deuxième mois. Je dois dire que les clients ont commencé à comprendre ce qu'est le «carré noir» et à quoi il sert.
Le projet avec un code QR a été apprécié par tous ceux qui en ont été informés - c'était une synergie d'intérêts: d'une part, ils ont simplifié la vie du client, et d'autre part, ils ont résolu un problème technique non standard. Vérifier l'état d'un paiement et le réaliser dans un morceau de papier en traitant simplement un code QR pour QIWI est quelque chose de nouveau. C'était formidable de prendre des technologies connues et simples à partir desquelles faire un projet utile. En général, le projet a non seulement stimulé les compétences, mais également amélioré la communication au sein de l'équipe elle-même. Et c'est presque le principal avantage du karma.