Comment ne pas perdre d'argent dans la boîte noire: méthodes de test de facturation

La validation des services payants est l'un des principaux problèmes d'ingénierie lors des tests de Badoo. Notre application est intégrée à 70 prestataires de paiement dans 250 pays du monde, et un bug dans au moins l'un d'entre eux peut entraîner des conséquences imprévisibles.

Dans cet article, je parlerai des méthodes de test que nous utilisons dans Badoo et des limites d'applicabilité de ces méthodes - les étapes de test auxquelles elles sont les plus efficaces.

Cet article sera utile aux testeurs, développeurs et chefs de produit, dont les projets sont déjà intégrés avec les prestataires de paiement, ou le processus d'intégration ne fait que commencer. Si dans votre travail vous êtes confronté au problème du choix des méthodes de test pour de telles intégrations, bienvenue chez cat!




Je m'appelle Vladimir Solodov, je suis ingénieur QA facturation chez Badoo: je suis engagé dans la vérification des intégrations de test et le traitement des paiements. Mon collègue Viktor Koronevich m'a aidé à préparer le texte: avec lui, nous avons fait un rapport lors de la conférence de Heisenbug ( vidéo ). Dans l'article, nous avons étendu la zone de description à toutes les intégrations avec les fournisseurs de paiement utilisés dans Badoo, classifié et décrit plus en détail la pratique de la suppression des dépendances externes.

À l'aide d'exemples d'études de cas, je vais vous expliquer pourquoi vous devriez accorder plus d'attention au test des services payants et comment ne pas aggraver les problèmes s'ils surviennent néanmoins. Ensuite, nous décrirons les problèmes techniques liés aux tests d'intégration et les moyens de les résoudre.

La deuxième partie de l'article, dans laquelle nous parlons davantage de l'automatisation des tests de services payants dans les applications iOS, est ici .

C'est parti!

Spécificités du test de facturation

En règle générale, l'objectif d'une entreprise est de générer des revenus. À Badoo, un réseau social de rencontres, les revenus sont générés par des prêts et des abonnements premium. Les prêts sont la monnaie interne de Badoo. Avec leur aide, par exemple, vous pouvez augmenter votre profil dans les résultats de recherche en premier lieu, faire un cadeau à un autre utilisateur, etc. L'abonnement premium est valable pour une certaine période de temps et vous offre plusieurs options à la fois: activez le mode "invisible", voyez les personnes qui ont manifesté de l'intérêt pour vous, confirmez l'authenticité de votre compte et bien plus encore.

Pour faire fonctionner ces services payants, nous utilisons des intégrations avec plus de 70 prestataires de paiement. Le choix du fournisseur dépend de la plate-forme, du pays, de l'appareil, de l'opérateur mobile et d'autres facteurs. Par conséquent, la question du test des services payants est très urgente.

Pour commencer, réfléchissez aux raisons pour lesquelles le test des services payants doit être abordé avec une attention particulière. Il y a deux raisons.

1. Les bogues de facturation sont essentiels pour les entreprises.

Le premier problème est la réputation. L'utilisateur qui a payé le service devient plus sensible (et moins tolérant) aux bugs de l'application. Tout commentaire dans l'espace public, qu'il s'agisse d'un examen d'une application de blog ou d'un commentaire sur l'App Store ou Google Play, d'un utilisateur qui rencontre un bug dans un service payant, sera plus émotionnel - c'est un facteur qui conduit à des pertes de réputation.

Le deuxième problème est que, dès que vous commencez à recevoir de l'argent d'un utilisateur pour un service, vous devenez l'objet d'une loi qui protège le consommateur du service. Et les pertes de réputation peuvent facilement se transformer en pertes financières.

Les entreprises perdent de l'argent de trois manières.

