Client
Un grand constructeur automobile européen a contacté Elinext pour développer un système de paiement en ligne B2B.
Défi
L'entreprise a travaillé avec un autre développeur pour créer une application de paiement de bout en bout personnalisée qui permettrait aux entreprises de vendre des produits aux clients en ligne. Pour les acheteurs — ce serait la même chose que de payer par carte via le terminal dans le magasin, mais aussi via Internet. L'application devait traiter les détails de paiement de manière sécurisée.
La première version de l'application était très en retard et difficile à utiliser. L'entreprise a décidé de remplacer l'équipe de développement. Ils avaient besoin d'un partenaire capable de clarifier l'architecture de l'application, de la rendre plus stable et d'ajouter de nouvelles fonctionnalités. Quelqu'un dans l'entreprise avait déjà travaillé avec Elinext et savait que nous avions de l'expérience dans la création de logiciels de paiement en ligne. Nous étions donc considérés comme un partenaire potentiel. Nous avons démontré notre expertise à travers plusieurs études de cas connexes, et l'entreprise était convaincue que nous savions quoi faire et que nous pouvions les aider.
Processus
Notre collaboration avec le client a été organisée selon le modèle de l'outstaffing. Cela signifie que nous avons fourni une équipe de développeurs et que notre équipe a travaillé à distance au sein de l'entreprise du client.
Nous avons aligné le processus sur la méthodologie Agile, en utilisant Jira pour configurer le flux de travail dans quatre environnements de développement avec des déploiements automatiques. Le travail a été décomposé en cinq sprints d'une semaine, chacun étant construit autour d'une phase particulière: investigation, implémentation, test, correction de bogues et livraison.
En grande partie, le client a planifié les sprints lui-même, en consultant notre développeur lead. Et le développeur lead a joué un rôle important dans le suivi des progrès grâce à des réunions quotidiennes, une avec son équipe et une avec le client.
En plus des sprints, l'ensemble du projet comprenait quatre étapes: refactorisation, ajout de nouvelles fonctionnalités, développement de la version 2.0 et amélioration de cette version. Et le plus crucial d'entre eux était la refactorisation.
Nettoyage
L'application originale avec laquelle nous avons dû travailler a nécessité beaucoup d'améliorations, notamment son architecture: nous avons dû la réécrire.
Nous avons résolu ce défi en utilisant domain-driven design (DDD). Cette approche nous a permis d'adapter la nouvelle architecture aux besoins et aux spécificités de l'entreprise. Et l'architecture que nous avons construite en conséquence s'est avérée beaucoup plus propre, plus stable et plus résistante à la charge que l'originale. Six mois après le lancement du projet, le client disposait d'une première version propre de l'application. Il comprenait des modules et des entités qu'eux et les entreprises potentielles utilisant l'application pouvaient enfin comprendre et utiliser. Et aucun risque de sécurité ou problème de base de code n'empêchait le développement ultérieur.
Passer au Niveau Supérieur
Une fois que l'application a obtenu une architecture propre et efficace, le client a donné son feu vert à d'autres améliorations. Au cours des six mois suivants, nous avons ajouté de nouvelles fonctionnalités et terminé la première version de l'application telle qu'elle avait été conçue. Et nous ne nous sommes pas arrêtés là.
Il nous a fallu un an pour créer la deuxième version et un an et demi pour étendre l'application, en l'enrichissant de fonctionnalités supplémentaires.
Testing
Tout au long du développement, nous avons vérifié le logiciel à l'aide de divers tests. Mais les tests de bout en bout (E2E) ont joué le rôle le plus important en nous permettant de surveiller les performances des nouvelles fonctionnalités. Au cours du travail, nous avons appliqué une variété d'outils pour analyser l'application et nous assurer que les fonctionnalités étaient livrées de manière continue et opportune.
Produit
Les entreprises peuvent utiliser l'application pour effectuer des paiements en ligne. Une fois qu'il a été intégré au site Web ou à l'application mobile d'une entreprise, notre client fournira à cette entreprise un compte marchand et une passerelle de paiement. Ils connecteront la banque du client ou le système de paiement à la banque de l'entreprise.
Nous avons activé le stockage des données associées dans DynamoDB, ce qui le rend conforme au RGPD.
Widget
L’entreprise peut intégrer l'application à son site Web ou à son application mobile en installant un widget.
Le widget prend en charge les paiements dans dix devises, transférés via des cartes largement utilisées (par exemple Mastercard, Visa, Paypal) et des solutions personnalisées (par exemple Klarna, SEPA). Nous avons également activé les paiements récurrents automatisés. Le système est conforme aux normes de l'Industrie des cartes de paiement (PCI) et n'est pas tenu se conformer au standard PCI DSS (PCI Data Security Standard).
L'apparence du widget dépendra de l'entreprise qui l'utilise — vous pouvez facilement personnaliser son apparence. Et c'est convivial pour les utilisateurs parlant différentes langues. Nous avons mis en place un mécanisme de localisation qui détecte automatiquement la langue de l'utilisateur et présente l'interface dans l'une des dix langues disponibles.
Nous avons utilisé Native.js avec son système d'événements à gérer par un gestionnaire d'état interne (par exemple Redux). Cela a permis d'éviter d'éventuels conflits d'intégration.
Back End
Nous avons utilisé Amazon Web Services (AWS) pour créer le back-end de l'application dans le cloud afin qu'elle puisse traiter plus de deux millions de demandes par jour.
Pour simplifier les transactions, nous avons utilisé un ensemble de technologies. Elastic Load Balancer équilibre automatiquement les charges élevées, tandis que l'Orchestration de Workflows Serverless est responsable du traitement des mécanismes transactionnels.
Maintenant, si une transaction échoue, la valeur du paiement renverra automatiquement les fonds sur la carte de paiement ou le portefeuille. Les causes de l'échec peuvent inclure une mauvaise gestion des demandes par des tiers, un manque de fonds dans le cas de paiements récurrents automatisés, etc. Nous avons également appliqué des lambdas pour gérer les tâches planifiées et tous les événements possibles.
Portail d'Administration
Pour construire le portail d'administration, nous avons utilisé React.js accompagné de Redux en tant que gestionnaire d'état et AWS Cognito en tant qu'outil d'authentification. Le portail génère les jetons d'accès nécessaires pour intégrer l'application au site Web ou l'application mobile de l'entreprise.
Les utilisateurs du portail peuvent être affectés à l'un des trois rôles suivants: Opérateur, Super Administrateur et Marchand.
Un Super Administrateur gère l'application à tous les niveaux, en attribuant des rôles d'utilisateur, en modifiant les informations de l'organisation, en configurant les localisations par défaut, etc.
Les Opérateurs peuvent créer des comptes professionnels, générer des jetons d'accès et gérer les localisations de l'entreprise.
Enfin, les comptes Marchands sont réservés aux entreprises. Ils peuvent gérer les détails de leur entreprise et utiliser des jetons d'accès pour intégrer le widget à leur site Web ou à leur application mobile.
Résultats
Nous avons terminé le projet à temps, nettoyé l'architecture de l'application, ajouté de nouvelles fonctionnalités et économisé de l'argent au client en supprimant des outils tiers. Et le projet dans son ensemble nous a été instructif, car nous avons amélioré notre compréhension de la gestion d'énormes systèmes de paiement très chargés.
Aujourd'hui, le produit se développe rapidement. Et nous nous préparons à l'étape suivante: refactoriser le widget en utilisant le framework React.
Découvrez d'autres projets réalisés par Elinext:
