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.
APPENDIX - Payment status codes and meaning:
|order_id||String||Unique Identifier for the order.|
|txn_id||String||Transaction ID for the payment attempt.|
|status||String||Status of the transaction. See Appendix below for status mapping. PENDING_VBV indicates that the transaction requires authentication to complete.|
|payment.authentication.method||String||HTTP Method for authentication. Can be one of GET or POST (See redirection instructions in the "Handling the Redirection Method" section above.)|
|payment.authentication.url||String||URL to which the user has to be taken to for completing the authentication|
|payment.authentication.params||Object||Present 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.|
|NEW||10||Newly created order|
|PENDING_VBV||23||Authentication is in progress|
|AUTHENTICATION_FAILED||26||User did not complete authentication|
|AUTHORIZATION_FAILED||27||User completed authentication, but bank refused the transaction|
|JUSPAY_DECLINED||22||User input is not accepted by the underlying PG|
|AUTHORIZING||28||Transaction 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).