Google Pay™

Introduction

Google Pay™ is a contactless payment service that enables users to make payments both online and in physical stores using Android devices. It simplifies payments by securely storing card details and allowing transactions via NFC technology.

Transactions use tokenization to protect sensitive card information, replacing the actual card number with a virtual account number. This ensures secure processing without exposing card details. Google Pay™ supports one-time transactions as well as subscriptions and other recurring payments, based on merchant configurations.

Google Pay™ is available in various regions worldwide, supporting multiple currencies. For online and in-app payments, KC UPCF Web SDK securely collects payment details, which are then transmitted to Google's servers for processing and authorization. The entire flow keeps sensitive data hidden from the merchant, providing customers with a secure and easy payment experience.

There are two ways to test the integration: one using a Google Wallet™ account with personal cards on an Android device, and another using Google-provided test cards in the Chrome browser. The first method simulates real payment flows without charging the card and is suitable for production readiness. The second is intended for early-stage testing and allows basic validation during development.

Workflows and Transaction Types

Integration flow for merchants

Merchants can integrate Google Pay™ for seamless in-app and web payments. For authorization and capture workflows, refer to Google Pay™ Authorization for Guest Payment and Google Pay™ Capture.

CIT (Customer Initiated Transactions)

Google Pay™ CIT transactions require active customer participation at checkout. Customers select Google Pay™ and authenticate their transactions using biometric authentication such as fingerprint or facial recognition, or a PIN. These transactions are securely processed through KontoCloud's UPCF Web SDK, ensuring compliance with PCI DSS standards.

Google Pay™ CIT transactions are initiated using the 1.38 Init Authorize, which verifies the payment details and obtains real-time authorization. These transactions support seamless one-time purchases, guest checkout, and payments by registered users.

Merchants must ensure that Google Pay™ CIT transactions include strong customer authentication (SCA) to meet regulatory requirements and prevent unauthorized usage. For a detailed overview of the CIT flow, refer to the Google Pay™ Authorization and Capture documentation.

MIT (Merchant Initiated Transactions)

Google Pay™ MIT allows merchants to initiate payments without direct customer interaction. MIT payments are primarily used for subscription payments (automatic recurring payments for services or memberships), deferred payments (payments processed after the service is completed), and unattended MIT payments, used for transactions without customer presence.

To enable MIT transactions, merchants must first process a CIT transaction where the customer explicitly consents to storing their Google Pay™ credentials. Payment details are securely stored, and MIT transactions are later processed using 1.39 Complete Authorize API.

MIT transactions must comply with strict authentication and security requirements, ensuring that customer consent is obtained before storage and that retry management policies are properly implemented. More details can be found in the MIT section.

In the case of an unattended MIT payment, Google Pay™ can be stored securely. Merchants are allowed to use stored Google Pay™ credentials under specific use cases outlined in this documentation section.

info

Google Pay™ supports VISA and Mastercard transactions.

Cancel and Refund

Google Pay™ allows for transaction cancellations and refunds, which can be managed via API. Refunds can be issued in full or partial amounts, depending on the merchant's refund policy. Refunds are processed back to the original payment method and typically follow standard processing times set by the customer's issuing bank. Merchants can initiate refunds using the Google Pay™ Capture API.

Storable Payment Option (SPO)

important

Google Pay™ can be stored as a payment option only for subscriptions and unattended MIT payments. Transactions processed through a Google Wallet™ account rely on device authentication and can only be completed using payment credentials saved on the customer's Android device.

Storing Google Pay™ facilitates recurring transactions by eliminating the need for customers to manually authenticate payments each time. Merchants must follow strict security measures when storing Google Pay™, ensuring compliance with PCI DSS and Google's payment security requirements. Unauthorized storage or use outside of approved MIT scenarios is not allowed. For detailed steps, please check here.

Transaction Status Flow

The Google Pay™ lifecycle follows a typical flow of statuses: Authorized, Captured, Refunded, or Canceled, depending on the transaction requirements.

