Skip to main content

Google Pay and Apple Pay

Wasp takes Google Pay™ and Apple Pay payments in every checkout it offers: on Wasp's own payment page (Hosted Checkout), through the Wasp Checkout SDK inside your page (Embedded Checkout), and in a checkout you build yourself (client-owned collection). Not sure which of those you are building? Start with Choose your integration.

This page sets out what each wallet needs from you, and from Google or Apple, to test and to go live, in each checkout. The two wallets ask for different things, and the difference matters when you plan.

What Wasp does for you​

  • Wasp is the Google Pay payment gateway and the Apple Pay payment platform. It holds every key and certificate that opens wallet payment data. You never receive them and never need them.
  • You never decrypt a wallet payment. Whichever checkout you use, the wallet's encrypted payment data reaches Wasp unopened, and Wasp decrypts it and processes it like a card payment.
  • A wallet is a payment method, not a separate integration. Stratsol switches each wallet on for your merchant, and it then appears inside the checkout you built. Adding a wallet later does not change the calls your backend makes.

What each wallet covers​

  • Google Pay through Wasp is a web integration. It runs in compatible browsers on desktop and mobile, including on Android. A native Android app integration is a different Google integration, which Wasp does not offer; Android customers pay through their mobile browser like any other web customer.
  • Google Pay through Wasp carries Mastercard and Visa. An eftpos card is not payable through the Google Pay button, so do not present Google Pay as accepting every card your merchant accepts.
  • Apple Pay through Wasp carries Visa, Mastercard and eftpos, for whichever of those your merchant is set up to accept.
  • Apple Pay appears only where the customer's browser and device support it. The customer approves the payment on their Apple device.
  • The buttons belong to Google and Apple. Wasp's payment page and the Wasp Checkout SDK draw each provider's own button. If you build your own checkout, you use their buttons and follow their guidelines, linked below.

Google Pay: what you arrange, and when​

What you arrange with Google depends on whose page the Google Pay button is on.

Your checkoutTo test in the sandboxTo go live
Hosted Checkout: the payment page is Stratsol'sNothing with Google.Nothing with Google. The page shows Google Pay under Stratsol's own Google Merchant ID, and Google's review and approval of that page are Stratsol's.
Embedded Checkout: the Wasp Checkout SDK, on your pageNothing with Google.Your own Google Merchant ID, and Google's approval of your website. You give the ID to Stratsol, which records it on your merchant, and Wasp Checkout presents it to Google on your page: it never goes in your code. See Going live with Google Pay on your own page.
Client-owned collection: your own Google Pay integration, on your pageNothing with Google. Google's TEST environment needs no Google Merchant ID.Your own Google Merchant ID, and Google's approval of your integration. See Going live with Google Pay on your own page.

In every checkout, Wasp stays your Google Pay gateway, and your Wasp Merchant ID identifies your merchant to it. A Google Merchant ID, where you need one, is a different identifier: Google issues it to your business, and it is never your Wasp Merchant ID.

Going live with Google Pay on your own page​

When the checkout page is yours, with Embedded Checkout or client-owned collection, Google must approve your integration before your site can take real Google Pay payments. Stratsol cannot do this for you: the page, and the approval, are yours. Google's review is the step you do not control, so start it well before you plan a launch date.

  1. Get your Google Merchant ID. In the Google Pay & Wallet Console, set your type of business to Merchant and complete your business profile. Open Google Pay API, choose Get started, and accept the Google Pay API Terms of Service and Acceptable Use Policy. Your Google Merchant ID is shown at the top right of the Console. With Embedded Checkout, give it to Stratsol, which records it on your merchant; with client-owned collection, your page sends it to Google itself.
  2. Check your integration against Google's requirements. Work through Google's integration checklist in Google's TEST environment, and check every place your site shows Google Pay against Google's brand guidelines.
  3. Submit your website. In the Console, add your website under Google Pay API's website integrations. Enter the domain your checkout page runs on, choose the Gateway integration type (Wasp is your gateway), upload screenshots of your purchase flow, and submit it for approval.
  4. Pass Google's review. Google reviews your integration's user experience and its Google Pay branding across the whole purchase flow: from choosing what to buy, through choosing a payment method and Google's payment sheet, to the page after payment. If Google asks for changes, make them and submit again.
  5. Switch to production. Once Google has approved your integration, your page uses Google's PRODUCTION environment, and your backend uses the production address and credentials Stratsol issues. With Embedded Checkout, Wasp Checkout presents your Google Merchant ID for you; without it recorded on your merchant, the Google Pay button does not appear on your page in production.

