Skip to content

Blog


Huit choses que nous avons apprises en implémentant les paiements dans l'application DoorDash Android

5 octobre 2021

|

Harsh Alkutkar

La mise en œuvre efficace des paiements dans une application mobile nécessite une attention particulière à des facteurs tels que les méthodes de paiement, l'expérience de l'utilisateur et la prévention de la fraude. L'importance critique des paiements mobiles pour une entreprise signifie que les ingénieurs doivent adopter une approche réfléchie, en anticipant toutes les éventualités. Chez DoorDash, nous avons découvert huit facteurs essentiels qui contribuent à créer un système de paiement mobile robuste et performant.

Pour toute application mobile, le paiement est un élément clé de l'expérience d'achat du client. Un passage à la caisse facile permet d'augmenter le taux de conversion et les ventes. Ces dernières années, l'utilisation des paiements mobiles a considérablement augmenté dans tous les secteurs, y compris la vente au détail, les voyages, la livraison de nourriture et les jeux mobiles. 

L'infrastructure des sociétés de cartes de crédit et des fabricants de systèmes d'exploitation mobiles favorise les transactions sans friction, mais les ingénieurs mobiles doivent également faire leur part. DoorDash a traité plus de 2 milliards de commandes. Les facteurs que nous abordons ici devraient donc être utiles à d'autres entreprises qui lancent leurs propres paiements mobiles.

Comment les paiements mobiles sont généralement mis en œuvre

Avant de nous pencher sur les enseignements que nous avons tirés, examinons d'abord comment les composants de paiement sont généralement mis en œuvre dans les applications mobiles. Lorsqu'ils passent une commande en ligne, les utilisateurs transmettent les informations relatives à leur carte à une passerelle de paiement telle que Stripe ou PayPal. La passerelle crypte ces informations et facilite à son tour la transaction avec les processeurs de paiement. Le processeur de paiement communique avec la banque émettrice et demande l'approbation. L'approbation est ensuite transmise au backend, qui indique au client si le paiement a été accepté ou refusé.

Figure 1 : Dans un flux de paiement mobile typique, l'application envoie le panier et les informations de paiement à un backend, qui demande l'autorisation de paiement à une institution financière appropriée.

Outre le fait qu'ils nécessitent un flux de données complexe entre les systèmes internes et externes, les paiements mobiles sont complexes pour les raisons suivantes :

  • Plusieurs modes de paiement (Paypal, Google Pay, Stripe, etc.) :
    • Les méthodes de paiement peuvent être un portefeuille numérique sur l'appareil, comme Google Pay, ou une passerelle de paiement externe, comme Stripe ou PayPal. Nous voulons offrir autant d'options que possible à l'utilisateur, mais il est difficile d'activer toutes les options de paiement disponibles.
    • Chaque méthode de paiement nécessite une intégration complexe dans l'application.
    • Chaque méthode de paiement nécessite une stratégie de test personnalisée.
  • Expérience de l'utilisateur : 
    • Les paiements mobiles doivent être aussi simples que possible pour permettre un passage rapide à la caisse.
    • Non seulement l'interface utilisateur doit fonctionner avec toutes les méthodes de paiement, mais elle doit également fonctionner pour les utilisateurs nouveaux et existants. Si l'on multiplie le nombre de méthodes de paiement par les flux d'utilisateurs nouveaux et existants, on obtient une matrice complexe de flux à mettre en œuvre et à tester.
  • Performance :
    • L'application doit rester performante tout en prenant en charge toutes les méthodes de paiement.
    • Nous devons nous assurer que l'application dispose de toutes les informations nécessaires pour commencer à traiter les paiements aussi rapidement que possible, tout en restant à jour avec les informations sur nos serveurs.
  • Test : 
    • Les tests ne doivent pas être envisagés après coup. Nous devons concevoir le backend et l'application de manière à ce que chaque méthode de paiement et chaque flux puissent être isolés et testés avant la mise en production.
  • Fraude : 
    • Des mesures anti-fraude doivent être mises en œuvre dans toute application comportant un élément de paiement mobile.
  • Localisation : 
    • Nous devons tenir compte de la région de l'utilisateur avant de traiter son paiement afin de nous conformer aux lois et règlements de chaque pays.

