1.18. Google Pay™ Web

Introduction

Google Pay™ is an electronic wallet system that allows you to make one-click payment using a card stored securely on Google side. There is no need to enter card details during Google Pay™ transaction.
Access to the payment mechanism is possible from any device, which supports Google Pay™.
After choosing Google Pay™ payment method, the payer will see the form on which he confirms his Google account and card he is going to use to pay for order. If payer doesn’t have a previously registered card, he may do it while making payment.

See terms definitions in Glossary.

Integrate Google Pay™ in App with the following steps:

1. Read and accept Terms of Service.
5. Follow the transaction flow instructions: Google Pay™ Web Flow.

How to integrate Google Pay through Payneteasy

Already our client   Not our client yet
If you are Payneteasy client, you can get in touch with your manager or contact us here.   Contact our sales team and we’ll create a test account for you and help to integrate Google Pay in a week.

Terms of Service

The following rules must be complied to use Google Pay™:
The following rules must be complied to use Google Pay™ on websites:

Google Pay™ Account Setup

  1. Connecting Party must register in Google Console. Instead of gmail, you can use a corporate email address.

../_images/gpay-1.png ../_images/gpay-2.png
  1. Then, from the account screen in the console, save the Merchant ID and proceed to the registration of the website in the Google Pay API section.

../_images/gpay-3.png
  1. Add a website using the “Add website” button.

../_images/gpay-4.png
  1. Specify screenshots of the checkout and payment form in the website settings, as well as integration type = Gateway and the address of the Connecting Party’s website from where the purchase starts.

../_images/gpay-5.png
  1. Send the website address and Merchant ID to Payneteasy support managers.

Google Pay™ Integration in a Connecting Party Website

Google Pay™ Authentication Types

