Le projet
Sur ARDUX, le frein à l'achat n'est pas le catalogue mais le règlement : la majorité des clients n'a pas de carte bancaire internationale. ARDUX Pay est la brique de paiement qui répond à ce frein, en branchant le tunnel de commande sur les deux opérateurs mobile money dominants du marché, Wave et Orange Money.
Les deux parcours n'ont rien en commun côté client. Orange Money repose sur un geste que l'utilisateur connaît déjà : il compose un code USSD depuis son téléphone (#144#391*code secret OM#), reçoit un code de validation à 4 chiffres par SMS, puis saisit son numéro et ce code dans la page de paiement pour valider le montant en FCFA. Wave, lui, passe par son propre écran de confirmation. Le rôle d'ARDUX Pay est d'unifier ces deux flux derrière une même page de paiement et un même cycle de vie de commande — aucun identifiant bancaire ne transite par la plateforme, et le client ne quitte jamais son tunnel de commande.
Mon rôle sur le projet
J'ai développé le tunnel de paiement côté frontend et son intégration au parcours de commande ARDUX.
- Conception de la page de paiement : choix de l'opérateur, instructions propres à chaque flux, saisie et confirmation du montant
- Intégration des flux Wave et Orange Money au tunnel de commande existant
- Abstraction des deux opérateurs derrière un même contrat côté interface, pour que le reste du tunnel ignore le moyen de paiement choisi
- Gestion des états de la transaction : attente de confirmation, code invalide, expiration, échec de débit
- Rapprochement du paiement et de la commande en base avec Prisma sur PostgreSQL
- Rédaction des messages d'accompagnement : le parcours Orange Money se déroulant hors navigateur, l'écran doit guider seul, sans support
Défis techniques
- Unifier deux parcours de paiement qui ne se ressemblent pas — un code USSD hors navigateur d'un côté, une confirmation opérateur de l'autre — derrière une seule interface et un seul modèle de transaction
- Guider un paiement qui se déroule en partie en dehors du navigateur : l'interface doit expliquer un geste USSD sans pouvoir le contrôler
- Traiter une confirmation asynchrone : le statut réel du débit ne remonte pas au moment où l'utilisateur valide le formulaire
- Garantir l'unicité du règlement d'une commande : un code de validation ne doit pouvoir débiter qu'une seule fois, même en cas de double soumission
- Rendre lisibles des échecs venus d'un opérateur tiers (solde insuffisant, code expiré, délai dépassé) sans exposer de détails techniques au client
- Préserver la conversion sur un parcours qui impose un aller-retour téléphone : chaque étape superflue est un abandon