Tous les développeurs d'applications sont susceptibles de rencontrer ces difficultés un jour ou l'autre, c'est pourquoi nous avons pensé qu'il serait utile de partager notre expérience en matière de paiements.

Ce que nous avons appris de la mise en œuvre des paiements dans notre application Android

Figure 2 : écran type permettant aux utilisateurs d'ajouter leur mode de paiement préféré

Planifier et concevoir les futures méthodes de paiement

Nos premières versions de l'application Android DoorDash ne prenaient en charge que les cartes de crédit et Google Pay, de sorte que la structure de la base de données et les modèles étaient tous stockés en tant que "Cartes". Cette architecture a conduit les développeurs à essayer de combiner le résultat de la requête cards dans la base de données avec d'autres méthodes de paiement telles que Google Pay avant d'envoyer un résultat cohérent au modèle de vue ou au présentateur. Nous étions également en train d'expérimenter PayPal à l'époque et nous avons dû pivoter pour l'adapter. 

Dans une version antérieure de l'application DoorDash, de nombreuses décisions étaient prises au niveau des objets de la couche architecturale supérieure, tels que le gestionnaire ou la vue ; elles auraient dû être prises dans les couches du référentiel et faire persister l'état dans la base de données. Dans notre pile technologique, les gestionnaires sont des classes qui ne maintiennent pas les données ou l'état ; ils interagissent plutôt avec la couche de données, puis modifient et effectuent des calculs sur la base des informations qu'elle contient. C'est pourquoi nous considérons les gestionnaires comme des abstractions sans état permettant d'encapsuler nos règles de gestion. Par exemple, la logique permettant de trouver le mode de paiement actuel était dupliquée au niveau des gestionnaires ou à un niveau supérieur, alors qu'elle aurait pu se trouver dans une source unique de vérité au niveau du référentiel ou de la base de données. Pour ajouter à la complexité, le concept de crédits a été introduit plus tard, ce que nous n'avions pas prévu au départ pour les couches du référentiel ou de la base de données. Cela a entraîné un recalcul des informations de tarification dans plusieurs objets de la couche domaine ou modèles de vue, ce qui aurait pu être évité grâce à une meilleure planification et à une intégration de la logique dans les couches d'infrastructure inférieures.

Cette prolifération est la raison pour laquelle nous avons introduit la notion de méthodes de paiement, qui peuvent gérer les cartes de paiement, Google Pay et PayPal. De manière générale, nous classons les méthodes de paiement en deux catégories : les méthodes de paiement locales qui font partie de l'appareil, comme Google Pay, et les autres méthodes de paiement qui nécessitent la mise en œuvre d'interactions avec une passerelle de paiement, comme Stripe.

Nous devrions être en mesure d'interroger chacune des méthodes pour connaître les fonctionnalités qui leur sont associées et les utiliser dans l'application selon les besoins. Nous avons inclus une propriété qui indique s'il existe des portefeuilles numériques sur l'appareil, tels que Google Pay, ou s'ils n'existent que sur le backend. Nous avons appelé ces portefeuilles numériques des "méthodes de paiement locales". Un exemple est donné dans la figure 3 ci-dessous où les méthodes de paiement sont la classe abstraite qui contient des propriétés ou des méthodes communes qui peuvent être héritées par des méthodes de paiement concrètes.

Figure 3 Le diagramme de classes indique différents types de sous-classes (méthodes de paiement) qui héritent des fonctionnalités et des propriétés communes de la superclasse des méthodes de paiement.

Attention aux restrictions et aux lignes directrices de mise en œuvre spécifiques aux méthodes de paiement

Les fournisseurs de services de paiement peuvent vouloir être représentés de manière spécifique dans une application. Par exemple, les directives UX strictes de Google Pay expliquent comment afficher ses logos et ses boutons. En outre, Google Pay exige qu'il soit la première option de paiement dans la mesure du possible. Les ressources de l'application doivent être conformes à toutes les directives des fournisseurs de services de paiement.

Faciliter le processus d'accueil pour les nouveaux utilisateurs 

