Kunde
Ein großer europäischer Automobilhersteller wünschte sich ein B2B-Online-Zahlungssystem entwickeln lassen.
Herausforderungen
Das Unternehmen stellte einen anderen Entwickler ein, um eine benutzerdefinierte End-to-End-Zahlungsanwendung zu erstellen, mit der Unternehmen online an Kunden verkaufen können. Für den Kunden wäre es das Gleiche wie das Bezahlen über ein Kartenterminal im Geschäft – nur eben im Internet. Die Anwendung musste Zahlungsdaten sicher verarbeiten.
Die erste Version der Anwendung war wirklich eine Katastrophe: Sie verzögerte stark und war schwierig zu bedienen. Und als das Unternehmen herausfand, dass es die Schuld des Entwicklers war, beschloss es, sie zu ersetzen. Sie wollten einen Partner, der die Architektur der Anwendung aufräumen, stabiler machen und neue Funktionen hinzufügen konnte.
Jemand im Unternehmen hatte bereits mit Elinext gearbeitet und wusste, dass wir Erfahrung mit der Entwicklung von Online-Zahlungssoftware hatten.
Wir haben unser Fachwissen durch mehrere Fallstudien unter Beweis gestellt, und das Unternehmen war überzeugt, dass wir wussten, was zu tun war, und wir konnten so viel umsetzen. “
Jemand im Unternehmen hatte bereits mit Elinext gearbeitet und wusste, dass wir Erfahrung mit der Entwicklung von Online-Zahlungssoftware hatten.”
Prozess
Unsere Zusammenarbeit mit dem Kunden wurde nach dem Outstaffing-Modell organisiert. Das bedeutet, dass wir ein Team bereitgestellt haben und unser Team als entfernter Teil der Organisation des Kunden gearbeitet hat.
Wir haben den Prozess an der Agile-Methodik ausgerichtet und mithilfe von Jira einen Workflow über vier Entwicklungsumgebungen mit automatischen Bereitstellungen eingerichtet. Die Arbeit wurde in fünf einwöchige Sprints unterteilt, von denen jeder um eine bestimmte Phase herum aufgebaut war: Analyse, Implementierung, Testen, Fehlerbehebung und Lieferung.
Der Kunde plante Sprints größtenteils selbst und konsultierte unseren leitenden Entwickler. Und der leitende Entwickler war maßgeblich daran beteiligt, den Fortschritt durch tägliche Meetings zu überwachen, eines mit seinem Team und eines mit dem Kunden.Zusätzlich zu den Sprints umfasste das gesamte Projekt vier Phasen: Refactoring, Hinzufügen neuer Funktionen, Entwicklung von Version 2.0 und Verbesserung dieser Version. Und der wichtigste von denen war das Refactoring.
Chaos aufräumen
Die ursprüngliche Anwendung, mit der wir arbeiten mussten, erforderte einige Verbesserungen, insbesondere ihre Architektur: Wir mussten sie neu schreiben.
Wir haben uns dieser Herausforderung gestellt, indem wir domänengetriebenes Design (DDD) verwendet haben. Dieser Ansatz ermöglichte es uns, die neue Architektur an den Bedürfnissen und Besonderheiten des Unternehmens auszurichten. Und die von uns gebaute Architektur erwies sich als viel sauberer, stabiler und belastbarer als das Original. Sechs Monate nachdem wir mit dem Projekt begonnen hatten, hatte der Kunde eine saubere, frühe Version der Anwendung. Es umfasste Module und Entitäten, die sie und potenzielle Unternehmen, die die Anwendung verwenden, endlich verstehen und mit denen sie arbeiten konnten. Und keine Sicherheitsrisiken oder Probleme mit der Codebasis verhinderten die weitere Entwicklung.
Weitere Verbesserungen
Nachdem die Anwendung eine saubere und effiziente Architektur hatte, gab der Kunde grünes Licht für weitere Verbesserungen. In den folgenden sechs Monaten fügten wir neue Funktionen hinzu und stellten die erste Version der Anwendung so fertig, wie sie konzipiert war. Und da haben wir nicht aufgehört.
Wir haben ein Jahr gebraucht, um die zweite Version zu erstellen, und anderthalb Jahre, um die Anwendung zu erweitern und mit weiteren Funktionen anzureichern.
Testen
Während der Entwicklungsphase haben wir die Software mit verschiedenen Tests überprüft. End-to-End (E2E)- Tests spielten jedoch die wichtigste Rolle, da sie es uns ermöglichten, die Leistung neuer Funktionen zu überwachen.
Dabei haben wir eine Vielzahl von Tools eingesetzt, um die Anwendung zu analysieren und sicherzustellen, dass die Funktionen kontinuierlich und zeitnah bereitgestellt werden.
Produkt
Unternehmen können die Anwendung nutzen, um Zahlungen online entgegenzunehmen. Sobald es in die Website oder mobile App eines Unternehmens integriert wurde, stellt unser Kunde diesem Unternehmen ein Händlerkonto und ein Zahlungsgateway zur Verfügung.
Wir haben die zugehörige Datenspeicherung in DynamoDB aktiviert und damit DSGVO-konform gemacht. Das Widget
Ein Unternehmen kann die Anwendung durch die Installation eines Widgets in seine Website oder mobile App integrieren.
Das Widget unterstützt Zahlungen in zehn Währungen, die über gängige Karten (z. B. Mastercard, Visa, Paypal) und benutzerdefinierte Lösungen (z. B. Klarna, SEPA) übertragen werden. Wir haben auch automatisierte wiederkehrende Zahlungen aktiviert. Das System erfüllt die Standards der Payment Card Industry (PCI), muss aber nicht den PCI Data Security Standard (DSS) einhalten.
Wie das Widget aussieht, hängt von dem Unternehmen ab, das es verwendet – Sie können sein Erscheinungsbild einfach anpassen. Und es ist benutzerfreundlich für Benutzer, die verschiedene Sprachen sprechen. Wir haben einen Lokalisierungsmechanismus eingerichtet, der die Sprache des Benutzers automatisch erkennt und die Benutzeroberfläche in einer von zehn verfügbaren Sprachen darstellt. Wir haben Native.js mit seinem Ereignissystem verwendet, das von einem internen Statusmanager (z. B. Redux) verwaltet wird. Dies trug dazu bei, mögliche Integrationskonflikte zu vermeiden.
Backend
Wir haben Amazon Web Services (AWS) verwendet, um die Back-End-Anwendung in der Cloud zu erstellen, damit sie täglich mehr als zwei Millionen Anfragen verarbeiten kann. Um Transaktionen zu rationalisieren, haben wir eine Reihe von Technologien verwendet. Elastic Load Balancer gleicht hohe Lasten automatisch aus, während Serverless Workflow Orchestrations für die Verarbeitung von Transaktionsmechanismen verantwortlich ist.
Wenn eine Transaktion fehlschlägt, sendet der Zahlungswert jetzt automatisch Geld zurück an die Zahlungskarte oder das Wallet. Gründe für das Scheitern können eine falsche Bearbeitung von Anfragen durch Dritte, fehlende Mittel bei automatisierten wiederkehrenden Zahlungen und andere sein. Wir haben auch Lambdas für die Abwicklung geplanter Jobs und aller möglichen Ereignisse angewendet.
Admin-Portal
Um das Admin-Portal zu erstellen, haben wir React.js zusammen mit Redux als Statusmanager und AWS Cognito als Authentifizierungstool verwendet. Das Portal generiert Zugriffstoken, die für die Integration der Anwendung in die Website oder mobile App eines Unternehmens erforderlich sind.
Die Portalbenutzern kann eine der drei Rollen zugewiesen werden: Operator, Super Admin und Merchant. Ein Super-Admin verwaltet die Anwendung auf allen Ebenen, weist Benutzerrollen zu, bearbeitet Organisationsdetails, richtet Standardlokalisierungen ein und vieles mehr.
Betreiber können Geschäftskonten erstellen, Zugriffstoken generieren und die Lokalisierung eines Unternehmens verwalten. Schließlich sind Händlerkonten für Unternehmen reserviert. Sie können ihre Geschäftsdetails verwalten und Zugriffstoken verwenden, um das Widget in ihre Website oder mobile App zu integrieren.
Ergebnisse
Wir haben das Projekt pünktlich abgeschlossen, die Architektur der Anwendung bereinigt, neue Funktionen hinzugefügt und dem Kunden Geld gespart, indem wir Tools von Drittanbietern entfernt haben. Und das Projekt insgesamt war für uns lehrreich, da wir unser Verständnis für den Umgang mit riesigen, hochbelasteten Zahlungssystemen verbesserten.
Heute entwickelt sich das Produkt rasant. Und wir bereiten uns auf die nächste Phase vor: das Refactoring des Widgets mit React Framework.
Möchten Sie die Benutzerinteraktionen verbessern? Gehen Sie zu Elinexts UI/UX Dribbble Showcase.
