Est-il difficile de créer sa propre application Tap to Pay ? (Nous avons essayé)

Plus difficile que ne le laissent entendre les brochures des SDK, et la difficulté ne réside généralement pas dans le code. Nous avons intégré le Tap to Pay dans l'application Final POS, cette réponse vient donc de l'expérience concrète, pas de la lecture de documentations. Si vous souhaitez créer votre propre application Tap to Pay, préparez-vous à un court projet logiciel enveloppé dans un projet d'autorisations beaucoup plus long : un partenariat avec un processeur de paiement, une autorisation manuelle d'Apple ou une évaluation en laboratoire sur Android, et un examen de l'application, le tout avant votre premier paiement réel.

Un petit avertissement : les règles des plateformes et du secteur des cartes bancaires changent souvent. Tout ce qui suit est exact au moment de la publication, considérez donc ces détails comme un instantané.

Que fait réellement une application Tap to Pay ?

Le Tap to Pay transforme le téléphone lui-même en lecteur de carte. Pas de terminal, pas de dongle : le client passe une carte sans contact ou un portefeuille mobile comme Apple Pay ou Google Pay directement sur l'appareil du commerçant, et le paiement passe par la puce NFC du téléphone (la radio à courte portée utilisée pour le sans-contact). Si la terminologie vous semble floue, nous avons détaillé la différence entre les paiements mobiles sans contact et le Tap to Pay sur mobile.

Voici le piège. Lire un tag NFC est un simple projet de week-end ; les amateurs le font constamment. Lire une carte de paiement est une tout autre affaire. Les cartes parlent l'EMV (le protocole à puce du secteur des cartes), les données de carte doivent rester cryptées de bout en bout, et seul un logiciel certifié est autorisé à les manipuler.

Pourquoi ne pouvez-vous pas simplement lire la carte vous-même ?

Parce que chaque couche de la pile nécessite une autorisation avant que votre code ne soit autorisé à s'exécuter publiquement.

• Apple ne donne pas aux applications un accès brut au NFC de paiement. Vous devez utiliser son framework ProximityReader, qui nécessite une autorisation Tap to Pay sur iPhone (une permission spéciale accordée par Apple au cas par cas). Apple exige également que vous vous intégriez à un prestataire de services de paiement (PSP) pris en charge (l'entreprise qui transfère réellement l'argent). Le PSP fournit les configurations de lecteur certifiées chargées sur l'appareil du commerçant et assume la charge de la certification.

• Android offre aux développeurs un accès NFC plus ouvert, mais une application d'acceptation des paiements doit tout de même être évaluée par un laboratoire indépendant reconnu par le PCI par rapport à la norme PCI MPoC (les règles de sécurité du secteur des cartes pour les téléphones faisant office de terminaux de paiement).

• Sous ces deux plateformes, vous avez besoin d'une relation d'acquisition : un processeur prêt à régler les fonds pour vos commerçants, en respectant les règles des réseaux de cartes.

Rien de tout cela ne peut être forcé en écrivant un meilleur code. Il s'agit de paperasse, de contrats et de files d'attente d'examen.

À quoi ressemble le parcours d'approbation sur iPhone ?

Selon les exigences publiées par Apple, le parcours est le suivant : posséder un compte Apple Developer de type organisation (le titulaire du compte dépose personnellement la demande), s'associer à un PSP pris en charge pour vos régions, demander l'autorisation, intégrer l'API ProximityReader ou le SDK de votre PSP, suivre les directives de conception d'Apple pour l'écran de paiement et soumettre l'application pour examen. La documentation d'Apple précise également que la fonctionnalité ne fonctionne que dans les pays et régions pris en charge, la disponibilité elle-même étant donc décidée pour vous, marché par marché.

Relisez cette liste en tant que fondateur ou commerçant plutôt qu'en tant que développeur. Aucune de ces étapes ne consiste à « coder la fonctionnalité ». La fonctionnalité est la partie facile ; l'autorisation est le fossé défensif.

Où se concentre le travail une fois que le paiement fonctionne ?

Un paiement sans contact approuvé vous donne un paiement, pas un point de vente. Dès que l'argent circule, tout ce qui entoure le paiement doit être correct : le panier sur lequel il s'appuie, les taxes sur le reçu, le parcours de remboursement et les rapports de rapprochement (chaque dollar associé à une vente, chaque jour). Nous avons constaté le même écart lorsque nous avons cherché à savoir si l'on peut créer un POS avec Lovable ou Replit : générer une interface est rapide, mais c'est la couche commerciale sous-jacente qui prend du temps.

Le Tap to Pay apporte également ses propres particularités opérationnelles. Dans notre implémentation, la vente doit être enregistrée sur le même appareil que celui qui encaisse le paiement, et cela ne fonctionne que dans l'application native, jamais dans un navigateur. Des contraintes comme celle-ci ne figurent dans aucune brochure. Vous les découvrez, vous concevez des solutions de contournement, puis vous rédigez l'article d'aide. Et lorsqu'un téléphone sur le comptoir ne suffit plus, vous devez de toute façon prendre de vraies décisions matérielles.

Alors, est-il difficile de créer sa propre application Tap to Pay ?

Difficile d'une manière bien précise : le codage représente la plus petite partie, tandis que le partenariat avec le processeur, l'autorisation d'Apple, la certification en laboratoire sur Android et l'examen de l'application constituent l'essentiel, et aucun d'entre eux ne dépend des efforts d'ingénierie. Pour nous, cela en valait la peine, car une plateforme POS répartit ce coût sur chaque commerçant qui l'utilise. Le Tap to Pay est désormais un bouton de paiement que nos commerçants activent, et accepter un paiement Tap to Pay est une routine de comptoir en cinq étapes. Si les paiements sont votre produit, ce parcours du combattant est le prix d'entrée. Si les paiements sont simplement le moyen de vous faire payer, créer votre propre application Tap to Pay n'a aucun sens financier ; la version finale existe déjà au sein des applications POS, et les frais sont le véritable élément de comparaison.

Règle d'or : si une fonctionnalité a besoin de l'autorisation de quelqu'un d'autre pour exister, aucun code astucieux ne pourra la contourner.