La première consiste à rembourser . Supposons qu'un utilisateur trouve que vous lui avez vendu un service qui ne répond pas tout à fait à ses attentes. Dans ce cas, il contactera votre équipe d'assistance. Ses employés mènent une enquête et découvrent que les attentes de l'utilisateur ne se sont vraiment pas concrétisées en raison d'un bug dans l'application. Vous initiez un remboursement. Dans ce cas, il y a un remboursement: en conséquence, l'entreprise est confrontée à une perte de bénéfices, et c'est le moyen le plus inoffensif de perdre de l'argent.

La deuxième façon est la rétrofacturation . Supposons que la même situation se soit produite, seul l'utilisateur n'a pas contacté votre service d'assistance, mais la banque qui lui a délivré la carte ou le prestataire de paiement. La banque / le fournisseur initie un remboursement. Dans ce cas, nous avons affaire à une rétrofacturation. Ici, le danger pour les entreprises ne réside pas seulement dans la perte de profits. Après un certain nombre de refacturations, l'entreprise se voit infliger une amende et sa cote de risque diminue. La dégradation, à son tour, entraîne une augmentation du coût des services des prestataires de paiement.

La troisième voie - poursuites (réclamations) . Dans les cas les plus négligés, des poursuites (y compris collectives) peuvent avoir lieu, entraînant les conséquences les plus graves. Ainsi, en 2015, après une action en justice intentée par le régulateur d'Ofgem, British Gas a été obligée de verser une compensation de plusieurs millions de dollars aux utilisateurs qui ont facturé des frais plus élevés en raison d'une erreur dans le système de facturation. En savoir plus à ce sujet ici .

2. Pour tester les intégrations, les connaissances et l'expertise sont nécessaires.

Les équipes qui commencent tout juste le processus d'intégration avec les prestataires de paiement sont souvent confrontées à ce problème. Ne connaissant pas tous les cas de facturation possibles, ils manquent des nuances importantes lorsqu'ils réalisent la réaction du système aux notifications des fournisseurs de paiement.

Cela peut entraîner des conséquences imprévisibles - de la perte de profits aux utilisateurs mécontents.

Examinons le schéma qui répertorie les types de services payants et examinons le problème plus attentivement.


Figure 1. Cas de facturation possibles

Il existe trois cas principaux: une erreur, un paiement réussi et un remboursement à l'utilisateur. Mais chaque cas a des détails, chaque cas que votre système doit gérer différemment.

Les erreurs peuvent être critiques et non critiques. Une erreur de notification peut être attribuée à un blocage non critique - lorsque le fournisseur de paiement informe du manque de fonds dans le compte de l'utilisateur et critique - du mode de paiement de l'utilisateur. Et si dans le premier cas, vous pouvez essayer de payer plus tard, dans le second - ce serait bien de comprendre pourquoi la méthode est bloquée. Peut-être que l'utilisateur a été remarqué dans une fraude et que vous devriez faire plus attention à ses transactions.

Remboursements . Vous savez déjà qu'il existe deux types de retours: les remboursements et les rétrofacturations. Votre système doit y répondre différemment. Par exemple, après une rétrofacturation, il est judicieux de penser à bloquer certaines fonctions de votre application pour l'utilisateur, car la rétrofacturation est l'une des méthodes de fraude les plus populaires.

Un paiement réussi peut être un paiement unique ou un abonnement.

Les paiements uniques peuvent être consommables et non consommables. Un exemple de paiement dépensé que nous avons examiné au tout début de l'article - ce sont les prêts à Badoo. Un exemple de paiement durable peut être donné à partir des jeux. Supposons que vous ayez un personnage que vous jouez. Vous voulez lui acheter des superpuissances qui existent depuis un certain temps. Dans ce cas, l'achat appartient à la classe des paiements durables.

Abonnements Voici la plus grande variété de cas. En plus de l'achat initial d'un abonnement, vous pouvez avoir:

• renouvellement d'un abonnement (renouvellement);
  
• fermer l'abonnement (annuler l'abonnement);
  
• abonnement d'essai (essai);
  