Google describes these steps itself in Publish your integration. The exact changes to your page and backend are in the integration guides for Embedded Checkout and client-owned collection, which you get access to after you register.

Apple Pay: what you arrange, and when​

Apple's requirements are not Google's. There is no Apple merchant identifier for you to obtain and nothing to submit to Apple for review, in any checkout. On your own page, what matters is the domain the payment sheet opens on: Wasp needs it to be HTTPS and authorised from your first test, and when you go live Apple also verifies it.

Your checkoutTo test in the sandboxTo go live
Hosted Checkout: the payment page is Stratsol'sNothing with Apple. The page runs on Stratsol's domain, which Stratsol has verified with Apple.Nothing with Apple.
Embedded Checkout or client-owned collection: on your pageA real HTTPS domain with a valid certificate, authorised by Stratsol as one of your checkout domains. Wasp registers the domain with Apple under Stratsol's Apple identity. Apple's sandbox does not verify domains, so Stratsol's domain association file is not needed to test.The same, on the domain your live checkout runs on, which must also serve Stratsol's domain association file exactly as issued: Apple verifies the domain with it before Wasp can register it. You need no Apple Developer account, Apple merchant identifier or Apple certificate.

localhost, a self-signed certificate, or a tunnel whose hostname changes will not work for Apple Pay on your own page.

Testing Apple Pay needs Apple's sandbox​

In every checkout, including Hosted Checkout, a test payment is approved on an iPhone or iPad signed in with an Apple Sandbox Tester account, using one of Apple's sandbox test cards. Only a member of an Apple Developer Program team can create a Sandbox Tester, in App Store Connect. If your organisation has no membership, arrange one before you plan Apple Pay testing.

In production, customers pay with their own Apple accounts and real cards, and Apple's sandbox testers and test cards do not work there.

Customer authentication​

Some card payments need the customer to confirm the payment with their bank (3D Secure) before they can be approved.

  • Google Pay returns either a device token, which is already authenticated, or the card itself, which Google calls PAN_ONLY. Google Pay PAN_ONLY transactions follow the same 3D Secure authentication rules as conventional card transactions. Stratsol manages the merchant's authentication policy, and your integration must support the authentication step: on Hosted Checkout the Wasp page runs it for you, and on your own page the integration guides show how.
  • Apple Pay payments are authenticated on the customer's device, so an Apple Pay payment never needs this step.

The terms you accept​

Offering a wallet means accepting its provider's terms, whichever checkout you use:

Your privacy notice​

A wallet payment carries your customer's personal data: with the payment, Apple and Google return the name and billing address the customer chose to share, and Wasp processes the payment on your behalf. Your own website must tell your customers what is collected, how it is used and who it is disclosed to. Apple's terms (section 7) require, at a minimum, a link to your privacy policy from your website, and (section 3.3) that you use Apple Pay payment data only to process the payment and for other uses you have told the customer about.

That applies in every checkout. With Hosted Checkout the payment page is Stratsol's, but your customer starts and finishes on your website: link your privacy policy there, including from the page that sends the customer to pay. Stratsol's privacy notice covers this developer portal only, not your customers or their payments.

Google and Apple documentation​

Google's and Apple's own guides sit alongside the Wasp ones. Their branding rules also apply to how you mention each wallet on your own site, whichever checkout you use.

From Google:

From Apple:

What to do next​

Last updated on