Hey! These docs are for version 3.2, which is no longer officially supported. Click here for the latest version, 1.0!

OmniChannel API flow

Merchants can use the Omnichannel API to request and accept payments from customers through Google Pay by requesting a single identifier (like a phone number) in their purchase flow. This API provides a server-side interface for merchants to initiate a payment call to Google and complete the transaction.

Merchants can pre-populate the user's phone numbers (or ask for input) on their app or website.
Once the user confirms the populated information, the merchant makes a server call to request payment
The Google Pay app directs the user to complete the payment.
The merchant verifies the payment status with their PSP before proceeding to confirm the purchase.

The User Experience is handled by the merchant when using mobile number based push payments on GooglePay. Please refer to GooglePay brand guidelines before implementing it.

Step 1: User selects GooglePay as the preferred Payment Option

Step 2: User is asked to enter the Mobile Number linked to GooglePay in the payment page. Merchants can choose to autofill this field.

Step 3: User clicks on “PAY”. The /txns API is called on click. This triggers a request to the GooglePay account linked to the mobile Number passed.

Step 4a: The response contains the field “url”. The URL needs to be loaded on a browser. The URL checks Juspay order status. As soon as the user confirms the payment on GooglePay, the browser will redirect to the merchant redirection page.

Step 4b: Instead of loading the URL passed in the response, merchants can handle UI natively and check Juspay order status API for the order confirmation. Once the user pays on GooglePay, the status API will return “CHARGED”. Until then, the status will be “PENDING_VBV”.

The response for the OmniChannel API is a Payment Status Object with one extra parameter:  "txn_uuid":       (click to open table)
The Payment Status Object is the same as the object returned for Payments API (/txns) transaction requests.
order_idStringUnique Identifier for the order.
txn_idStringTransaction ID for the payment attempt.
txn_uuidStringTransaction UUID
statusStringStatus of the transaction. See Appendix below for status mapping. PENDING_VBV indicates that the transaction requires authentication to complete.
payment.authentication.methodStringHTTP Method for authentication. Can be one of GET or POST (See redirection instructions in the "Handling the Redirection Method" section above.)
payment.authentication.urlStringURL to which the user has to be taken to for completing the authentication
payment.authentication.paramsObjectPresent only when the method is POST. This a mapping via a list of key:value pairs that must be sent along with the URL for authentication. Do not hardcode the params in your client * Never assume that you will receive param “x” or param “y”. This is completely dynamic and will vary on a case by case basis.
  APPENDIX   - Payment status codes and meaning:
NEW10Newly created order
PENDING_VBV23Authentication is in progress
CHARGED21Successful transaction
AUTHENTICATION_FAILED26User did not complete authentication
AUTHORIZATION_FAILED27User completed authentication, but bank refused the transaction
JUSPAY_DECLINED22User input is not accepted by the underlying PG
AUTHORIZING28Transaction status is pending from bank
The request consists of Payment Method Details and two extra parameters: txn_type (must be set to 'PUSH_PAY'), and  mobile_number (identifier of customer in payment process).     Parameters are listed below:
The Payment Method Details parameters are the same as those returned for Payments API (/txns) transaction requests, except that the  redirect_after_payment (Boolean) parameter is not used (the user will be automatically redirected to the  return_url  configured for the order).
Click Try It! to start a request and see the response here!