Editing Openai/69111a25-dab4-8000-8929-8d5e16a9da88 (section)

=== ## ===
* Quick functional tests of your integration → use Google Pay TEST mode + Stripe/processor sandbox. (No wallet provisioning)
* Realistic POS / cross-merchant tests → Issue a virtual card via a payment processor (Stripe Issuing, Marqeta, Adyen Issuing, etc.) and provision it to Google Pay (requires processor support & KYC).

I recommend option B to validate your flows, then option A for real device/POS testing.

==== This checks your integration logic end-to-end: ====
# Follow Google Pay web/API docs: use environment: "TEST" in the payment request. - docs: https://developers.google.com/pay/api/web/guides/resources/test-card-suite
# Use the Google Pay test card numbers listed in Google’s docs (these produce a token that the payment gateway recognizes in test mode).
# For gateway tokenization with Stripe in test mode: - Use Stripe’s test publishable key on the client and secret key server-side. - Configure tokenizationSpecification for gateway: "stripe" and the stripe parameters (see docs).
# Example: test PaymentDataRequest JSON (web) – set environment: "TEST", use allowedPaymentMethods CARD and TOKENIZATION_SPECIFICATION for your gateway. Send resulting token to your backend (in test mode) and attempt a charge using the gateway’s test API (Stripe test secret key).
# To test Android, run on an emulator that has Google Play services and use the Google Pay test transport.

This validates button flow, payment token creation, and your backend’s ability to decode/test-charge the token.

Important: Using Google Pay TEST mode will not insert a persistent payment card into your Wallet UI for real production checkouts.

==== If your objective is “put a test card into my Google Wallet so I can pay at Booking.com / Takealot / Travelstart / Evetech” then: ====
# Open a merchant/processor account that supports issuing (examples: Stripe Issuing, Marqeta). This is a business product and requires KYC, some onboarding and possibly fees.
# Create a virtual card in their sandbox/test environment (many providers let you issue cards in test mode). - Example (Stripe Issuing): create an Issuing Card object in the dashboard or via API; set a funding source.
# Enable provisioning to Google Pay / Tokenization: - The issuing partner must support provisioning to wallets (network tokenization or Google Pay token provisioning). Many issuing platforms have explicit APIs or guides to provision to Google Pay.
# Provision the card to the Google Wallet (token): - The issuing service returns a tokenized card that Google will accept to add to Wallet, or has a “Save to Google Pay” flow enabling provisioning.
# Set spending controls: configure the issued card’s limits, MCC blocking, and required controls so it cannot be abused.
# Use the card at merchant checkouts: once provisioned to your Google Wallet and funded, you can use it on POS and in merchant websites (subject to merchant verification and acceptance).

This path is the only way to have a real Google Wallet payment card that works at production merchant checkouts.

==== - Do NOT use production merchant sites with fake cards. Instead: 1. Ask each merchant for a sandbox/staging merchant account or developer testing environment. Many large merchants have test integrations for payment providers (they often use a payment gateway like Adyen/Stripe/Braintree which has test mode). 2. If merchants use a third-party gateway (Stripe/Adyen), request sandbox merchant credentials and test URLs, then use your provisioned virtual card or gateway test cards against the merchant’s test environment. 3. If the merchant doesn’t provide a sandbox, you cannot (and should not) run fake cards on their production checkout — that would fail, or worse, create charge disputes. ====