• abonnement au délai de grâce: lorsque nous ne pouvons pas renouveler l'abonnement et essayer de payer à nouveau pendant une période appelée période de grâce. Pour l'utilisateur, le délai de grâce ressemble à ceci. Supposons que vous ayez acheté un abonnement mensuel à un journal. La société qui vous envoie des journaux essaie d'annuler le paiement du prochain mois d'abonnement après la fin du premier mois, mais ne peut pas le faire (en raison d'un verrou de carte, d'un manque de fonds dans le compte, etc.). Si la période de validité de la période de grâce est de dix jours, pendant ce temps, la société essaie d'annuler le paiement, tandis que l'abonnement reste valide. Si l'entreprise n'est pas en mesure d'annuler l'argent, l'abonnement est annulé. Si tel est le cas, l'abonnement est renouvelé à partir de la date du dernier paiement;
  
• paiement partiel (facturation partielle). Par exemple, PayPal autorise le paiement partiel si le compte de l'utilisateur ne dispose pas de suffisamment de fonds (paiement partiel), ou pour diviser le paiement en plusieurs parties (facture partielle).
  

Vous devez également prendre en compte deux caractéristiques totalement dépendantes du prestataire de paiement: l'abonnement peut être contrôlé par votre application ou géré en externe.

• Un abonnement géré en interne est, par exemple, un abonnement utilisant des cartes de crédit ou PayPal, lorsque, après le premier paiement, vous recevez un jeton avec lequel vous réappliquez au fournisseur, sans avoir les détails de paiement de l'utilisateur.
  
• Un abonnement géré en externe est lorsque l'agrégateur de paiement prend le contrôle total de vos abonnements et vous envoie simplement des notifications sur leurs statuts actuels.
  

Sur la figure, les zones les plus évidentes, dont la réaction est généralement réalisée en premier lieu, sont surlignées en violet. Tous les autres commencent à être pris en compte beaucoup plus tard, comme l'accumulation d'expertise. Ceci est largement facilité par l'application incorrecte des méthodologies de développement itératif dans le domaine de la facturation.


Figure 2. Cas de facturation principalement mis en œuvre dans les systèmes

Une telle mise en œuvre progressive peut entraîner des conséquences imprévisibles. Par exemple, dans l'un des projets sur lesquels j'ai travaillé avant Badoo, la possibilité de faire un remboursement n'a pas été prise en compte. En conséquence, tous les retours ont été effectués non pas par le biais de remboursements, mais par le biais de rétrofacturations, ce qui a affecté négativement la cote de risque de l'entreprise et conduit à des échecs dans la collecte des statistiques de revenus. L'ignorance de toute la variété des cas de facturation peut entraîner une perte de bénéfices ou une vulnérabilité de l'entreprise pour les utilisateurs qui se sentent trompés.

Ainsi, d'une part, les bogues dans le traitement des paiements doivent être trouvés avant la publication, car ils peuvent entraîner les conséquences les plus négatives. Si cela n'était pas possible, il est important de comprendre le plus rapidement possible que le bogue est entré dans la version finale de l'application, de le corriger et, surtout, ce que beaucoup de gens oublient, «rassure» les utilisateurs qui rencontrent ce bogue.

D'un autre côté, la situation est compliquée par le fait que l'intégration avec les prestataires de paiement est toujours une interaction avec la boîte noire, ce qui ajoute beaucoup de variables au processus de test.

Problèmes techniques lors des tests de facturation

Examinons-les sur l'exemple de l'intégration de Badoo avec l'App Store.

Les abonnements sur l'App Store appartiennent à la classe des gestionnaires externes, c'est-à-dire qu'ils sont entièrement gérés du côté du fournisseur, et notre système ne peut que demander l'état actuel ou recevoir une notification de sa modification.

Nous avons spécifiquement choisi cette intégration, car elle est la plus complexe et contient toute la variété des cas que l'on retrouve dans le processus d'intégration du service avec d'autres prestataires de paiement.

