To provide the best Google Pay customer experience, we recommend that transit agencies implement the following enhancements:
- Accept EMV payments on mobile devices.
- Integrate with GTFS feeds.
- Offer fare parity.
- Identify the transaction as transit.
- Display transit receipts.
- Implement receipt roll-ups.
Accept EMV payments on mobile devices
The EMV tags listed in the following table must be set to accept near field communication (NFC) transactions from mobile devices.
|Tag||Description||Required?||Expected value||Format and limits||Example|
|9F15||Merchant Category Code (MCC)||Yes||
One of the following transit-specific MCCs:
A Merchant Name prefix, followed by a space, and then either a station name for underground/metro/rail or the route number for buses/trams.
Use ASCII encoding and the Latin alphabet with no special characters.
Limited to 32 characters.
|TfL Abbey Road DLR|
|9F16||Merchant ID||No||The Merchant ID provided by your payment processor.||Limited to a 15-digit alphanumeric.||1234|
|9F1C||Terminal ID||No||The Terminal ID provided by your payment processor.||Limited to an 8-digit alphanumeric.||001|
Integrate with GTFS feeds
We recommend that you integrate with Google’s static and real-time transit feeds (GTFS) system. In the future, Google plans to use GTFS data to look up route and station details for receipts.
Offer fare parity
If cap and transfer mechanisms are available on regular ticketing methods, make them available on open loop payments as well. Also, make sure that there's no fare difference between regular methods and open loop payments on single ride prices.
Identify the transaction as transit
Google Pay strives to provide the best user experience for transit. This includes the following features:
- Reduced requirements to unlock the user's mobile device, also known as velocity checks
- Receipts with additional transit details
To enable these features, the transaction must be identified as a transit transaction. The requirements for this vary by network.
The following table summarizes the network requirements:
|Network||Transit flag requirements|
If the following conditions are met, the transaction is flagged as transit by Mastercard SDK:
If the following conditions are met, the transaction is flagged as transit by Google:
If the following conditions are met, the transaction is flagged as transit by AMEX SDK (v2+):
|Discover||There's no transit-specific support available.|
Display transit receipts
Google Pay displays receipts with transit-specific details, such as stations, fares, and times.
To enable this feature, the following steps are required:
- Include the Merchant Category Code (MCC) as part of the 9F15 tag.
- Append the station or stop name as part of the 9F4E tag.
- Supply Google with reference data through the Open Loop Transit Google form. For more details, see Station and stop names spreadsheet.
Implement receipt roll-ups
With mobile payments and fare caps, users can be unsure about how much they're actually charged. To address this, Google Pay has developed receipt roll-ups to make this easier to understand.
At the end of the day, or every couple of days, the transit agency calculates the settlement, or final amount to be charged, to a user for that period. The card issuer sends the settlement details to Google Pay with an array of correlation IDs for all transactions related to that fare. Google Pay then rolls these taps up together to make a single receipt with the final fare.
To achieve this, transaction correlation IDs are used to identify which taps are related to that settlement, and Google Pay merges them together to make the single rolled-up receipt. Currently, to implement receipt roll-ups, custom logic needs to be implemented per transit agency.