Google Pay™

Google Pay™ is a digital wallet that allows customers to pay using credit or debit cards saved in their Google account or on their Android device. Instead of sharing card details directly with the merchant, Google Pay generates a secure payment token representing the customer’s payment information. This tokenization process helps protect sensitive card data during the transaction.
Google Pay enables customers to perform fast and secure payments with a single interaction on websites or Android applications using any card linked to their Google account.
How Google Pay Works with Getnet
When a customer chooses Google Pay during checkout, the following flow occurs:
- The customer selects Google Pay as the payment method.
- Google Pay returns payment data containing the customer’s payment credentials or tokenized card credentials.
- The merchant sends the required Google Pay payment data to Getnet as part of the payment request.
- Getnet processes the transaction through the configured payment processor or card network.
- The authorization result is returned to the merchant.
Integration Overview
To process Google Pay payments with Getnet, the integration involves two main components:
- Integrating the Google Pay API in your application or website.
- Sending the required Google Pay payment data to Getnet for payment processing.
After integrating with Google Pay, you can display the Google Pay button in your checkout and request payment information from your customers.
If you offer Google Pay as a payment method to your customers, use only official Google Pay brand assets according to Google’s brand guidelines. Do not modify the colors, proportions, layout, or appearance of Google Pay assets.
- Include the Google Pay brand within your websites
- Include the Google Pay brand within your Android applications
Requirements
Before integrating Google Pay, ensure the following:
- Google Pay payment with Getnet is available only in Brazil and Spain.
- Your integration complies with the Google Pay API Acceptable Use Policy and Terms of Service.
- Your frontend environment must be served over HTTPS to initialize the Google Pay SDK.
- Your Google Pay configuration must use the gateway information provided during technical onboarding.
- Your backend must be able to send the required payment data to Getnet according to the selected processing scenario.
Integration Steps
Step 1: Integrate with Google Pay
Follow Google’s official documentation to implement the Google Pay API:
-
Web integration: https://developers.google.com/pay/api/web/overview
-
Android integration: https://developers.google.com/pay/api/android/overview
This integration allows your checkout to display the Google Pay button and request payment data from the user’s device or Google account.
Step 2: Configure your Google Pay account
Before moving to production, you must:
- Register your business in the Google Pay & Wallet Console: https://pay.google.com/business/console/
- Configure your domain in the Google Pay allowlist through the Google Developer Console.
These steps ensure your website or application is authorized to request Google Pay payments.
Step 3: Tokenize and process the payment
Once the customer authorizes the payment:
- Google Pay returns payment data to the merchant.
- Your system sends the required Google Pay payment data to Getnet.
- Getnet processes the transaction through the configured payment processor or card network.
- Getnet returns the authorization result to the merchant.
Google Pay authorization methods and Getnet processing models
Google Pay supports card payments through authorization methods configured in the frontend using allowedAuthMethods.
Use the sections below to understand which Google Pay authorization methods are supported and when to use Getnet’s Authorization Token flow.
PAN_ONLY
PAN_ONLY uses card credentials associated with the customer’s Google account. The transaction is processed similarly to a card-not-present payment.
If 3D Secure authentication is required by local regulation, issuer rules, merchant configuration, or transaction risk, an additional 3DS flow may be triggered.
3DS for PAN_ONLY transactions
For PAN_ONLY transactions, 3D Secure may be required depending on the country, merchant configuration, issuer rules, or transaction risk.
For Spain, 3DS/SCA is required. For Brazil, 3DS may be optional depending on merchant configuration and risk rules.
To process a PAN_ONLY transaction with 3DS, merchants must follow the standard Getnet 3DS authentication flow before creating or confirming the payment. After authentication is completed, send the 3DS authentication fields in the payment request, such as eci, xid, ucaf, tdsver, and tdsdsxid, according to the Create a 3DS Authenticated Payment documentation.
If 3DS is required and the authentication data is not provided, the transaction may be declined or returned as pending for additional authentication.
CRYPTOGRAM_3DS
CRYPTOGRAM_3DS uses tokenized device card credentials and includes a transaction cryptogram generated during the payment process.
This method provides stronger authentication evidence through the device-generated cryptogram. Because of this, additional 3D Secure authentication is generally not required, unless required by local regulation, issuer rules, merchant configuration, or transaction risk.
Authorization Token flow
Authorization Token is not a Google Pay allowedAuthMethods value. It is a Getnet processing model.
Use this flow when your backend sends the Google Pay payment token to Getnet instead of sending card data fields.
In this flow, extract the value from paymentMethodData.tokenizationData.token, serialize the Google Pay payment token exactly as returned by Google Pay, encode it in Base64, and send the encoded value in data.payment.wallet.authorization_token. Getnet uses this token to extract and process the payment data required for authorization.
Do not decrypt, change, trim, or remove any field from the token content before encoding it.
Merchant gateway
When integrating with the Google Pay API as a merchant, ensure that both gateway and gatewayMerchantId are defined in the tokenizationSpecification object.
In this example, the gateway value is set to getnetpayments, and the gatewayMerchantId corresponds to the merchant identifier configured during technical onboarding.
| Attribute | Type | Description | Example |
|---|---|---|---|
tokenizationSpecification.type | String | Payment method tokenization type. | "PAYMENT_GATEWAY" |
tokenizationSpecification.parameters | Object | Parameters specific to the selected payment method tokenization type. | — |
tokenizationSpecification.parameters.gateway | String | Gateway ID configured during technical onboarding with Google. | "getnetpayments" |
tokenizationSpecification.parameters.gatewayMerchantId | String | Unique identifier used to represent the merchant in the gateway configuration. | "<Merchant ID assigned during onboarding>" |
{
"tokenizationSpecification": {
"type": "PAYMENT_GATEWAY",
"parameters": {
"gateway": "getnetpayments",
"gatewayMerchantId": "<Merchant ID assigned during onboarding>"
}
}
}Payment acceptance
For the best payment acceptance rates, Google recommends including both authorization methods in your configuration. Supporting both methods allows Google Pay to automatically choose the most secure and compatible option based on the customer’s device and card configuration.
Through the Getnet Global API, merchants can process Google Pay payments using multiple backend scenarios, including PAN_ONLY, CRYPTOGRAM_3DS, Authorization Token, and SDWO-specific transactions.
You must define the payment methods you accept in allowedAuthMethods, based on the methods implemented during your technical onboarding with Google.
| Authorization method | Credential type | 3DS requirement | Supported countries |
|---|---|---|---|
PAN_ONLY | Card credentials associated with the customer’s Google account | Required in Spain. Optional in Brazil depending on merchant configuration and transaction risk. | Brazil and Spain |
CRYPTOGRAM_3DS | Tokenized device card credentials with cryptogram | Generally not required, unless required by regulation, issuer rules, merchant configuration, or transaction risk. | Brazil and Spain |
Cards
Cards available for the transaction.
| Type | Spain | Brazil |
|---|---|---|
| Mastercard | ✅ | ✅ |
| Visa | ✅ | ✅ |
You must define the card networks you accept in allowedCardNetworks, based on the networks implemented during your technical onboarding with Google.
| Attribute | Type | Description | Example |
|---|---|---|---|
allowedPaymentMethods | Array | Set of payment method and card configurations. | — |
allowedPaymentMethods.type | String | Payment method type. | "CARD" |
allowedPaymentMethods.parameters.allowedAuthMethods | Array of strings | Supported Google Pay authorization methods. | ["PAN_ONLY", "CRYPTOGRAM_3DS"] |
allowedPaymentMethods.parameters.allowedCardNetworks | Array of strings | Card networks supported by Google Pay and Getnet. | ["MASTERCARD", "VISA"] |
The following is an example of how to support all available payment methods, card networks, and card authentication methods:
{
"allowedPaymentMethods": [
{
"type": "CARD",
"parameters": {
"allowedAuthMethods": ["PAN_ONLY", "CRYPTOGRAM_3DS"],
"allowedCardNetworks": ["MASTERCARD", "VISA"]
},
"tokenizationSpecification": {
"type": "PAYMENT_GATEWAY",
"parameters": {
"gateway": "getnetpayments",
"gatewayMerchantId": "<Merchant ID assigned during onboarding>"
}
}
}
]
}Billing address
Request billing address only when required for authorization, fraud prevention, AVS, or local compliance. Asking for additional information may increase checkout friction.
Use billingAddressParameters to request billing address fields from Google Pay when required for authorization, fraud prevention, AVS, or local compliance.
This object lets you define additional billing address fields to be returned by Google Pay.
| Attribute | Type | Description | Example |
|---|---|---|---|
allowedPaymentMethods.type | String | Payment method type. | "CARD" |
parameters.billingAddressRequired | Boolean | Set to true only if a billing address is required. | true |
parameters.billingAddressParameters.phoneNumberRequired | Boolean | Set to true if a phone number is required. | true |
parameters.billingAddressParameters.format | String | Billing address format required. | "MIN", "FULL" or "FULL-ISO3166" |
{
"allowedPaymentMethods": [
{
"type": "CARD",
"parameters": {
"billingAddressRequired": true,
"billingAddressParameters": {
"phoneNumberRequired": true,
"format": "MIN"
},
"allowedCardNetworks": ["MASTERCARD", "VISA"],
"allowedAuthMethods": ["PAN_ONLY", "CRYPTOGRAM_3DS"]
},
"tokenizationSpecification": {
"type": "PAYMENT_GATEWAY",
"parameters": {
"gateway": "getnetpayments",
"gatewayMerchantId": "<Merchant ID assigned during onboarding>"
}
}
}
]
}Handling the Google Pay payload
When a customer pays with Google Pay, Google returns payment data in the PaymentData response object.
For the Authorization Token flow, the encrypted Google Pay payment token must be extracted from:
paymentMethodData.tokenizationData.tokenThe merchant must then:
- Extract the value from
paymentMethodData.tokenizationData.token. - Serialize the token exactly as returned by Google Pay.
- Encode the serialized token in Base64.
- Send the encoded value in
data.payment.wallet.authorization_tokenin the Getnet payment request.
Do not decrypt, change, trim, or remove any field from the token content before encoding it.
Example of the Getnet payment request using the Authorization Token flow:
{
"data": {
"amount": 500,
"currency": "EUR",
"payment": {
"payment_method": "CREDIT",
"transaction_type": "FULL",
"number_installments": 1,
"wallet": {
"id": "216",
"type": "10",
"authorization_token": "<BASE64_ENCODED_GOOGLE_PAY_PAYMENT_TOKEN>"
}
}
}
}Integrate via Global API
To integrate Google Pay via the Global API, ensure the following prerequisites are met:
- Generate an access token through the Authentication endpoint.
- Wallet configuration: Use the correct
wallet.id,wallet.type, andwallet.tagaccording to the selected Google Pay processing scenario. - PCI Compliance: Scenarios involving
cardobjects, such as PAN_ONLY and CRYPTOGRAM_3DS, require the merchant to operate within the appropriate PCI-DSS scope for handling sensitive card data. - HTTPS: Your frontend environment must be served over a secure connection to initialize the Google Pay SDK.
Wallet field configuration
Use the table below to identify the correct wallet configuration for each scenario.
| Scenario | data.payment.wallet.id | data.payment.wallet.type | data.payment.wallet.tag |
|---|---|---|---|
| Standard Google Pay — PAN_ONLY | 216 | 10 | Not required |
| Standard Google Pay — CRYPTOGRAM_3DS | 216 | 10 | Not required |
| Authorization Token | 216 | 10 | Not required |
| SDWO card data | BRL | 55 | Not required |
| SDWO Authorization Token | BRL | 55 | GP |
For standard Google Pay transactions, use wallet.id = 216.
For SDWO transactions in Brazil, use wallet.id = BRL and wallet.type = 55.
Characteristics
| Capability | Details |
|---|---|
| Customer Experience | One-Tap — Fast checkout via biometric or device authentication. |
| Settlement | Real-time — Transactions are authorized and settled according to card network rules. |
| Confirmation | Synchronous — The API provides an immediate APPROVED, DECLINED, or intermediate status such as PENDING when additional authentication is required. |
Available Features
Use the matrix below to confirm the supported operations for Google Pay in the Global API.
| Features | Supported Countries | Purchases | Refunds | Partial Refunds | Pre-authorizations | 3DS | SDWO |
|---|---|---|---|---|---|---|---|
| Direct / API | Brazil and Spain | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Integration Flow
The lifecycle of a Google Pay transaction begins with the frontend SDK obtaining a secure payload and ends with the server-side authorization call.
Transaction Flow Diagram
The following diagram illustrates the end-to-end payment flow when a customer completes a purchase using Google Pay and the payment is processed through Getnet.