Pour commencer, nous nous tournons vers un achat unique non réutilisable.


Figure 3. Processus de paiement unique non remboursable

À l'étape 1, l'utilisateur fait une demande d'achat du service. L'application décide que le paiement doit être effectué et, à l'étape 2, le contrôle est transféré au fournisseur de paiement (App Store). Étape 3: l'utilisateur reçoit un formulaire pour effectuer un paiement. Étape 4: l'utilisateur fournit des données pour le paiement. Étape 5: le fournisseur finalise la transaction et communique le résultat à l'application en renvoyant un reçu contenant des informations complètes sur l'achat (date, service, statut, etc.). Étape 6: le chèque, complété par des données utilisateur, est envoyé au serveur pour traitement. Le serveur traite les données de contrôle et génère une notification push pour l'application à la septième étape. Dans la huitième étape, la notification est montrée à l'utilisateur.

Le problème est que les étapes 3, 4 et 5 sont effectuées du côté du prestataire de paiement, ne sont pratiquement pas contrôlées par nous et peuvent avoir différentes variantes. Ainsi, le processus n'a pas réellement une structure linéaire, comme le montre la figure 2, mais une ramification (voir la figure 4), et chaque branche doit être gérée différemment par l'application.


Figure 4. Branchement d'un diagramme d'état de paiement unique

L'achat d'abonnements commence de la même manière qu'un paiement unique, mais un contrôle plus poussé du processus est assez difficile à contrôler.


Figure 5. États d'abonnement gérés en externe

Permettez-moi de vous rappeler que l'abonnement Apple, que nous considérons comme un exemple, est géré en externe. Cela signifie que l'utilisateur après l'achat peut le gérer de manière asynchrone: fermer, modifier la date d'expiration, demander un remboursement. Nous le voyons à l'étape 9. Puisque l'action se déroule en dehors de notre système, dans la figure, je l'ai marquée avec une ligne pointillée.

À l'étape 10, l'App Store peut modifier l'état de l'abonnement: renouveler, fermer, saisir le délai de grâce dans la fenêtre.

Pour que nous puissions savoir dans quel état se trouve l'abonnement, il y a l'étape 11, qui est spécifique aux agrégateurs tels que l'App Store et Google Wallet. À cette étape, le système envoie un jeton, qui est utilisé comme reçu reçu au tout début lors de l'achat d'un abonnement ou après son renouvellement précédent.

L'étape 12 est la réponse du fournisseur. Nous recevons un chèque avec l'état actuel de l'abonnement. Le résultat de cette étape dépend des étapes asynchrones 9 et 10.

À l'automne 2018, Apple for all a mis en place un mécanisme de notifications de serveur à serveur , qui vous permet de notifier les changements survenus avec un abonnement. La réception d'une telle notification est indiquée à l'étape 13. Pour la plupart des autres fournisseurs, le mécanisme de notification de serveur à serveur est le seul, de sorte que l'on peut faire valoir que l'exemple d'Apple couvre toute la variété des cas. Dans le cas d'autres fournisseurs, l'étape 13 vous permet d'exclure les étapes 11 et 12 du schéma.

À l'étape 14, le serveur génère une réponse pour que l'application modifie l'état de l'abonnement.

Ainsi, nous avons obtenu un graphique complet des états qui doivent être passés afin de vérifier les services payants.


