Figure 1 shows the system architecture for Google Pay Open Loop Payment:
The following defines each part of the system architecture:
- Mobile device with Google Pay
- A user’s Android-powered mobile device that has a bank-issued payment card added. When a user adds a card to their Google Pay app, payment networks tokenize the card and add a device-specific card on the mobile device. For more information about tokenization, see How payments work.
- Transit reader
- A card reader at a transit station or bus entry point. The transit reader must support the EMV protocol to accept generic payments. Software on the reader might need to be updated by the transit operator to support mobile EMV payments. For information about the Google requirements for EMV tags, see Transit operator-specific enhancements. Unless the readers are always online with a reliable high speed internet connection, transit operators need to enable offline data authentication (ODA).
- Transit server
- The backend server. This is typically operated by transit operators or their systems integrator. Card readers often connect to the server on an intermittent basis and batch transactions together. Servers receive batch processing requests and pass requests on to the transit operator’s payment processor.
- Payment processor
- The processing firm. It de-tokenizes the tokenized payment credentials and completes the transaction with the issuing bank. For more information about payment processing, see How payments work.
- Token Service Provider (TSP)
- The TSP for payment networks provides services to tokenize and de-tokenize credit cards. Processors use them to retrieve payment credentials based on the tokens they received from the Google Pay app.
- Google server
- The server provides a link between Google's partners and the user's Android-powered mobile device. Transaction notifications such as authorization and settlement are received from the TSP. The Google servers use this information to show notifications and transaction receipts to the user.