KC UPCF Web SDK integration

Google Pay™ transactions are processed through the KC UPCF Web SDK for efficient integration directly into your online checkout experience. For optimal performance and user experience, merchants should ensure their integration aligns with Google's guidelines outlined in their Web Developer Documentation, as well as confirm compatibility with Google Wallet™.

Customizable Google Pay™ Button

To customize the Google Pay™ button within an API request, include the googleButtonType and googleButtonStyle parameters in criteria (see example below). The "type" parameter defines the text displayed on the button, such as a standard payment label or a subscription-related prompt, while "style" controls the button's visual theme to match different background and branding requirements. These parameters determine how the Google Pay™ button is generated on the page, ensuring flexibility in its presentation. By specifying these attributes, merchants can align the button's appearance with their checkout flow while maintaining compliance with Google's UI guidelines. Google does not support the creation of your own custom Google Pay™ button from scratch.

For visual consistency, please refer to Google's Brand Guidelines for additional styling and placement requirements.

Example request

Path:

PUT {baseURL}/payment/initAuthorize

Header:

Content-Type: application/json
Accept-Language: en-US
X-Auth-Token: eyJjb25uZW***AwMjZ2PTQifQ==
User-Agent: ***

{
  "partnerReference": "eb9640b0-f731-4abf-8752-37e8280c9ee9",
  "programAccno": "7228894817",
  "accno": "7228905548",
  "accnoType": "01",
  "presentationAmount": 100,
  "presentationCurrCode": "EUR",
  "presentationUsage": "V Purchase:2xPremiumWidgets. Merchant:WidgetsGmbH. CUSTREF:52650FD95.",
  "useDifferentBillingAddress": false,
  "paymentOptionCode": "GGLPAY",
  "criteria": [
    {
      "name": "googleButtonType",
      "value": "order"
    },
    {
      "name": "googleButtonStyle",
      "value": "black"
    }
  ],
  "localDate": "2025-01-28",
  "localTime": "125849"
}

The following parameters can be configured:

googleButtonType	Representation
book
buy
checkout
donate
order
pay
plain
subscribe

googleButtonStyle	Representation
default
white
black

info

The Google Pay™ button is rendered dynamically via Google's API, and should not be hardcoded or recreated manually.

Multiple Domains Support

To support multiple merchant domains for Google Pay™, merchants need to register them with Google, as only the domains added to Google Pay's whitelist will be valid for use. Please see the integration section for Google Pay™ Console - Registration of the shop domain below.

info

The registered domain automatically extends to its sub-directories as listed below, allowing Google Pay™ transactions on localized pages without requiring separate configurations.

your-shop.com
your-shop.com/de
your-shop.com/fr

Merchants must align with their Product Solution Specialist to ensure all relevant domains are configured within the backend program settings before initiating Google Pay™ transactions. The domain should be provided without "https://", as the API handles secure connections internally. Merchants must align with their Product Solution Specialist to ensure all relevant domains are configured within the backend program settings before initiating Google Pay™ transactions. The domain should be provided without "https://", as the API handles secure connections internally.

The domain submitted to Google should match the exact origin where the payment sheet is rendered and should not forward traffic to a different domain or staging environment. This helps Google™ verify the integration.

Google Pay™ Integration Prerequisites

Integration of Google Pay™ payment option includes registration, preparation and testing of the new payment option. To begin the integration process for Google Pay™ via Hosted Checkout, follow the steps outlined below, starting with the Web Developer Documentation and integration checklist.

info

The dedicated Product Solution Specialist will be your partner during the integration process. The dedicated Product Solution Specialist will be your partner during the integration process.

After the testing is successful, it is possible to continue with the preparation for production deployment.

The merchant provides integration details to both Google™ and dedicated Product Solution Specialist during the integration process. The merchant provides integration details to both Google™ and dedicated Product Solution Specialist during the integration process.

1. Registration with Google™ and JPM MPS