Connecting Party can independently choose the card types in Google Pay™ that will be available for payment. The card type is specified in the allowedAuthMethods Google request parameter.
There are two card types (authentication methods):
  1. PAN_ONLY (non-tokenized) - cards stored in payer`s Google account. These cards available on any device of the payer.
    The token contains the number and expiration date of the physical card. That is why 3-D Secure authentication is required for these cards. 3DS is required for PAN_ONLY cards. It can be indicated by the Success==3DS in Google payment response. 3-D Secure authentication does not differ from the standard 3-D Secure.
  2. CRYPTOGRAM_3DS (tokenized) - cards that are stored tokenized on the payer’s device. Tokenized cards are only available on the device where the card was added to the Google Pay™ app.
    The token contains the number and expiration date of the virtual card as well as the 3-D Secure cryptogram. Customer 3-D Secure verification for tokenized cards is not required.

Google Pay™ Allowed Networks

Payment Gateway supports all networks specified in the allowedCardNetworks Google request parameter, such as: VISA, MASTERCARD, etc. For the complete list of allowed networks refer to Payneteasy support.

Required Parameters for Google Pay™ Integration

  1. Register with Google, accept Google Terms of Service, and receive a Google merchant ID after website passes a Google review.

  2. ENDPOINT or ENDPOINGROUPID received from Payneteasy support.

  3. Control-key and Connecting Party login received from Payneteasy support.

Google Pay™ Web Flow

autonumber
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
actor Плательщик as Customer
participant "Веб-сайт \nПрисоединяющейся Стороны" as Merchant
participant Payneteasy as g
participant "Сервис Google Pay™" as gps
Customer -> Merchant: Инициализация
activate Merchant
== Запрос на проведение оплаты ==
Merchant -> g: sale-form/ENDPOINTID
activate g
Merchant -> g: **ИЛИ** preauth-form/ENDPOINTID
g --> Merchant: status=processing,\nredirect-url
deactivate g
Merchant -> Customer: Перенаправление на \nплатёжную форму redirect-url
deactivate Merchant
activate Customer
Customer -> g: GET redirect-url
deactivate Customer
activate g
g --> Customer: payment-form
deactivate g
activate Customer
Customer -> Customer: Нажатие кнопки Google Pay™
Customer -> Customer: Выбор карты
Customer -> gps: Подтверждение формы Google Pay™
deactivate Customer
activate gps
gps -> Customer: Криптограмма
deactivate gps
activate Customer
Customer -> g: Подтверждение криптограммы \nданных платежа
deactivate Customer
activate g
g -> g: Расшифровка \nкриптограммы CHD
alt CRYPTOGRAM_3DS
g -> g: Авторизация платежа \nтокен, дата окончания срока, \nполя 3DS
else PAN_ONLY
g->g: извлечение URL-адреса \nACS Банка-эмитента
g->Customer: перенаправление на URL-адрес \nACS Банка-эмитента
activate Customer
Customer->Customer:прохождение 3DS аутентификации
Customer->g: перенаправление назад к \nполям 3DS
deactivate Customer
g->g:авторизация платежа \nPAN, дата окончания срока, \nполя 3DS
end
== Финальное перенаправление клиента ==
g -> Customer: redirect-url веб-сайта Присоединяющейся Стороны
deactivate g
activate Customer
Customer -> Merchant: POST redirect-url\nstatus, orderid
deactivate Customer
activate Merchant
group Получение финального статуса
== Получение обратного вызова \nПрисоединяющейся Стороны ==
g -> Merchant: Обратный вызов с финальным статусом
activate g
Merchant --> g: HTTP 200
deactivate g
== Запрос статуса ==
Merchant -> g: status/ENDPOINTID
activate g
g --> Merchant: Ответ\nstatus, order-stage
deactivate g
end
Merchant --> Customer: Показ результата
deactivate Customer
deactivate Merchant

Below we can see Google Pay™ Purchase Flow and Integration steps:

(2) To implement sale-form payment request see /api/v2/sale.
(3) Instead of sale-form it is possible to implement preauth-form payment request see /api/v2/preauth-form. Preauth allows to hold the specified amount in the Payer’s card account for a limited time. Preauth can be followed by Capture or Cancel.
(20) To implement Final Redirect see Финальное Перенаправление.
(22) To implement callback with final status handling see Connecting Party Callbacks.
(24) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

Capture Flow

Capture is a transaction followed after preauth which deducts the locked amount from Payer’s card. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).

  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Плательщик
  participant "Присоединяющаяся Сторона" as A
  participant "Payneteasy" as B
  hnote over A,B : Успешная транзакция преавторизации
  autonumber
  group Опцонально
  Payer -> A: Инициация списания
  activate A
  end
  == Списание ==
  A -> B: api/v2/capture
  activate B
  B --> A: ИД транзакции
  B -> B: Обработка списания
  group Получение финального статуса
  == Получение обратного вызова ==
  A <- B: Обратный вызов с финальным статусом
  A --> B: HTTP 200
  deactivate B
  == Запрос статуса ==
  A -> B: Получение статуса по ИД транзакции api/v2/status
  activate B
  B --> A: Ответ со статусом, Order-stage
  deactivate B
  end
  group Опционально
  A --> Payer: Конечный статус
  deactivate A
  end

(1) Capture can be initiated by Connecting Party based on internal business model or Payer’s request.
(2) To implement capture request see /api/v2/capture/.
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see Connecting Party Callbacks.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.

Cancel Flow

Cancel is opposite of Capture which cancels the deduction and returns locked amount back to Payer’s card. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).

  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Плательщик
  participant "Присоединяющаяся Сторона" as A
  participant "Payneteasy" as B
  hnote over A,B : Успешная транзакция преавторизации
  autonumber
  group Опционально
  Payer -> A: Инициация отмены
  activate A
  end
  == Отмена ==
  A -> B: api/v2/cancel
  activate B
  B --> A: ИД транзакции
  B -> B: Обработка отмены
  group Получение финального статуса
  == Получение обратного вызова ==
  A <- B: Обраный вызов с финальным статусом
  A --> B: HTTP 200
  deactivate B
  == Запро статуса ==
  A -> B: Получение статуса по ИД транзакции api/v2/status
  activate B
  B --> A: Ответ со статусом, Order-stage
  deactivate B
  end
  group Опционально
  A --> Payer: Конечный Статус
  deactivate A
  end

(1) Cancel can be initiated by Connecting Party based on internal business model or Payer’s request.
(2) To implement cancel request see /api/v2/return/.
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see Connecting Party Callbacks.
(7) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.