Flow Description
- The customer selects Google Pay as the payment method at checkout.
- The merchant application requests payment data from Google Pay.
- Google Pay displays the customer’s saved payment methods.
- The customer selects a card and confirms the payment.
- Google Pay generates and returns payment data to the merchant.
- The merchant sends the required Google Pay payment data to Getnet.
- Getnet prepares the transaction according to the selected processing scenario.
- Getnet sends the authorization request to the card network or configured payment processor.
- The processor returns the authorization result.
- Getnet forwards the response to the merchant, which then displays the final payment result to the customer.
Server-Side Implementation Scenarios
The following scenarios detail the JSON structures required based on the data provided by the Google Pay frontend and the selected Getnet processing scenario.
PAN_ONLY
PAN_ONLY is a card payment method within Google Pay in which the transaction uses the PAN — Primary Account Number associated with the customer’s Google account.
In this model, the payment behaves similarly to a traditional card-not-present transaction. The merchant sends standard card information alongside the Google Pay wallet identifier.
| Attribute | Type | Description | Example |
|---|---|---|---|
data.payment.card | Object | Card data set. | — |
data.payment.card.number | String | Card number. | 4012001037141112 |
data.payment.card.expiration_month | String | Two-digit card expiry month. | 12 |
data.payment.card.expiration_year | String | Two-digit card expiry year. | 25 |
data.payment.wallet | Object | Wallet data set. | — |
data.payment.wallet.id | String | Wallet identifier. For standard Google Pay transactions, always use 216. | 216 |
data.payment.wallet.type | String | Wallet type. For standard Google Pay transactions, always use 10. | 10 |
data.payment.eci | String | Electronic Commerce Indicator used for 3DS authentication. Optional for transactions without 3DS. | 02 |
For Spain, 3DS authentication is required. In Brazil, 3DS is optional depending on merchant configuration, issuer rules, and transaction risk.
Example of request
{
"idempotency_key": "{{$guid}}",
"request_id": "{{$guid}}",
"order_id": "{{$guid}}",
"data": {
"amount": 500,
"currency": "BRL",
"customer_id": "02587894152",
"payment": {
"payment_id": "{{$guid}}",
"payment_method": "DEBIT",
"transaction_type": "FULL",
"number_installments": 1,
"card": {
"number": "4012001037141112",
"expiration_month": "12",
"expiration_year": "26"
},
"wallet": {
"id": "216",
"type": "10"
}
},
"additional_data": {
"customer": {
"phone_number": "919999999",
"email": "[email protected]",
"document_number": "50506468",
"document_type": "uyci",
"name": "Jose da Silva",
"billing_address": {
"street": "R a",
"number": "1",
"district": "B",
"city": "City Z",
"state": "SP",
"country": "PT",
"postal_code": "05781000",
"complement": "N/A"
}
}
}
}
}Example of response
{
"idempotency_key": "563853a7-0c9b-43d6-9b0b-08a9483dcddb",
"seller_id": "a9c99f03-025c-4251-a9f5-de73ef593523",
"payment_id": "7af9d6ad-aba7-4395-ac35-86eecb11fe5c",
"order_id": "82daa233-5f23-4379-8b24-6cbb7e55fc77",
"amount": "500",
"currency": "BRL",
"status": "APPROVED",
"payment_method": "DEBIT",
"received_at": "2026-05-12T17:49:53.000Z",
"transaction_id": "306132749937879",
"original_transaction_id": "306132749937879",
"authorized_at": "2026-05-12T17:49:53.885Z",
"reason_code": "00",
"reason_message": "captured",
"acquirer": "GETNET",
"soft_descriptor": "EC TESTES PAGONXT - NA",
"brand": "VISA",
"authorization_code": "092608",
"acquirer_transaction_id": "000953185070"
}SDWO — Staged Digital Wallet Operator
SDWO is a payment framework typically used by digital wallet providers where the wallet acts as an intermediary between the cardholder and the final recipient.
It facilitates two stages: funding the account and transferring funds to a sub-merchant. This ensures transparency of the end receiver for payment networks.
For SDWO transactions in Brazil, the fields inside the wallet object must be filled as follows:
data.payment.wallet.idmust be set toBRLdata.payment.wallet.typemust be set to55
| Attribute | Type | Description | Example |
|---|---|---|---|
data.payment.card | Object | Card data set. | — |
data.payment.card.number | String | Card number. | 4012001037141112 |
data.payment.card.expiration_month | String | Two-digit card expiry month. | 12 |
data.payment.card.expiration_year | String | Two-digit card expiry year. | 25 |
data.payment.wallet | Object | Wallet data set. | — |
data.payment.wallet.id | String | Wallet identifier for SDWO transactions in Brazil. Always use BRL. | BRL |
data.payment.wallet.type | String | Wallet type for SDWO transactions. Always use 55. | 55 |
data.payment.wallet.fund_transfer | Object | Fund transfer data required for SDWO transactions. | — |
Example of SDWO request
{
"idempotency_key": "{{$guid}}",
"request_id": "{{$guid}}",
"order_id": "{{$guid}}",
"link_id": "{{$guid}}",
"data": {
"amount": 1200,
"currency": "BRL",
"payment": {
"payment_id": "{{$guid}}",
"payment_method": "CREDIT",
"save_card_data": false,
"transaction_type": "FULL",
"number_installments": 1,
"dynamic_mcc": 6051,
"card": {
"number": "4012001037141112",
"expiration_month": "12",
"expiration_year": "29"
},
"wallet": {
"type": "55",
"id": "BRL",
"fund_transfer": {
"pay_action": "FT",
"receiver": {
"account_number": "9999999999999995",
"account_type": "00",
"first_name": "Jane",
"middle_name": "T",
"last_name": "Smith",
"addr_street": "1 Main ST",
"addr_city": "SAO PAULO",
"addr_state": "SP",
"addr_country": "BRA",
"addr_postal_code": "1408000",
"nationality": "BRA",
"phone": "5511977778888",
"date_of_birth": "19901230",
"id_type": "03",
"id_num": "12345678900000"
},
"sender": {
"account_number": "9999999999999995",
"account_type": "00",
"first_name": "Jane",
"middle_name": "T",
"last_name": "Smith",
"addr_street": "1 Main ST",
"addr_city": "SAO PAULO",
"addr_state": "SP",
"addr_country": "BRA",
"addr_postal_code": "1408000",
"nationality": "BRA",
"phone": "5511977778888",
"date_of_birth": "19901230",
"id_type": "03",
"id_num": "12345678900000"
}
}
}
}
}
}Example of SDWO response
{
"idempotency_key": "855294c3-61d0-4da9-a3e4-f6038b92cd76",
"seller_id": "a9c99f03-025c-4251-a9f5-de73ef593523",
"payment_id": "4eaab005-5cdc-41eb-8598-6e36aaa1bb85",
"order_id": "cc44fe82-2712-453c-948b-52e346216e43",
"amount": "1200",
"currency": "BRL",
"status": "APPROVED",
"payment_method": "CREDIT",
"received_at": "2026-05-12T18:04:21.000Z",
"transaction_id": "016132078327616",
"original_transaction_id": "016132078327616",
"authorized_at": "2026-05-12T18:04:32.953Z",
"reason_code": "00",
"reason_message": "captured",
"acquirer": "GETNET",
"soft_descriptor": "EC TESTES PAGONXT - NA",
"brand": "VISA",
"authorization_code": "030603",
"acquirer_transaction_id": "000421185086"
}SDWO with 3DS Transactions
For transactions using 3DS, please follow all the steps provided in the Create a 3DS Authenticated Payment document.
When creating SDWO requests, the fields inside the wallet object must be filled as follows:
data.payment.wallet.idmust be set toBRLdata.payment.wallet.typemust be set to55
The table below shows the fields required for transactions with 3DS.
| Attribute | Type | Description | Example |
|---|---|---|---|
data.payment.xid | String | MPI identifier for each authenticated transaction. | yFNXIadjt0mEsP5ob44vQPd0Zbg= |
data.payment.ucaf | String | Authentication code encrypted by the card network. | B5kBAHNwQAAAAYdqmGESdiZwFVg= |
data.payment.eci | String | Electronic Commerce Indicator used for 3DS authentication. | 5 |
data.payment.tdsver | String | 3DS version used in authentication. | 2.3.1 |
data.payment.tdsdsxid | String | 3DS Server transaction identifier. | 9c2410c8-07c7-4e07-ac76-185e620970cf |
Example of SDWO with 3DS request
{
"idempotency_key": "{{$guid}}",
"request_id": "{{$guid}}",
"order_id": "{{$guid}}",
"link_id": "{{$guid}}",
"data": {
"amount": 1000,
"currency": "BRL",
"payment": {
"payment_id": "{{$guid}}",
"payment_method": "CREDIT",
"save_card_data": false,
"transaction_type": "FULL",
"number_installments": 1,
"dynamic_mcc": 6051,
"xid": "dyZb2stPifAatR7aaQufcNBgshE=",
"ucaf": "j0V7ephXEz91CBEEwhFpACkAAAA=",
"eci": "2",
"tdsver": "2.3.1",
"tdsdsxid": "790cb396-97b4-5a03-8000-0000104ec36b",
"card": {
"number": "5555555555554444",
"expiration_month": "12",
"expiration_year": "32"
},
"wallet": {
"type": "55",
"id": "BRL",
"fund_transfer": {
"pay_action": "FT",
"receiver": {
"account_number": "9999999999999995",
"account_type": "00",
"first_name": "Jane",
"middle_name": "T",
"last_name": "Smith",
"addr_street": "1 Main ST",
"addr_city": "SAO PAULO",
"addr_state": "SP",
"addr_country": "BRA",
"addr_postal_code": "1408000",
"nationality": "BRA",
"phone": "5511977778888",
"date_of_birth": "19901230",
"id_type": "03",
"id_num": "12345678900000"
},
"sender": {
"account_number": "9999999999999995",
"account_type": "00",
"first_name": "Jane",
"middle_name": "T",
"last_name": "Smith",
"addr_street": "1 Main ST",
"addr_city": "SAO PAULO",
"addr_state": "SP",
"addr_country": "BRA",
"addr_postal_code": "1408000",
"nationality": "BRA",
"phone": "5511977778888",
"date_of_birth": "19901230",
"id_type": "03",
"id_num": "12345678900000"
}
}
}
}
}
}Example of SDWO with 3DS response
{
"idempotency_key": "c26015f2-a412-4ddb-a126-6742b6acdc70",
"seller_id": "a9c99f03-025c-4251-a9f5-de73ef593523",
"payment_id": "5d11ac09-3343-4654-80f7-28a9f46dc25d",
"order_id": "6753f130-c8fd-4faf-8e5a-424d777aedaa",
"amount": "1000",
"currency": "BRL",
"status": "APPROVED",
"payment_method": "CREDIT",
"received_at": "2026-05-12T17:39:32.000Z",
"transaction_id": "MCC00CVWL0512",
"original_transaction_id": "MCC00CVWL0512",
"authorized_at": "2026-05-12T17:39:33.281Z",
"reason_code": "00",
"reason_message": "captured",
"acquirer": "GETNET",
"soft_descriptor": "EC TESTES PAGONXT - NA",
"brand": "MASTERCARD",
"authorization_code": "108850",
"acquirer_transaction_id": "000932182031",
"eci": "2"
}The response follows the same structure as the standard payment response. If additional authentication is required, the transaction may return
PENDINGwith 3DS challenge data.
CRYPTOGRAM_3DS
CRYPTOGRAM_3DS is a card payment method within Google Pay in which the transaction uses tokenized card credentials associated with a device and includes a security cryptogram generated during the payment process.
In this model, instead of the real card number, a tokenized card credential is used along with a cryptogram that proves the transaction was initiated from the user’s authenticated device.
The cryptogram is a dynamically generated cryptographic value that enables payment networks to validate the authenticity of the transaction.
| Attribute | Type | Description | Example |
|---|---|---|---|
data.payment.card | Object | Card data set. | — |
data.payment.card.number | String | Tokenized card number or device PAN returned by Google Pay. | 4761120000000148 |
data.payment.card.expiration_month | String | Two-digit card expiry month. | 12 |
data.payment.card.expiration_year | String | Two-digit card expiry year. | 25 |
data.payment.wallet | Object | Wallet data set. | — |
data.payment.wallet.id | String | Wallet identifier. For standard Google Pay transactions, always use 216. | 216 |
data.payment.wallet.type | String | Wallet type. For standard Google Pay transactions, always use 10. | 10 |
data.payment.tokenization | Object | Tokenization data set containing cryptographic values from the device. | — |
data.payment.tokenization.cryptogram | String | Cryptogram generated by the Token Service Provider. | AgAAAAAABk4DWZ4C28yUQAAAAAA= |
data.payment.tokenization.eci | String | Electronic Commerce Indicator associated with the tokenized payment. | 02 |
Example of request
{
"idempotency_key": "f6e5cb13-a5fe-46f9-b467-29bd13c29e59",
"request_id": "d808b53a-aa47-4484-8c99-cbe83624474c",
"order_id": "izgyekkmb8sd",
"data": {
"amount": 500,
"currency": "EUR",
"customer_id": "02587894152",
"payment": {
"payment_id": "izgyekkmb8sd",
"payment_method": "CREDIT",
"transaction_type": "FULL",
"number_installments": 1,
"card": {
"number": "4761120000000148",
"expiration_month": "12",
"expiration_year": "49"
},
"wallet": {
"id": "216",
"type": "10"
},
"tokenization": {
"cryptogram": "AgAAAAAABk4DWZ4C28yUQAAAAAA=",
"eci": "02"
}
},
"additional_data": {
"customer": {
"phone_number": "919999999",
"email": "[email protected]",
"document_number": "50506468",
"document_type": "uyci",
"name": "Jose da Silva",
"billing_address": {
"street": "R a",
"number": "1",
"district": "B",
"city": "City Z",
"state": "SP",
"country": "PT",
"postal_code": "05781000",
"complement": "N/A"
}
}
}
}
}Example of response
{
"idempotency_key": "2e7b86be-201d-4a82-a8f9-7102500faf78",
"seller_id": "7c966bb3-a8dc-4428-aa95-61081719ed80",
"payment_id": "omczgrvmxdt5",
"order_id": "omczgrvmxdt5",
"amount": "500",
"currency": "EUR",
"status": "APPROVED",
"payment_method": "CREDIT",
"received_at": "2026-02-23T15:10:52.664Z",
"original_transaction_id": "",
"authorized_at": "2026-02-23T15:10:53.688Z",
"reason_code": "00",
"reason_message": "Transaction authorized (payment/preauthorization)",
"acquirer": "GETNET",
"brand": "UNKNOWN"
}In sandbox environments, the brand field may be returned as UNKNOWN depending on the test token configuration.
Authorization Token
The Authorization Token flow is a Getnet processing model used when the merchant sends the Google Pay payment token to Getnet instead of sending card data fields.
When a customer pays with Google Pay, Google returns encrypted payment data in the paymentMethodData.tokenizationData.token property of the PaymentData response object.
In this model, the merchant does not send card.number, card.expiration_month, card.expiration_year, tokenization.cryptogram, or tokenization.eci as separate fields. Instead, the merchant must extract the value from paymentMethodData.tokenizationData.token, serialize it exactly as returned by Google Pay, encode it in Base64, and send the encoded value in data.payment.wallet.authorization_token.
Getnet uses the authorization_token to extract and process the payment data required for authorization.
Do not decrypt, change, trim, or remove any field from the token content before encoding it.
| Attribute | Type | Description | Required |
|---|---|---|---|
idempotency_key | String | Unique identifier to prevent duplicate charges. | Yes |
order_id | String | Merchant reference ID used for reconciliation. | Yes |
request_id | String | Trace identifier for idempotency audits and support follow-up. | Recommended |
data.amount | Number | Transaction amount in cents. | Yes |
data.currency | String | ISO currency code used in the transaction. | Yes |
data.customer | Object | Customer details such as name, email, phone, document, and billing address. Mandatory in production to reduce antifraud blocks. | Yes |
data.payment.payment_method | String | Payment method used for the transaction. | Yes |
data.payment.transaction_type | String | Defines how the transaction is processed. Examples: FULL, INSTALL_NO_INTEREST, INSTALL_WITH_INTEREST. | Yes |
data.payment.number_installments | Number | Number of installments. Use 1 for a single payment. | Yes |
data.additional_data.device | Object | Device fingerprint information for antifraud analysis, such as ip_address, device_id, and finger_print. | Production required |
data.payment.wallet | Object | Wallet data set. | Yes |
data.payment.wallet.id | String | Wallet identifier. Use 216 for standard Google Pay Authorization Token transactions. | Yes |
data.payment.wallet.type | String | Wallet type. Use 10 for standard Google Pay Authorization Token transactions or 55 for SDWO Authorization Token transactions. | Conditional |
data.payment.wallet.tag | String | Wallet tag. Required only for SDWO Authorization Token transactions. Use GP. | Conditional |
data.payment.wallet.authorization_token | String | Base64-encoded Google Pay payment token. Send the token content exactly as returned by Google Pay, encoded in Base64, without decrypting, changing, trimming, or removing any field. | Yes |
The antifraud payload must also include the following fields.
| Object / Field | Description |
|---|---|
customer.first_name | Customer’s first name. |
customer.last_name | Customer’s last name. |
customer.email | Customer email address. |
customer.phone_number | Phone number in international format. |
customer.document_type | Document type, such as CPF, DNI, or equivalent. |
customer.document_number | Document number without punctuation. |
customer.billing_address.street | Street name. |
customer.billing_address.number | Address number. |
customer.billing_address.district | District or neighbourhood. |
customer.billing_address.city | City. |
customer.billing_address.state | State or province. |
customer.billing_address.country | Country code. |
customer.billing_address.postal_code | Postal or ZIP code. |
additional_data.device.ip_address | Customer’s IP address. |
additional_data.device.device_id | Device fingerprint session ID. |
additional_data.device.finger_print | Fingerprint hash generated by the antifraud script. |
Example of request
{
"idempotency_key": "4c3cbdc2-b41e-4e1c-b7fe-90ed10abd9bb",
"request_id": "4802c01b-5aee-4962-a4f0-cff50439fda0",
"order_id": "izgyekkmb8sd",
"data": {
"amount": 500,
"currency": "EUR",
"customer_id": "02587894152",
"payment": {
"payment_id": "izgyekkmb8sd",
"payment_method": "CREDIT",
"transaction_type": "FULL",
"number_installments": 1,
"wallet": {
"id": "216",
"type": "10",
"authorization_token": "<BASE64_ENCODED_GOOGLE_PAY_PAYMENT_TOKEN>"
}
},
"additional_data": {
"customer": {
"phone_number": "919999999",
"email": "[email protected]",
"document_number": "50506468",
"document_type": "uyci",
"name": "Jose da Silva",
"billing_address": {
"street": "R a",
"number": "1",
"district": "B",
"city": "City Z",
"state": "PT",
"country": "PT",
"postal_code": "05781000",
"complement": "N/A"
}
},
"device": {
"ip_address": "192.0.2.1",
"device_id": "{{$guid}}",
"finger_print": "<DEVICE_FINGERPRINT>"
}
}
}
}Example of response
{
"idempotency_key": "ae010d29-997f-4b8b-9890-32ab6c927a85",
"seller_id": "7c966bb3-a8dc-4428-aa95-61081719ed80",
"payment_id": "c7pk1y8j97o0",
"order_id": "c7pk1y8j97o0",
"amount": "500",
"currency": "EUR",
"status": "PENDING",
"payment_method": "CREDIT",
"received_at": "2026-02-23T15:16:37.589Z",
"original_transaction_id": "",
"authorized_at": "2026-02-23T15:16:38.853Z",
"reason_code": "00",
"reason_message": "Transaction is pending of EMV3DS authentication",
"acquirer": "GETNET",
"brand": "UNKNOWN",
"additional_data": {
"_links": [
{
"rel": "3ds_html",
"type": "POST",
"href": "https://example.com/3ds/challenge",
"creq": "<3DS_CREQ_VALUE>"
}
]
}
}SDWO Authorization Token
For SDWO Authorization Token transactions, the merchant sends the Base64-encoded Google Pay payment token together with the SDWO fund transfer data.
Only for SDWO Authorization Token transactions:
data.payment.wallet.idmust be set toBRLdata.payment.wallet.typemust be set to55data.payment.wallet.tagmust be set toGP
Example of SDWO Authorization Token request
{
"idempotency_key": "{{$guid}}",
"request_id": "{{$guid}}",
"order_id": "{{$guid}}",
"link_id": "{{$guid}}",
"data": {
"amount": 1200,
"currency": "BRL",
"payment": {
"payment_id": "{{$guid}}",
"payment_method": "CREDIT",
"save_card_data": false,
"transaction_type": "FULL",
"number_installments": 1,
"dynamic_mcc": 6051,
"wallet": {
"type": "55",
"id": "BRL",
"tag": "GP",
"authorization_token": "<BASE64_ENCODED_GOOGLE_PAY_PAYMENT_TOKEN>",
"fund_transfer": {
"pay_action": "FT",
"receiver": {
"account_number": "9999999999999995",
"account_type": "00",
"first_name": "Jane",
"middle_name": "T",
"last_name": "Smith",
"addr_street": "1 Main ST",
"addr_city": "SAO PAULO",
"addr_state": "SP",
"addr_country": "BRA",
"addr_postal_code": "1408000",
"nationality": "BRA",
"phone": "5511977778888",
"date_of_birth": "19901230",
"id_type": "03",
"id_num": "12345678900000"
},
"sender": {
"account_number": "9999999999999995",
"account_type": "00",
"first_name": "Jane",
"middle_name": "T",
"last_name": "Smith",
"addr_street": "1 Main ST",
"addr_city": "SAO PAULO",
"addr_state": "SP",
"addr_country": "BRA",
"addr_postal_code": "1408000",
"nationality": "BRA",
"phone": "5511977778888",
"date_of_birth": "19901230",
"id_type": "03",
"id_num": "12345678900000"
}
}
}
}
}
}Example of SDWO Authorization Token response
{
"idempotency_key": "ff9c7c47-22f4-437b-af20-1f227a6bcaae",
"seller_id": "a9c99f03-025c-4251-a9f5-de73ef593523",
"payment_id": "21911ab4-85c7-4906-a56c-d75c5b7ea185",
"order_id": "e478c15e-fd0a-40f4-8b70-48233ca203bd",
"amount": "1200",
"currency": "BRL",
"status": "APPROVED",
"payment_method": "CREDIT",
"received_at": "2026-05-12T18:10:18.000Z",
"transaction_id": "MCC00CVZ20512",
"original_transaction_id": "MCC00CVZ20512",
"authorized_at": "2026-05-12T18:10:19.283Z",
"reason_code": "00",
"reason_message": "captured",
"acquirer": "GETNET",
"soft_descriptor": "EC TESTES PAGONXT - NA",
"brand": "MASTERCARD",
"authorization_code": "446201",
"acquirer_transaction_id": "000018185087"
}Comparison Table
Use the table below to identify which technical fields are required for each Google Pay processing scenario.
| Scenario | What merchant sends to Getnet | Card object | Tokenization object | Authorization token | 3DS data | Wallet fields |
|---|---|---|---|---|---|---|
| PAN_ONLY | Card PAN + expiry | Required | No | No | Optional or required by country/configuration | id=216, type=10 |
| PAN_ONLY with 3DS | Card PAN + expiry + 3DS authentication fields | Required | No | No | Required | id=216, type=10 |
| CRYPTOGRAM_3DS | Tokenized card/DPAN + expiry + cryptogram + ECI | Required | Required | No | Usually not required | id=216, type=10 |
| Authorization Token | Base64-encoded Google Pay payment token | No | No | Required | Handled according to token content and configuration | id=216, type=10 |
| SDWO card data | Card data + fund transfer data | Required | Depends on scenario | No | Optional or required by configuration | id=BRL, type=55 |
| SDWO Authorization Token | Base64-encoded Google Pay payment token + fund transfer data | No | No | Required | Depends on token content and configuration | id=BRL, type=55, tag=GP |
Additional resources
- Google Pay Web documentation
- Integration Web checklist
- Google Pay Android documentation
- Integration Android checklist
- Google Pay Web brand guidelines
- Google Pay Android brand guidelines
- Google Pay API Acceptable Use Policy
- Google Pay API Terms of Service
- Authentication for token management.
- Publish your integration - Web
- Publish your integration - Android