1.1. Google Console

Merchants need to register their business with Google™ by creating an account and submitting the required legal details at Google™ Console. This includes company information, business type and payment processing preferences.

As part of the initial setup flow, the merchant must accept the Google Pay™ and Wallet™ APIs Acceptable Use Policy and Terms of Service directly in the Business Console before continuing with test or production integration. This step is required before testing or going live with the integration.

1.2. Merchant ID

After registration, a unique Merchant ID is generated. The ID is displayed in the Business Information section below the company name. Merchants should provide the Merchant ID to the Product Solution Specialist for configuration.

1.3. KC UPCF Web SDK

The next step is the integration with JPM MPS using KC UPCF Web SDK.

2. Test Google Pay™ on the testing environment

Google™ provides two methods for testing transactions with Google Pay™.

2.A. Google Wallet™ with Personal Card

• This method allows testers to use a real Google Wallet™ account with personal cards. These transactions do not involve real payments, and no funds are debited. Instead, this option helps validate the integration using live payment credentials.
• To use this method, testers must join the Google Test Group required for testing with production cards and must have a working Android device with Google Wallet™ installed, including a valid Visa or Mastercard card.
• Testing with a personal Google Wallet™ account is supported only on physical Android devices that have NFC enabled and the Google Wallet™ app installed. iOS devices and emulators are not supported for this type of test.
• The CRYPTOGRAM_3DS option must be configured in SmartPay settings by your Product Solution Specialist to ensure proper handling of 3D Secure cryptograms during transactions for authentication.
• Please refer to Google™'s Test with sample tokens.

2.B. Test cards

• Google™ offers the use of test cards option for developers looking to perform basic Google Pay™ test transactions without using an Android device. Google™ test cards are supported exclusively in the Chrome browser and require integration via ACI Worldwide.
• To enable this testing method, testers must subscribe to the Google Test Card Suite Subscription by signing in with their Google™ account through Chrome and follow the subscription process. To unsubscribe, testers must navigate to Google Groups and remove their subscription.
• SmartPay settings should be configured by your Product Solution Specialist (PAN_ONLY) beforehand to facilitate the use of test cards.
• For more information, please visit Google™'s documentation on Test with sample cards.

Both testing modes align with Google's testing recommendations and ensure correct behavior during test or live review.

info

For authorization, add paymentOptionCode: GGLPAY. For authorization, add paymentOptionCode: GGLPAY.

Merchants can use end-to-end functionality for seamless payment completion. When a tester clicks on the Google Pay™ button, the process maintains the browser's user activation behavior, allowing the Google Pay™ API to display a payment sheet without interference from pop-up blockers. The Google Pay™ payment sheet is a secure interface that appears when a customer selects Google Pay™ as their payment method and displays the customer's saved payment methods (e.g., the cards stored in Google Wallet™), shipping address and contact details, allowing them to confirm and complete the payment with a single tap. The sheet is presented as an overlay or modal directly in the browser or app and is managed entirely by Google, so the merchant never handles sensitive payment data.

important

Before processing the transaction, the merchant must display a final price to the user. If the amount to be charged has varied based on data received from the Google Pay™ API, the merchant is expected to show a confirmation page with the final price.

To remain compliant, the Google Pay™ payment sheet should only be displayed after the customer actively interacts with the page, such as clicking a button. Triggering the payment sheet automatically or in the background is not supported and may prevent it from opening. This helps maintain browser compatibility and meets user interaction requirements enforced by Google.

info

Storing Google Pay™ is allowed only in case of subscriptions and unattended MIT payments.

important

In the test TEST environment, Google™ offers two ways to test transactions. Merchants can use Google-provided test PANs, or they can use a regular Google Wallet™ account with personal cards, which are not used to process real payments and are not debited.
For PROD environment, only Google Wallet™ cards are accepted. In the test TEST environment, Google™ offers two ways to test transactions. Merchants can use Google-provided test PANs, or they can use a regular Google Wallet™ account with personal cards, which are not used to process real payments and are not debited.
For PROD environment, only Google Wallet™ cards are accepted.

