Application de paiement mobile : 5 décisions techniques pour la fintech

Une application de paiement mobile pour services financiers ne se gagne pas sur les features. Le wallet bien dessiné, l'onboarding fluide, le sélecteur de carte animé : ce sont des conditions nécessaires, pas suffisantes. Ce qui distingue un projet qui passe en production sereinement d'un projet qui explose au premier pic de trafic, c'est l'exécution sur quatre ou cinq décisions structurantes que beaucoup d'équipes sous-estiment au cadrage.

Selon le Bulletin de la Banque de France n° 261/5 (novembre-décembre 2025), le paiement par carte via appareil mobile a progressé de 53,6 % en volume en 2024 pour atteindre 2,4 milliards d'opérations et 56 milliards d'euros échangés. Le mode représente désormais 10 % des paiements par carte en France et 15 % en proximité, contre 7 % et 11 % un an plus tôt. Le marché est en train de basculer, et chaque néo-banque, fintech ou plateforme de services financiers qui se lance se retrouve sur le même terrain technique.

Cet article s'adresse aux CTO et dirigeants tech qui pilotent ce type de projet. Il ne couvre pas l'UI, le marketing ou la roadmap produit. Il couvre les arbitrages techniques qui décident, dans les six premiers mois après le lancement, si l'équipe vit un cauchemar comptable ou si elle peut se concentrer sur la croissance.

Prérequis avant d'attaquer le sujet

Avant même de discuter PSP ou framework mobile, vérifier que ces éléments sont en place ou planifiés :

• Une équipe back-end senior capable d'opérer une base relationnelle (Postgres de préférence) avec contraintes d'unicité, transactions explicites et observabilité.
• Un statut juridique compatible avec l'activité visée : agent prestataire de services de paiement, intermédiaire, ou simple e-commerçant. Les obligations LCB-FT changent radicalement.
• Un budget conformité non-symbolique : compter 30 à 80 k€ la première année pour outiller proprement KYC, monitoring transactionnel et reporting réglementaire.
• Un domaine d'usage clair : encaissement pour compte de tiers, paiement de service propre, ou wallet avec stockage de fonds. Les trois imposent des choix de socle différents.

Sans ces fondations, les décisions ci-dessous ne sont pas exploitables. Mieux vaut prendre deux mois de cadrage que six mois de refonte après un premier audit ACPR.

1. Choisir son socle PSP avant son framework mobile

L'erreur la plus fréquente est de choisir React Native, Flutter ou Swift en premier, puis de chercher le PSP qui s'intègre. C'est l'inverse. Le PSP conditionne le statut réglementaire, les frais unitaires, les SDKs disponibles, le support du 3DS2 natif et la portée internationale. Le framework mobile vient après.

Lecture rapide : Stripe et Adyen sont les seuls à proposer un parcours SDK mobile premier-class de bout en bout. Mangopay, Lemonway et Treezor ciblent les marketplaces et le banking-as-a-service ; sur mobile, on construit l'UI soi-même et on parle à leur API REST. Treezor reste imbattable côté agréments en France (Société Générale derrière), Lemonway sur les marketplaces régulées (Circlub, plateformes d'investissement).

2. SCA et 3DS2, l'enjeu d'UX numéro un

Depuis le 14 septembre 2019, la directive DSP2 et les RTS de l'EBA imposent l'authentification forte du client (SCA) pour toute transaction électronique soumise à exemption négociable. Le mécanisme technique standard est 3D Secure 2, conçu pour réduire la friction du protocole historique 3DS1.

Les chiffres du passage 3DS1 vers 3DS2 sont sans appel. Sur 3DS1, l'authentification prenait 45 à 60 secondes en moyenne et générait 15 à 25 % d'abandon de panier. Sur 3DS2, l'authentification descend sous les 5 secondes et l'abandon tombe entre 2 et 5 % (données Visa, sources : 2accept.net, Forter). Visa documente publiquement une baisse de 70 % d'abandon de panier sur les marchands ayant basculé en 3DS2 propre.

