# Technical architecture

Figure 1 shows the technical architecture for an open loop payment and its interaction with
Google Wallet:
![](https://developers.google.com/static/wallet/tickets/images/sys_arch_1.png) **Figure 1.** Data flow between Google Wallet, the TSP, and the transit agency.

The following are definitions for each part of the technical architecture.

Mobile Device with Google Wallet

:   Mobile devices powered by Android OS allow users to securely add their cards to
    Google Wallet. Google Wallet facilitates the process of tokenization, which is when
    payment networks tokenize the card and add a device-specific token on the mobile device. For
    more information about tokenization, see
    [How payments work](https://support.google.com/androidpay/merchant/answer/6345242).

    Google Wallet is compatible with the majority of modern Android devices across multiple
    manufacturers and form factors. For minimum requirements, see
    [Prerequisites](https://developers.google.com/wallet/tickets/open-loop/get-started/prerequisites).

Transit Reader

:   Transit readers are typically card readers at a transit station or bus entry point. The
    transit readers and terminals receive a payment credential from Google Wallet in the same
    way that they receive a payment credential from a physical, contactless credit or debit card. To
    accept contactless payments, the transit reader must be compliant with EMV protocol. For more
    information, see
    [Basic functionality requirements](https://developers.google.com/wallet/tickets/open-loop/technical-integration/basic-requirements).

    In order for the readers to become compliant and support mobile EMV payments, they might
    need software upgrades. For more information about the Google requirements for EMV tags, see
    [Basic functionality requirements](https://developers.google.com/wallet/tickets/open-loop/technical-integration/basic-requirements).

    For readers that are offline or without a reliable high-speed internet connection, the
    transit operations are required to enable
    [offline device authentication](https://developers.google.com/wallet/tickets/open-loop/technical-integration/basic-requirements#oda) (ODA). For minimum requirements, see
    [Prerequisites](https://developers.google.com/wallet/tickets/open-loop/get-started/prerequisites).

Transit Server
:   The backend server. Transit operators or their systems integrators typically operate it. 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 payment processor is the firm that handles transactions. 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](https://support.google.com/androidpay/merchant/answer/6345242).

Token Service Provider (TSP)
:   The TSP for payment networks provides services to tokenize and de-tokenize credit and debit
    cards. Processors leverage TSPs to retrieve payment credentials based on the tokens the
    Google Wallet app sends to them.

Google Server
:   The server provides a link between Google's partners and the user's Android-powered mobile
    device. The TSP sends transaction notifications, such as authorization and settlement
    notifications, to the Google servers. The Google servers use this information to show
    notifications and transaction receipts to the user.