3. Production Prerequisites

Once the testing is done, the next step is preparing for the production deployment and implementing the procedure for going live. During this phase, the merchant provides integration details to both Google™ and dedicated Product Solution Specialist for activation: Once the testing is done, the next step is preparing for the production deployment and implementing the procedure for going live. During this phase, the merchant provides integration details to both Google™ and dedicated Product Solution Specialist for activation:

• Registration of Shop domain that hosts the checkout.
• Registration of Google Pay™ connector URL and Google Pay™ integration type.
• Screenshots of the checkout.
• Production activation.

Before going live in production, the merchant should submit integration details to Google™ via the Google™ Console.

Before submitting the integration to Google™ for validation with a PaymentsClient configured for a TEST environment, ensure that the exit criteria are fulfilled for each of the following functional and branding checks.

3.1. Registration of the shop domain

3.1. Registration of the shop domain

Register the Shop domain that hosts the checkout to Google™ through Google Console.

info

Provide this domain to the dedicated Product Solution Specialist upon registration with Google. Provide this domain to the dedicated Product Solution Specialist upon registration with Google.

The registered domain should correspond to the environment where the Google Pay™ button is implemented, as mismatches between domain and integration setup may lead to transaction issues.

3.2. Registration of the Google Pay™ Connector and Integration Type

3.2. Registration of the Google Pay™ Connector and Integration Type

Register the Google Pay™ connector URL: api.googlepay.upcf.jpmmps.com through Google™ Console. For Google Pay™ API integration type, select: Gateway.

To ensure that transactions are processed correctly, the connector URL used in the Google Console should be entered exactly as provided during onboarding. Using a different or modified URL may prevent the payment request from reaching SmartPay's systems.

3.3. Screenshots of the Checkout for Google Pay™

Please provide the following screenshots of the Checkout for Google Pay™ through Google Console:

• Item selection - screenshot where the customer views or selects products or services before checkout.
• Pre-purchase page - the order summary page showing selected items and total price before choosing a payment method.
• Payment method selection - screenshot where the customer chooses Google Pay™ as their preferred payment option.
• Google Pay™ API payment sheet - the secure Google interface displaying saved payment methods, shipping info, and a confirmation button.
• Post-purchase confirmation - page confirming that the payment was successful and the order was placed.

info

Android doesn't allow taking a screenshot of these screens, so the screenshot should be taken using another device.

Checkout screenshots submitted for review should represent actual user flows with real data and complete UI. Placeholder content or mockups are not accepted as part of the production review by Google™. Please include full context for each screenshot, with visible product names, pricing and a properly rendered Google Pay™ button.

3.4. Request to go live

After all the steps have been completed, the merchant can request activation for PROD integration through Google™ console.

important

Google Pay™ transactions with SmartPay require device authentication through the Google Wallet™ app. Only cards stored in Google Wallet™ can be used for payments, transactions without device authentication are not supported.

After you submit your integration for review, Google™ may request additional information, test evidence, screenshots or clarifications. Merchants should promptly coordinate with their Product Solution Specialist to apply required changes. Google's review process typically takes 5-7 business days after submitting production access. Delays may occur if screenshots or test steps are missing.

info

Ensure that the PaymentsClient is set to PRODUCTION only once the integration has been reviewed and approved by Google.

Useful links when integrating Google Pay™

• Google Pay™ Web developer documentation
• Google Pay™ Web integration checklist
• Google Pay™ Web Brand Guidelines
• All merchants must login to Google Pay™ Business Console and accept Google Pay™ APIs Acceptable Use Policy and agree to the terms defined in the Google Pay™ API Terms of Service.
• Merchants can regularly monitor the Google Pay™ Status Dashboard for any ongoing issues or outages that could impact payment processing.

Google Pay™ Test Data

For testing Google Pay™, please follow the instructions above.