Nous avons récemment réécrit une grande partie de notre pile de paiements sur Android. Ce faisant, nous nous sommes rendu compte que la plupart des nouveaux utilisateurs n'avaient pas configuré de méthodes de paiement. L'application ne leur permettait pas de passer à la caisse et affichait une erreur. Les utilisateurs ne savaient pas quoi faire lorsqu'ils recevaient ce message, et nous avons donc dû repenser le flux afin d'intégrer rapidement les nouveaux utilisateurs. Une suggestion est d'utiliser la méthode de paiement locale sur l'appareil, comme Google Pay, car elle permet aux utilisateurs d'ajouter une carte lorsqu'ils lancent le flux. Cela signifie que les utilisateurs n'ont pas besoin d'avoir une carte dans le dossier de l'application pour effectuer le paiement.

Planifier pour des consommateurs dans différents pays ou des consommateurs en déplacement

Les paiements ne peuvent généralement pas être mis en œuvre d'une manière générique applicable à l'échelle mondiale. Chaque pays a généralement ses propres méthodes comptables. Par exemple, si un consommateur est enregistré aux États-Unis, mais qu'il se rend au Canada pour commander dans un restaurant, cela a des implications techniques, juridiques et comptables pour l'entreprise.

En outre, certaines méthodes de paiement peuvent nécessiter des vérifications ou des informations supplémentaires dans d'autres pays. 

Dans ce cas, nous devons nous assurer que les clés APIpubliables (qui servent uniquement à identifier un compte chez Stripe) sont spécifiques à chaque pays et que nous les récupérons en fonction de la localisation du consommateur. Cela permet également d'éviter tout problème de comptabilité ou de fiscalité qui pourrait résulter d'une facturation incorrecte.

Sécurité et fraude

La plupart des entreprises ne sont pas préparées à faire face à la fraude mobile. Les fraudeurs essaient de trouver des bogues ou des failles dans chaque nouvelle application lancée et peuvent utiliser toute une série de méthodes pour déjouer le système. Nous disposons d'un système interne de détection des fraudes qui soumet l'utilisateur à des contrôles de vérification supplémentaires lorsqu'il soupçonne qu'une action - telle que le paiement, la connexion ou la modification du profil - pourrait être frauduleuse. Ces contrôles sont conçus pour être très difficiles à passer pour les fraudeurs, mais faciles pour les utilisateurs bien intentionnés. Nos systèmes internes de détection des fraudes sont constitués de modèles d'apprentissage automatique et de moteurs de règles qui sont constamment mis à jour pour suivre l'évolution des nouveaux vecteurs de fraude. 

Le stockage des clés d'API ou des secrets sur l'appareil est une mauvaise idée et doit être évité. Le meilleur moyen est d'obtenir les clés à partir du backend. Cette méthode présente toutefois ses propres difficultés, car l'application doit mettre en cache les clés ou les secrets de l'API et disposer d'une logique permettant de les invalider et de récupérer une nouvelle clé en cas de besoin. Il est également important de veiller à ce que les clés API soient récupérées au début de l'application et de mettre en place une logique de réessai appropriée afin que les paiements sur l'application n'échouent pas pour un utilisateur.

Plan d'essai

La plupart des fournisseurs de services de paiement tels que Google Pay ou Stripe disposent de clés API de test et de clés API réelles. L'idée est que les clés de test sont utilisées pour envoyer des transactions dans un environnement "sandbox" (sans frais), tandis que les clés "live" sont destinées à être utilisées en production. Veillez à ce que le backend et le client acceptent et utilisent ces clés de test ainsi que les clés de production.

L'application doit être dans un état où les jetons de test qui représentent des cartes sensibles ou des détails bancaires et des transactions de test sont acceptés par les systèmes dorsaux. Tous les principaux processeurs de paiement offrent cette fonctionnalité, moyennant une configuration supplémentaire. Il est également essentiel de tester la version en la publiant via les pistes de test de la Google Play Console. La signature peut affecter le fonctionnement de Google Pay. Google Pay propose un mode de test que les développeurs peuvent configurer dans leurs applications.

Planifier la performance

