Application mobile avec paiement en ligne au Maroc

Ajouter le paiement à une application existante

Votre application est en ligne, vos utilisateurs s’en servent, et l’argent se règle encore ailleurs : par virement, en espèces à la livraison, ou par un lien envoyé à la main. À chaque commande, un membre de votre équipe intervient. C’est précisément ce que l’ajout du paiement dans l’application supprime.

Nous partons de ce qui existe. Nous regardons comment votre application a été construite, ce qu’elle échange déjà avec votre serveur, et où le paiement doit se placer dans le parcours : au moment de la commande, à la confirmation d’un rendez-vous, au renouvellement d’un accès. Le travail se fait sur deux niveaux, dans l’application pour l’écran de paiement, et côté serveur pour la partie qui reçoit l’argent et confirme l’opération. Cette seconde partie est la même que pour l’intégration du paiement par API à votre logiciel métier, et elle sert ensuite à tous vos canaux.

Soyons clairs sur un point : l’ajout du paiement passe par une mise à jour de votre application, comme toute nouvelle fonctionnalité. Elle doit être publiée, et vos utilisateurs doivent l’installer. Nous vous disons dès le début ce que cela implique dans votre cas, et nous prévoyons la période pendant laquelle les deux versions circuleront.

Si vous voulez encaisser sans attendre cette publication, un lien de paiement envoyé par WhatsApp fait très bien la transition. Beaucoup de commerçants commencent ainsi, puis intègrent le paiement quand le volume le justifie.

Créer une nouvelle application prête à encaisser

Quand l’application n’existe pas encore, nous la construisons avec le paiement prévu dès la conception. Ce n’est pas un détail de calendrier. Une application pensée sans encaissement finit toujours par l’intégrer de travers, avec un écran ajouté à la fin et un parcours qui s’allonge.

Nous commençons par la version utile, pas par la version complète. Ce que votre client doit pouvoir faire, ce que vous devez voir de votre côté, et ce qui peut attendre la deuxième version. Une application de commande, de réservation, d’abonnement ou de service à domicile n’a pas besoin de vingt écrans pour rapporter de l’argent. Elle a besoin que les cinq écrans du parcours d’achat soient irréprochables.

Vous gardez la propriété du code et des comptes. C’est une question facile à oublier au moment de signer, et qui devient très importante deux ans plus tard, le jour où vous voulez changer de prestataire ou reprendre le développement en interne.

Android, iOS et Flutter

Nous développons avec Flutter : une seule base de code pour Android et iOS. Concrètement, vous financez un développement au lieu de deux, les corrections partent sur les deux plateformes en même temps, et le parcours de paiement se comporte de la même manière sur un téléphone Android d’entrée de gamme et sur un iPhone récent.

Si votre application existante a été écrite autrement, en natif Android ou iOS, ou avec un autre outil multiplateforme, nous nous adaptons. Réécrire une application qui fonctionne pour y ajouter un paiement serait une dépense difficile à justifier.

Nous testons sur des appareils réels et sur les réseaux que vos clients utilisent vraiment, y compris une connexion mobile faible, parce que c’est là que les paiements échouent sans que personne vous le signale.

Paiement dans l’application : ce que voit votre client

Du côté de votre client, tout doit paraître évident. Il arrive au récapitulatif, il voit le montant exact et ce qu’il achète, il appuie sur le bouton de paiement. L’écran de saisie de carte s’ouvre dans l’application, il entre ses numéros, il valide avec le code que sa banque lui envoie, et il revient à l’écran de confirmation.

Les détails qui rassurent comptent beaucoup à ce moment précis. Le montant toujours visible, le cadenas de la connexion sécurisée, la mention de la vérification 3-D Secure, un message clair quand la carte est refusée, et surtout aucun écran figé sans explication. Un client qui ne comprend pas ce qui se passe pendant trois secondes ferme l’application et vous appelle, ou n’achète pas.

Nous soignons aussi les cas de sortie. L’utilisateur qui reçoit un appel pendant le paiement, celui qui quitte l’application et revient, celui qui appuie deux fois. Dans chaque cas, une seule opération doit être enregistrée, et le reçu doit arriver une seule fois.

De votre côté, chaque paiement remonte dans votre espace avec son statut, son montant et la référence de la commande. Vous n’avez pas besoin d’ouvrir l’application pour savoir ce que vous avez encaissé aujourd’hui.

Publication sur l’App Store et Google Play

La publication fait partie du travail. Nous préparons la fiche, les visuels, la description, la politique de confidentialité, et nous accompagnons le passage en revue par les deux stores. Si un refus arrive, nous corrigeons et nous soumettons à nouveau : c’est une étape courante, pas un accident.

Une question revient toujours : les stores prennent-ils une commission sur les paiements ? Leurs règles visent surtout le contenu numérique consommé dans l’application. Un paiement par carte pour un bien ou un service livré en dehors de l’application est en général traité différemment. Comme ces règles évoluent et comportent des cas particuliers, nous vérifions celles en vigueur pour votre application précise avant sa publication, et nous vous exposons ce que nous trouvons plutôt que de vous donner une règle générale.

Après la mise en ligne, il reste du travail : les mises à jour imposées par les nouvelles versions d’Android et d’iOS, les changements de règles des stores, et les améliorations tirées de ce que font réellement vos utilisateurs. Nous pouvons en assurer le suivi ou transmettre le projet à votre équipe, proprement documenté.