On 14th Nov 2018, Google Pay launched in the UAE without much fanfare. It was a quiet launch — with only 4 banks participating, advertised only for the POS and not a lot of the standard Google promotion that we’ve come to expect. Nonetheless, for e-tailers, it opened up a large consumer base, who could be nudged to use the payment wallet for transacting faster online.
In this article, we’ll touch upon how the payment method works, how you as a product manager can leverage it and most importantly, things to keep in mind when it comes to the pays.
What is Google Pay?
Originally launched as Android Pay, the service was released at Google I/O 2015. Android Pay was a successor to and built on the base established by Google Wallet which was released in 2011. In Jan 2018, Google announced that Google Wallet would be merged into Android Pay, with the service as a whole rebranded as Google Pay.
What does it offer?
Standard wallet functionality — adding your credit cards, loyalty cards, payment cards etc along with Google powered recommendations. The entire eco-system completes the Google vision of data empowered individuals — connecting Maps, Search, Reviews and Pay to provide you a data driven accurate version of where you’ll want to spend next.
In the USA & UK, it also offers the ability to send and receive money between individuals — saturating an already saturated market. Here is a country wise distribution of the features.
One additional benefit, I personally feel, is that of the Web payments in Chrome. Google pay integrates (or is) the web payments part of the Chrome browser, so if you’ve already stored cards on your browser, you’re already using Google Pay!
How does Google Pay work?
Keeping the scope to only digital payments, here is a high-level flow:
Step 1: User opts to pay using Google Pay.
Step 1.1: On device script initiates an API call to the Google Pay service to identify the payment request (with your gateway provider). This also fetches the ondevice cards and their identifiers.
Step 1.2: The script requests for the address, payment amount, shipping details etc required to complete the transaction for the ecommerce… this is where you’ll specify what the input requirements are, the shipping options available etc.
Step 2: User confirms the payment using biometric/PIN. A request is made to the GPay service to retrieve card details against the card identifiers sent. At this point, it is advisable to run an inventory check or a reservation, since the payment is being made.
Step 3: Incase the card details are tokenized (which is the case for most providers), a request is made by GPay services to get the token against the identifier sent.
Step 4: The payment network returns the appropriate token and cryptogram to the GPay service.
Step 5: Google creates encrypted payment data using the gateway-specific key that is supplied in the Wallet request and includes it in the Google API response.
Step 6: On device script makes a call to your server with the encrypted payload from the Google API response and your order object containing product details.
Step 7: A server to server request is initiated with the payment payload:
Your server prepares the Google Pay response information for submission to the gateway service. The following are the steps that take place once the gateway gets the information (standard Card not present credit card processing):
- Gateway sends the authorization request to the acquirer. (the bank who handles all your incoming payments — with whom you’ve a banking relationship)
- The acquirer processes the request from the gateway and creates the payment network (VisaNet or MasterCard) authorization request.
- The payment network processes the request from the acquirer and creates the issuer authorization request (the issuer is the bank that issued the credit card to the customer).
- The issuer processes the request from the payment network. The issuer looks up the payment information and returns an approved or declined authorization message to the payment network.
- The payment network returns the authorization response to the acquirer.
- The acquirer returns the authorization response to the gateway.
Step 8: The entire response is sent back to your server. In case of success, you’ll want to create the order here.
Step 9: The response is sent back to the device. In case of success, the user is directed to the Order Confirmation page, while in case of failure, the failure message is shown with errors, if any.
Step 10: User takes the appropriate action in case of failure (re-attempt) or gets the order confirmation.
Note: 3D Secure in this case is mostly avoided, since the payment is coming from a recognized source — at the time of adding the card, you might have already gone through the process & customer biometrics already confirms ownership.
Why should you implement GPay in your ecommerce?
Here are the reasons:
- Leverage the large Chrome user base with their addresses and cards stored.
- Unlike Apple Pay & Samsung Pay, which require device ownership (Samsung Pay works with W3C payments API, but is a convoluted method of confirming payment), GPay works seamlessly across devices which have Chrome installed.
- User adoption is much higher, since for the web payments part, there is virtually no bank integration — adding cards is a breeze.
Where should you implement GPay?
I’ll take Namshi.com as an example:
This is the right place to the Buy button. A common UX concern could be that if the site offers click and collect, the customer will not be able to choose. The answer to that is simple — the pop up that is shown right after clicking the Buy with GPay button explicitly states that it is a home delivery.
The whole point of this button is to enable express payments, without the hassle of the fancy checkout your UX team designed.
Enables express checkout with the ability to have multi-items basket. This is a no-brainer.
Payment Step on the checkout
On the last step of the checkout, when the payment methods are being chosen, you’ve to expose the GPay button. However, there is some merit in providing the button one step before, though it can change depending upon the checkout logic you might have (e.g. processing inputs received from that step changes the payment options shown).
FAQs, T&Cs and other pages
This is usually missed out, but all your communication pages and FAQs, including your email communication should start to reflect GPay.
And that’s it! Hopefully, this should have given you some sort of direction to start thinking about wallet payments on your site. Note that the rest of the pays function almost similarly, so you can launch Apple Pay & Samsung Pay (if you haven’t already).
Thank you for reading! If you’d like to read about how the wallets run in a store scenario or more details on payments themselves, be sure to comment below. Do follow for more articles on product management, payments and other things :)