Regardez quelqu'un acheter sur son téléphone avec une carte. Il cherche son portefeuille, lit seize chiffres, en tape un de travers, recommence, cherche le CVV — puis échoue à l'authentification parce que le SMS est parti sur le téléphone qu'il est déjà en train d'utiliser.
Maintenant, le même achat avec un wallet. Double-clic, pouce, terminé.
Cette différence est la raison pour laquelle l'intégration des paiements est un projet de conversion, pas un chantier de plomberie.
La première décision n'est pas technique
Avant tout travail d'intégration, établissez ce que vous vendez — car pour les apps iOS et Android, c'est cela qui détermine si vous avez seulement le choix.
Les biens numériques consommés dans l'app — abonnements, fonctions premium, monnaie de jeu — doivent en règle générale passer par le système d'achat intégré de la plateforme, aux taux de commission de la plateforme. Il y a eu du mouvement réglementaire et certaines juridictions autorisent désormais des alternatives, mais le défaut reste la facturation plateforme, et les règles varient selon les marchés.
Les biens physiques et les services du monde réel — commerce, livraison de repas, VTC, billetterie — utilisent un traitement de paiement ordinaire, aux frais de carte ordinaires. Vous gardez le contrôle et payez une fraction du taux plateforme.
Se tromper là-dessus n'est pas un bug technique. C'est un rejet de l'app — et les tentatives répétées de contournement mettent la fiche en danger. Si votre produit est proche de la frontière, lisez les directives actuelles plutôt que de vous fier à ce qu'un concurrent semble faire.
Ce que les wallets changent vraiment
Apple Pay et Google Pay ne sont pas des processeurs de paiement. Ce sont des moyens plus rapides pour un client de transmettre des données de carte qui existent déjà sur l'appareil, tokenisées, de sorte que le numéro brut ne vous parvient jamais.
Deux conséquences. D'abord, il vous faut toujours un processeur derrière — le wallet fournit l'identifiant, le processeur déplace l'argent. Ensuite, et c'est plus utile : la tokenisation signifie que vous ne manipulez pas directement de données de carte, ce qui rétrécit énormément votre exposition à la conformité.
L'effet sur la conversion est la raison de s'y mettre. Supprimer la saisie manuelle supprime l'étape où les paiements mobiles sont abandonnés — et l'amélioration est maximale exactement là où ça fait le plus mal : les primo-acheteurs, sur petit écran, sans carte enregistrée.
Fig. — Le numéro de carte ne touche jamais votre code. C'est l'essentiel du gain de conformité.
Choisir un processeur
Les taux comptent moins qu'on ne le croit à petit volume, et énormément à grand volume — et le pourcentage vitrine est rarement le coût complet.
Demandez les suppléments : marge de conversion de devises, frais de contestation, délais de versement, gestion des remboursements, et si le taux annoncé s'applique au mix de cartes que vous voyez réellement. Une activité qui vend à des particuliers porteurs de cartes premium paie sensiblement plus que la vitrine.
Demandez les moyens de paiement locaux. La couverture carte n'est pas tout le marché dans la plupart des pays — TWINT en Suisse, UPI en Inde, iDEAL aux Pays-Bas, divers schémas de virement et de wallet ailleurs. Un processeur sans le moyen local dominant de votre marché vous fait perdre des clients qui, simplement, ne peuvent pas payer commodément.
Et vérifiez la qualité du SDK, parce que vous allez y vivre : support natif des deux plateformes, environnement de test qui fonctionne, taxonomie d'erreurs sensée, et une documentation qui couvre les cas d'échec plutôt que le seul chemin heureux.
La conformité qu'on ne saute pas
PCI DSS s'applique dès qu'une donnée de carte touche vos systèmes. La bonne stratégie : faire en sorte qu'elle ne les touche jamais — utiliser le SDK du processeur pour que les données aillent de l'appareil au processeur sans passer par vos serveurs. Cela réduit vos obligations au palier le plus léger, et c'est la décision d'architecture la plus précieuse de tout le projet.
L'authentification forte du client s'applique en Europe et de plus en plus ailleurs. Certaines transactions exigent un second facteur via 3-D Secure — votre parcours de paiement doit donc supporter d'être interrompu en plein milieu puis repris. Testez-le délibérément : c'est la source la plus fréquente des signalements « le paiement échoue parfois ».
La fiscalité est réellement compliquée pour les services numériques vendus au-delà des frontières, et ce n'est pas un sujet à régler après coup. Elle change l'affichage des prix, la facturation — et parfois la possibilité même de vendre sur un marché.
Les abonnements sont un problème à part
La facturation récurrente ressemble à une variante du paiement unique et ne se comporte pas du tout pareil.
Les cartes expirent, sont remplacées après une fraude, et sont refusées pour des raisons qui se règlent seules en un jour. Une part significative du churn d'abonnement est involontaire — des clients qui voulaient continuer à payer et dont le paiement a échoué en silence. Bien gérer cela s'appelle le dunning, et c'est surtout de la logique sans gloire : réessayer à un rythme sensé, prévenir le client par un canal qu'il lit vraiment, et garder le compte en période de grâce plutôt que d'annuler immédiatement.
Les services de mise à jour de cartes, proposés par la plupart des processeurs, rafraîchissent les identifiants stockés quand une banque réémet une carte. Ils coûtent peu et récupèrent plus qu'ils ne coûtent.
L'autre moitié, c'est l'état. Un abonnement peut être en essai, actif, en retard, en pause, résilié-mais-actif-jusqu'à-la-fin-de-période, ou expiré — et votre app doit afficher juste dans chaque cas. Les équipes qui modélisent cela en booléen découvrent le trou quand un client qui a résilié la semaine dernière perd l'accès trois semaines trop tôt et s'en plaint publiquement.
Et si vous êtes en facturation plateforme pour des biens numériques, le droit d'accès vit chez la plateforme plutôt que sur votre serveur — vous réconciliez donc leurs données de reçus avec vos propres registres. Cette réconciliation est un travail permanent, pas une tâche de lancement.
Où les implémentations échouent
Traiter le paiement comme un écran plutôt qu'une machine à états. Un paiement peut être en attente, autorisé, capturé, échoué, contesté ou remboursé — et l'app peut être tuée à n'importe quel point de la séquence. Concevez autour des états, pas autour du bouton.
Pas d'idempotence. Un utilisateur tape deux fois sur une connexion lente, ou l'app réessaie après un timeout — et il est débité deux fois. Les clés d'idempotence sur chaque requête de paiement ne sont pas optionnelles.
Faire confiance au client. Le montant, la devise et l'article se déterminent côté serveur depuis le panier — jamais acceptés depuis l'app. C'est l'erreur la plus dommageable et la plus courante de la catégorie.
Négliger les messages d'échec. « Paiement échoué » n'apprend rien au client et perd la vente. « Votre banque a refusé — essayez une autre carte ou contactez-la » en récupère une part significative.
Sauter les reçus et l'historique. Les clients s'attendent à voir ce qu'ils ont payé et quand. L'absence génère des tickets de support, pour toujours.
Aucun chemin de remboursement dans le produit. Si rembourser exige de se connecter au tableau de bord du processeur, les remboursements seront lents et mal consignés. Intégrez-les à votre propre outillage d'admin, avec le motif capturé — sinon votre support inventera un contournement que vous ne pourrez pas auditer.
Un ordre de travail sain
Commencez par les cartes via un seul processeur, montant déterminé côté serveur, idempotence, et une machine à états de paiement correctement modélisée. Rendez ça juste et ennuyeux.
Ajoutez ensuite les wallets — un travail modeste par-dessus une intégration existante, et la plus grande amélioration de conversion disponible.
Ajoutez les moyens locaux quand vous savez où sont réellement vos clients — guidé par l'endroit où les paiements sont abandonnés, pas par une carte du monde.
Testez avec de vraies cartes dans le monde réel avant le lancement, pas seulement en sandbox. Les sandbox modélisent le chemin heureux et quelques refus scriptés ; elles ne reproduisent pas le flux d'authentification d'une banque sur un vrai téléphone, avec un vrai SMS qui arrive pendant que votre app est en arrière-plan. Un petit pilote où le personnel achète de vrais articles à petit prix fait remonter plus de problèmes en un jour que quinze jours de sandbox.
Puis instrumentez : taux de tentative, taux de réussite, motifs d'échec, et où dans le parcours les gens partent. Sans cela, les problèmes de paiement sont invisibles — les clients ne déposent pas de ticket pour un panier abandonné. Ils ne reviennent simplement pas.
Des paiements qui tiennent aux marges, c'est le standard de nos réalisations — dites-nous où les vôtres fuient.
