« Le paiement est-il en train de planter ? » Cette question, posée en interne après plusieurs signalements de donateurs abandonnant leur parcours de don juste après avoir saisi leurs coordonnées bancaires, résume bien le problème observé sur cette plateforme de collecte pour une association. Le parcours de don, techniquement fonctionnel de bout en bout, semblait figer l’écran pendant près de cinq secondes au moment précis où la banque du donateur déclenche une vérification 3D Secure.
Diagnostic : une chaîne de redirections invisible pour l’utilisateur
L’authentification 3D Secure, imposée par la directive européenne DSP2 sur la majorité des paiements par carte, fonctionne par une série de redirections : le navigateur du donateur est envoyé vers une page hébergée par la banque émettrice, qui affiche un défi d’authentification (code reçu par SMS, application bancaire), avant de rediriger à nouveau vers le site marchand une fois la vérification validée. Sur ce parcours, l’intégration Stripe utilisée gérait cette chaîne de redirections dans un conteneur invisible (une iframe cachée) le temps que la première étape de la banque se charge, ce qui laissait l’écran visible du donateur strictement identique pendant plusieurs secondes, sans aucun indice visuel de ce qui se passait.
Techniquement, rien ne bloquait : chaque redirection s’exécutait normalement, dans les délais attendus pour ce type d’échange entre le site marchand, Stripe, et la banque émettrice. Le problème n’était pas un ralentissement réel, mais un silence perceptif : le donateur voyait un écran figé et en concluait, à raison, que quelque chose n’allait pas.
Mesure du temps perçu comme figé
Un chronométrage manuel, reproduit sur une dizaine de parcours de test avec différentes banques, a mesuré un temps moyen de 4,8 secondes entre le clic sur le bouton de paiement et l’apparition visible du premier écran d’authentification de la banque, temps pendant lequel l’interface du site ne montrait strictement aucun changement, pas même une simple animation de chargement.
Correctif : un affichage progressif de chaque étape
La correction n’a pas touché au flux 3D Secure lui-même, techniquement conforme et non modifiable côté site marchand puisqu’il obéit à une norme bancaire. Elle a consisté à rendre visibles, une par une, les étapes réellement en cours grâce aux événements exposés par le SDK Stripe.js, plutôt que de masquer entièrement le processus derrière un écran statique :
const { error, paymentIntent } = await stripe.confirmCardPayment(
clientSecret,
{ payment_method: idMoyenPaiement }
);
// Affichage progressif basé sur le statut retourné
stripe.registerAppInfo({ name: 'don-association' });
afficherEtape( 'Connexion sécurisée à votre banque…' );
stripe.confirmCardPayment( clientSecret, {
payment_method: idMoyenPaiement
} ).then( ( result ) => {
if ( result.paymentIntent && result.paymentIntent.status === 'requires_action' ) {
afficherEtape( 'Vérification en cours par votre banque…' );
}
});
Concrètement, dès le déclenchement du paiement, un message « Connexion sécurisée à votre banque… » apparaît immédiatement, remplacé par « Vérification en cours par votre banque… » dès que Stripe signale le passage en authentification renforcée, puis par un message de confirmation une fois le don validé. Aucune de ces étapes n’ajoute de délai réel : elles se contentent de rendre visible ce qui se passait déjà, silencieusement, en arrière-plan.
Résultat
Le temps réel du parcours de don n’a pas changé d’une seconde : la contrainte réglementaire de la 3D Secure reste incompressible. Ce qui a changé, c’est le taux d’abandon mesuré sur cette étape précise, qui a diminué de façon nette après la mise en place de cet affichage progressif, les donateurs ne quittant plus le parcours en pensant qu’il s’était interrompu.
- Ne jamais laisser un écran totalement statique pendant une étape bancaire obligatoire, même de quelques secondes.
- S’appuyer sur les événements exposés par le SDK de paiement plutôt que d’inventer un minuteur arbitraire déconnecté du déroulement réel.
- Tester le parcours avec plusieurs banques différentes, les délais réels de la première étape variant sensiblement d’un émetteur à l’autre.
Un parcours de paiement qui respecte toutes les règles de sécurité peut encore échouer si le donateur croit, à tort, qu’il est cassé. La perception compte autant que la conformité.
En résumé
Le ralentissement perçu sur ce parcours de don n’était pas un problème de performance au sens strict, mais un défaut d’affichage pendant une étape bancaire obligatoire et incompressible. En rendant visibles, étape par étape, les événements déjà exposés par le SDK Stripe, le temps réel du parcours n’a pas bougé, mais le sentiment de blocage a disparu, avec un effet mesurable sur le taux d’abandon.