Figure 6. Processus complet de modification des états de paiement (à l'aide d'un exemple d'abonnement géré en externe)

Les parties que nous ne contrôlons pas dans notre système sont colorées en orange et ce sont des boîtes noires pour nous.

Méthodes de test de facturation

Ainsi, le principal problème technique lors du test des services payants est la présence de «boîtes noires», dont nous contrôlons très peu les états. Cela définit un ensemble de méthodes qui peuvent couvrir toute la variété des cas.

Il n'y a pas beaucoup de ces méthodes, et nous les avons divisées en trois catégories: les paiements réels, les bacs à sable et l'élimination des dépendances externes des "boîtes noires".

Paiements réels

Les paiements réels en tant que méthode d'essai sont bons dans la mesure où ils donnent une idée claire de l'état de l'intégration. Une erreur lors d'un paiement réel est une preuve inconditionnelle d'un bug.

Sinon, les paiements réels sont mauvais. Tout d'abord, cela coûte cher: il est évident que pour effectuer un vrai paiement, il faut dépenser de l'argent réel. Vous vous trompez si vous pensez qu'en fin de compte, le montant total sera restitué à l'entreprise: tout d'abord, les prestataires facturent des frais pour chaque transaction, dont la taille, comme décrit ci-dessus, dépend de la cote de risque de l'organisation et peut atteindre 40% (et même plus) ; deuxièmement, vous risquez de perdre de l'argent lorsque vous testez des paiements dans d'autres pays en raison de l'écart de change - la différence entre les taux d'achat et de vente de la devise (vous effectuerez l'achat au taux de vente de devises étrangères de la banque, et le retour se fera au taux d'achat).

En outre, cette méthode peut prendre beaucoup de temps, car vous devez attendre la fin de la période de renouvellement de l'abonnement, la fin des périodes de grâce, et cela peut prendre des mois.

Bacs à sable

Les bacs à sable sont magnifiques. En fait, c'est la même fonctionnalité qu'un fournisseur de paiement nous donne dans le cas d'un paiement réel, mais sans dépenser de l'argent réel. Il est entièrement pris en charge par le fournisseur, ce qui signifie que l'intégration avec le bac à sable est bon marché.

Le problème de la longueur des tests dans le temps est résolu, en règle générale, à l'aide de diverses astuces. Par exemple, le sandbox de l'App Store utilise la conversion d'expiration d'abonnement suivante.

Tableau 1. Le ratio de la période de validité d'un abonnement réel et d'un abonnement dans le bac à sable d'Apple

Les abonnements Google Wallet sandbox par défaut sont répertoriés dans le tableau 2 et peuvent être configurés dans la console du vendeur.

Tableau 2. Définition de la durée d'un abonnement dans le sandbox de Google

Apple, Google , - . ., 3.

3. Google

-: App Store , Google Wallet Play Store.

, - . , 70 , Badoo, . Adyen PayPal. , ( Google Wallet), ( App Store Fortumo). , .


7.

, — , , . : , .

— (. . 8). , - +7111-111-11-11 . +7111-111-11-12 , « ».


8.

— ( ) (. . 9). . ( ), .


9.

— (. . 10), .


10.

, , . (, , ) . , , , , .

. 3, 4, 5 : , . - : , — , — . « ».


11. ( App Store)

, (, ). — , . . , , , . , . , .

. , ? :

• — ?
  
• end-to-end — : - ?
  
• — : , .
  

.


4.

. . . , . : , .

. , , Apple Google, . ( ). end-to-end : . , , .

, , — . . . : .

, , .

, . .

: . , , — .

, : — , , ; — : .


12.

, , , , .

, 12, Badoo.

. . QA- . , . , - , , . , .

: .

, , — . , Apple . . , . : - .

— , . -, . -, , -, , .

— : , Apple . 1 — , .

. , . , - .

, ( ).

Conclusions

1. , .
   
2. ( ) . , .
   
3. « » , . - — . , : , — , — .
   
4. Lorsque vous utilisez des faux, des mokas et des talons, il est important de se rappeler qu'il s'agit de véritables modèles de paiement et, comme tout modèle, ils ont un degré d'approximation de la réalité et des risques. Ces risques doivent être reconnus et couverts soit par des paiements en nombre, soit par des contrôles supplémentaires.
   

À propos de la façon dont nous avons réussi à réaliser une automatisation stable et peu coûteuse des tests de services payants dans une application iOS, nous le dirons dans le prochain article .

Merci de votre attention! Tous les gros profits et moins de bugs!