OnePay

OnePay and UCS

To explain the purpose of OnePay, we have to dive into another topic first, and that's the Unified Commerce System (UCS).

We were in a situation where, as a company, we were offering different products through different purchase portals. Some enabled the purchase of individual products only, and some allowed for product families to be purchased.

Going forward, we wanted to provide a single, unified platform that could handle all of this, and that would be GoTo Admin (GTA, codenamed BOSS) with OnePay as the payment gateway. For the other commerce systems we had in place we'll use the codenames Sterling, Titan and Jive.

There were two main reasons for doing this:

Technicalities;
Smoother user experience, where customers could purchase everything in one place, going forward.

OnePay

OnePay is the name of a front end application, which, at the time, could only integrate with GTA, but could be extended to work with any other application that we wanted it to. At the time of my presence at GoTo, it only supported credit cards.

We had a back end service where all the payment-related transactions were sent across and that interacted with all the payment gateways and made a payment possible. Every transaction would have a transaction key and every account would have a payment account key.

Payment encapsulation

As part of a centralized billing account (CBA), what we were doing was payment encapsulation. How that worked was that one card assigned to an account shared multiple identifiers (payment method keys) with different commerce systems (CS), thus these CSs couldn't tell that that key was assigned to a payment method that actually belongs to one card. The back end was not allowed to save a credit card's number.

We referred to each of the CSs 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.

Targets

The front end should indicate how many renewals a client has scheduled;
Each credit card should indicate what it's used for/by (which subscription it is used for as a payment method);
Indicate which card is primary;
OnePay should be extended to all credit cards and payment methods (like Direct Debit).

OnePay flows.pdf

Mapping OnePay. PDF is scrollable.

Addressing the challenges of an interconnected gateway

The prerequisite to adding a payment method is a valid address. This will help determine, based on geolocation, which payment methods an account is eligible for. Say the account holder has a valid address in India. That means they'll only be able to add a bank account, a credit card, and payment methods like PayPal or RazorPay, which are supported in India.

Adding payment methods could be done from both GTA and OnePay (below is OnePay):

The call for responsiveness

One would think that in 202x the majority of services would operate responsively, but alas, like with many it wasn't the case with OnePay either, until prompted by an over 10% user base call to structure the service for the responsive web, since there were no plans at the time to craft a native GTA mobile application:

Optimized for an iPhone 13 mini

Google Sites

Report abuse