Mais le détail UX est ailleurs : le flux frictionless (l'émetteur authentifie via signaux de risque sans interaction utilisateur) ne couvre pas tout. Sur une étude Forter couvrant Amazon et Microsoft en France, le frictionless 3DS réduit le taux d'autorisation d'environ 10 % par rapport à un challenge réussi, et les taux d'abandon sur challenge approchent encore 40 à 71 % selon les marchés européens. Côté Stripe, l'usage des exemptions TRA (Transaction Risk Analysis) permet d'éviter une partie de la SCA, à condition que le PSP maintienne un taux de fraude inférieur à 0,13 % sur les transactions sous 100 €, 0,06 % sous 250 €, 0,01 % sous 500 € (source officielle : docs.stripe.com).

Concrètement, ce qu'il faut tester avant le lancement :

• Le SDK PSP affiche bien le challenge 3DS2 en natif (pas une WebView qui se redirige), sinon Apple et Google rejettent la review.
• Les cartes de test du PSP couvrent les quatre cas : frictionless succès, frictionless échec, challenge succès, challenge timeout. Pas seulement le happy path.
• Le code applicatif sait distinguer un échec 3DS2 d'un échec d'autorisation bancaire. Les deux remontent par des codes différents, et l'expérience utilisateur doit l'être aussi.

3. Idempotence des webhooks et réconciliation comptable

C'est la section la plus négligée du cadrage technique, et c'est celle qui produit le plus d'incidents en production. La règle à intérioriser : la vérité comptable d'une transaction arrive dans un webhook, pas dans la réponse synchrone de l'API. La réponse au POST /payment_intents/confirm dit ce que le PSP croyait au moment de la réponse. Le payment_intent.succeeded dans le webhook dit ce qui s'est réellement passé une fois l'autorisation propagée.

Sans pipeline robuste, on récupère trois classes de bug :

1. Doubles paiements : le client clique deux fois sur "Payer", le SDK envoie deux requêtes sans clé d'idempotence, deux PaymentIntents sont créés, deux débits.
2. Statuts divergents : la réponse synchrone dit "pending", le webhook arrive en 200 ms mais on ne l'a pas reçu (DNS, timeout, 502 transient), le client voit "en attente" alors que le débit est passé.
3. Réplays non-idempotents : Stripe redélivre un webhook qui a renvoyé un 5xx, ou même un événement qui a réussi mais que le PSP a marqué en échec, et on l'applique deux fois sur le ledger.

Le pattern de base est connu, mais rarement implémenté proprement de bout en bout :

CREATE TABLE payment_events (
  event_id TEXT PRIMARY KEY,
  source TEXT NOT NULL,
  event_type TEXT NOT NULL,
  payload JSONB NOT NULL,
  received_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  processed_at TIMESTAMPTZ,
  status TEXT NOT NULL DEFAULT 'received'
);
CREATE INDEX ON payment_events (status, received_at)
  WHERE status = 'received';

La clé primaire est l'event_id du PSP (evt_xxx chez Stripe, notificationId chez Adyen). L'INSERT se fait avec ON CONFLICT (event_id) DO NOTHING. Si l'INSERT n'affecte aucune ligne, c'est un doublon, on renvoie 200 immédiatement au PSP pour qu'il arrête de retry. Si l'INSERT réussit, on enqueue l'event_id dans une file de traitement (Redis Streams, SQS, ou table de jobs Postgres avec FOR UPDATE SKIP LOCKED). Un worker idempotent consomme, applique l'état comptable dans une transaction, marque l'événement processed, et écrit dans un journal d'audit append-only.

Le pipeline complet ressemble à ça :

sequenceDiagram
    participant PSP as PSP Stripe ou Adyen
    participant H as Webhook handler
    participant DB as Table payment_events
    participant Q as File de traitement
    participant W as Worker idempotent
    participant L as Ledger
    participant A as Audit log

    PSP->>H: POST /webhooks avec event_id et signature HMAC
    H->>H: Vérifie signature
    H->>DB: INSERT ON CONFLICT DO NOTHING
    alt Nouvel évènement
        DB-->>H: inserted
        H->>Q: enqueue event_id
        H-->>PSP: 200 OK
        Q->>W: dequeue
        W->>DB: SELECT payload, status FOR UPDATE
        W->>L: BEGIN, UPDATE payment, COMMIT
        W->>A: append event_id, before, after, who, when
        W->>DB: UPDATE status = processed
    else Évènement déjà vu
        DB-->>H: conflict
        H-->>PSP: 200 OK
    end

Le rapprochement comptable quotidien (PSP vs DB interne) doit être un job automatique avec rapport diffusé. Pas un rituel manuel le lundi matin.

4. KYC et AML, la conformité LCB-FT n'est pas optionnelle

Tout service qui ouvre un compte, encaisse pour compte de tiers ou stocke de la monnaie électronique tombe sous le régime LCB-FT (lutte contre le blanchiment des capitaux et le financement du terrorisme) supervisé par l'ACPR et alimenté par TRACFIN. Sanction de référence : la décision ACPR de décembre 2020 contre Mangopay (cité par le rapport Skadden 2021), qui rappelle que les écarts sur le screening sanctions et le contrôle continu coûtent vite plusieurs centaines de milliers d'euros.

Quatre familles de fournisseurs dominent le marché européen, avec des compromis nets :

• Sumsub : couverture la plus large (6 000+ types de documents, 220+ pays), pass rate de 96,39 % sur la France selon leurs propres données. Bundle KYC + AML monitoring intégré. Onboarding plus long (jours), pricing par verification dégressif.
• Veriff : temps de décision moyen de 6 secondes (vs 20 à 30 s chez Sumsub), 230+ pays, focus UX sur le drop-off. Plus cher à l'unité, moins de tooling AML transactionnel natif.
• Onfido (Entrust) : plus mature sur les workflows no-code et l'A/B testing des parcours. Faible sur le monitoring continu sans add-on.
• Jumio : leader historique sur les industries lourdement régulées (banking, crypto, prêt). Setup en semaines, pricing premium.

Le bon framework de décision : KYC light (document + selfie) suffit pour les comptes basiques sous seuil, KYC full (justificatif de domicile + screening PEP/sanctions) est obligatoire au-delà de 1 000 € de flux ou pour tout produit de crédit. Le monitoring transactionnel temps réel (typologies suspectes, ruptures de comportement) est non-négociable dès qu'on touche au virement instantané ou aux paiements de tiers à tiers : c'est précisément le risque qui explose en 2025 avec l'alignement tarifaire SEPA Instant.

5. React Native ou natif, le faux débat de la sécurité

Le mythe à démonter : "Pour une app de paiement, le natif est obligatoire pour des raisons de sécurité." C'est paresseux et techniquement faux. La surface d'attaque d'une app de paiement est dans trois zones : le SDK PSP (qui est natif et exposé via le bridge React Native), le code backend (qui valide signature webhook, idempotence, autorisations), et le device lui-même (root, debugger, repackaging). La couche UI au-dessus du SDK n'apporte rien de critique côté sécurité, qu'elle soit en Swift, Kotlin, Flutter ou React Native.

Stripe maintient officiellement @stripe/stripe-react-native avec parité de features sur PaymentSheet, Apple Pay, Google Pay, 3DS2, et même Tap to Pay sur iPhone dans certains pays. Adyen propose des composants React Native officiels pour le drop-in card et Google Pay, en évolution rapide. Primer, Stripe Terminal et plusieurs autres acteurs ont des SDKs RN supportés.

Le vrai débat n'est pas "natif ou React Native". C'est "un seul codebase mobile maintenu par 2 devs" ou "deux codebases natifs maintenus par 4 devs". La réponse dépend de la trajectoire produit, pas d'un dogme sécurité.

Checklist pré-lancement

Avant la mise en production publique, vérifier :

1. Webhooks idempotents + table payment_events avec PRIMARY KEY sur l'event_id du PSP, signature HMAC vérifiée à chaque réception.
2. 3DS2 SDK testé sur les cartes de test du PSP, couvrant frictionless succès, frictionless échec, challenge succès, challenge timeout.
3. PCI-DSS scope vérifié : aucun PAN (numéro de carte complet) stocké dans la base interne, tokenisation via le PSP de bout en bout.
4. KYC intégré avec workflow de revue manuelle pour les cas border (documents flous, scoring intermédiaire, listes de surveillance).
5. Observabilité : tracing distribué complet sur le flow paiement (init, confirm, webhook, ledger), alerte automatique sur taux d'échec > seuil par type d'opération.
6. Rapprochement comptable quotidien automatisé entre l'API du PSP et la DB interne, rapport diffusé à l'équipe finance.
7. Runbook d'incident : qui répond à 3 h du matin si le PSP tombe ou si le taux d'erreur explose, avec procédure de bascule documentée et testée.

Si l'un de ces sept items n'est pas couvert, le lancement est prématuré. C'est aussi simple que ça.

Conclusion

Une application de paiement mobile pour services financiers est un projet où l'écart entre une exécution moyenne et une exécution senior se mesure en six chiffres sur la première année d'exploitation. Le bon PSP, le bon flux 3DS2, le bon pattern d'idempotence et le bon KYC valent souvent plus que le bon framework mobile.

L'agence Platane (https://platane.io) accompagne des PME et fintech sur ce type d'intégration depuis plusieurs années, dont la plateforme Astory Finance pour la gestion d'échéances Stripe récurrentes en contexte de leasing d'œuvres d'art. Notre cluster Kubernetes Scaleway en France, avec stream WAL répliqué chez OVH, héberge ce type de plateforme depuis 2022 sans incident comptable majeur. Le détail des choix techniques sur Astory est consultable sur https://platane.io/fr/references/astory-finance.