Embedded Files
Product & scope: OnePay frontend web application and its unifying backend layer designed to consolidate disparate payment gateways across multiple GoTo product lines.
Core strategy: Implementation of a Centralized Billing Account system featuring payment encapsulation, allowing an account to distribute isolated identifiers across distinct commerce systems without storing actual credit card data on the backend.
Key design targets: Establishing clear system indicators for scheduled account renewals, linking specific payment methods to their active subscriptions, and distinct branding for primary corporate credit cards.
Compliance & adaptability: Introducing mandatory address validation parameters to automatically filter payment method eligibility based on local country infrastructure and regulations.
Responsive overhaul: Restructuring the interface architecture to provide complete cross-platform responsiveness, targeting a minimum form factor equivalent to an iPhone 13 mini in response to mobile access demands from more than ten percent of the core user base.
The friction of fragmented commerce
Enterprise software ecosystems frequently suffer from fractured internal architectures where separate product acquisitions retain their own isolated purchasing portals. At GoTo, this structural inefficiency meant that clients attempting to buy across different product lines faced a disjointed labyrinth of distinct payment platforms.Β
To collapse this wall of friction, the organization set out to develop a single, unified payment gateway capable of consolidating all product families into a frictionless commerce stream.
The architecture of anonymized transactions
The resulting frontend application, dubbed OnePay, originally operated under severe functional constraints by integrating exclusively with the GoTo Admin portal and processing only credit card payments. Beneath the surface, the engineering strategy relied on an advanced payment encapsulation framework within a Centralized Billing Account structure. Under this system, a single corporate credit card could distribute unique identifier keys across multiple legacy commerce systems, which effectively hid the unified card source from individual platform tenants while strictly ensuring that actual credit card data never remained stored on the backend.
We referred to each of the commerce systems as Tenants. Going forward, we would be using one tenant, with the back end being the single source of truth for all of these. This opened multiple possibilities for us, e.g., currently in Titan, a client could only save one credit card.
The back end could host more credit cards. Going with it would eliminate that limitation as the credit cards would be hosted in one unifying layer. The CSs would call the back end to get a response about how many credit cards a client has, and all the saved cards along with their payment keys would be shared across all tenants.
Breaking the single-card monolith
Transitioning to this unified backend layer eliminated a critical legacy limitation where clients were arbitrarily restricted to saving just a single credit card within specific tenants. By transforming the backend into a centralized single source of truth, the architecture allowed clients to host multiple payment methods simultaneously while distributing payment keys across all software branches. This structural shift forced the team to prioritize clear visibility, requiring the interface to display upcoming scheduled renewals, match specific cards to their corresponding subscriptions, and clearly identify primary corporate accounts.
OnePay flows.pdfScrollable PDF
Geolocation and mobile imperatives
Expanding this centralized gateway introduced strict compliance and accessibility challenges where financial regionality dictated payment options. Because local regulations govern payment processing, a verified physical address became a mandatory gateway requirement to dynamically filter eligible payment methods, restricting or expanding options like Direct Debit, PayPal, or specialized local processors based on strict geolocation data.
Furthermore, while corporate management lacked plans for a native mobile application, a strong push from 10-15 % of the active user base forced the team to re-engineer OnePay for the responsive web, an optimization that scaled down to the compact screen dimensions of an iPhone 13 mini to guarantee universal access.
Next up: invoices, or go to overview
Google Sites
Report abuse