Il est absolument essentiel qu'une application reste performante pendant qu'elle traite les paiements. Nous avons appris que la mise en cache des méthodes de paiement et des cartes accélère le processus de paiement pour le consommateur, car il y a moins d'attente pour les informations de paiement dans le panier et les écrans de paiement. Cela doit être fait avec soin et tenir compte des nombreux cas d'erreur où le backend et l'appareil peuvent être désynchronisés. Le suivi des performances est également essentiel ; il est important de savoir comment les utilisateurs interagissent avec les flux de paiement dans l'application et quand ces flux s'interrompent.

Pour notre application Android, nous nous appuyons sur la mise en cache de la plupart de nos informations de paiement et nous nous assurons que lorsque les utilisateurs démarrent ou utilisent l'application, nous disposons des informations de paiement les plus récentes dans le dossier. Les informations de paiement ne sont pas seulement requises lors du paiement final, mais aussi tout au long du flux de l'application pour calculer les avantages à l'écran du panier de commande et afficher les articles dans le panier et leur coût final, y compris les crédits et les avantages.

Ajouter beaucoup de télémétrie

La télémétrie, ou télémesure, est un système automatisé de mesure et de collecte de données à distance.

La télémétrie recueille des données et envoie des informations utiles qui permettent de contrôler la santé des fonctionnalités et de savoir si l'application sert réellement les objectifs de l'entreprise. Si les utilisateurs sont bloqués ou se plantent quelque part dans le flux de l'application, les métriques refléteront cette information. La télémétrie contient des événements, qui sont des verbes lisibles par l'homme ou des actions que nous voulons suivre. Ces événements représentent généralement une action effectuée par l'utilisateur ainsi que des métadonnées relatives à cette action, par exemple lorsque l'utilisateur sélectionne une autre carte ou lorsqu'il y a une erreur au moment où il essaie de payer.

Lorsque nous avons réécrit notre pile de paiements sur Android, nous avons pu constater que les consommateurs rencontraient des erreurs en essayant de payer. Cependant, nous ne disposions pas de suffisamment de données sur les flux à l'origine de ces problèmes. Nous avons ajouté des données télémétriques supplémentaires aux flux de paiement des utilisateurs afin de détecter les nouveaux utilisateurs, le nombre de méthodes de paiement dont ils disposent, le type d'appareil utilisé, si Google Pay a été configuré avec une carte existante dans le dossier, et d'autres problèmes similaires. Nous avons également ajouté des données télémétriques pour enregistrer les raisons des échecs de paiement, telles qu'une carte invalide, des erreurs de réseau et des erreurs de vérification de la fraude.

Les flux de paiement peuvent être difficiles à déboguer s'ils ne fonctionnent pas correctement dans la nature. Au lieu d'envoyer une télémétrie générique telle que "paiement échoué", le système devrait inclure autant d'informations que possible, y compris des codes d'erreur des fournisseurs, des informations sur l'appareil ou tout diagnostic permettant d'identifier l'état de l'application au moment de l'échec. Veillez à ne pas inclure d'informations personnelles identifiables (PII) ou d'informations de paiement qui pourraient être compromises par un pirate.

Conclusion

Une mise en œuvre réussie du paiement mobile est essentielle à la réussite d'une entreprise. Si les utilisateurs ne peuvent pas effectuer facilement des paiements par le biais d'une application, ils refuseront les services de l'entreprise et se tourneront probablement vers un concurrent. La mise en œuvre des paiements mobiles est extrêmement difficile en raison de facteurs tels que les problèmes d'intégration, la sécurité, les tests et les performances. Mais une bonne mise en œuvre des paiements mobiles dès le départ peut faire le succès ou l'échec d'une nouvelle entreprise. En partageant notre expérience, nous espérons que les nouveaux développeurs seront en mesure d'anticiper ces défis et de s'assurer que leurs paiements sont correctement intégrés.

About the Author

Emplois connexes

Job ID: 2915998
Localisation
Sao Paulo, Brazil
Département
Ingénierie
Localisation
Sunnyvale, CA
Département
Ingénierie
Localisation
Pune, Inde
Département
Ingénierie
Localisation
São Paulo, Brésil
Département
Ingénierie
Localisation
San Francisco, CA; Tempe, AZ
Département
Ingénierie