[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eTo integrate with Google Wallet for transit, terminals must be EMV certified and support Offline Data Authentication (ODA) for faster contactless payments, especially with unreliable connections.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Wallet supports ODA for Visa, Mastercard, and Amex, ensuring quicker transactions even when terminals are intermittently offline.\u003c/p\u003e\n"],["\u003cp\u003eTransit terminals should be configured to handle potential card clashes caused by dynamic UIDs in Android devices by disabling UID clash logic or lowering polling speeds.\u003c/p\u003e\n"],["\u003cp\u003eFor terminals supporting both open and closed loop cards, prioritize closed loop cards using AID select, followed by open loop cards using PPSE.\u003c/p\u003e\n"],["\u003cp\u003eWhile Google Wallet doesn't currently support ePPSE, expressing interest in enabling it for transit is encouraged when submitting the onboarding form.\u003c/p\u003e\n"]]],["Integrating with Google Wallet requires EMVCo Level 1 and 2 certification for terminals. Transit terminals must support Offline Data Authentication (ODA) for fast, offline transactions. Terminals must manage card clash issues caused by Android's dynamic UIDs, either by disabling clash logic or reducing polling speed. For terminals supporting both open and closed-loop, prioritize closed-loop cards using AID select, then open loop using PPSE. Google Wallet does not support ePPSE.\n"],null,["To integrate with Google Wallet, the following basic functionalities must be\nimplemented.\n\nEMV certification\n\nTerminals need to meet EMVCo Level 1 and 2 certification. For more details, see the\n[EMVCo website](https://www.emvco.com/).\n\nOffline data authentication\n\nTo allow users quick passage through a terminal, transit terminals must support\n[Offline data authentication (ODA)](https://en.wikipedia.org/wiki/EMV#Offline_data_authentication_(ODA)). ODA is a cryptographic check that\nallows a payment terminal to perform offline authentication with a contactless payment card or\nmobile device. ODA provides a high level of trust that the card presented is genuine. It allows\nthe transit gate to open without a need for the user to wait for the network to process the\npayment. ODA is also used when transit terminals are intermittently offline. When the transit\nterminal is back online, the payment is processed.\n\nThe ODA feature is ideal for transit stations that have terminals that aren't always online or\nhave less-reliable connections. It's also used when payment processing time might slow the\ncommuter down as they enter the gate. The gates usually open within 500 milliseconds of when the\nuser taps their mobile device.\n\nTo use ODA, the transit terminal needs to be configured correctly. Contact your payment processor\nor system integrator for details on how to configure the terminals.\n\nGoogle Wallet supports ODA for the following networks:\n\n- Visa\n- Mastercard\n- Amex\n\n| **Note:** If a transit terminal is online with a highly reliable and fast internet connection, the open loop transaction still works. However, the transaction is treated like a simple merchant transaction rather than a specific \"transit\" tap.\n\nPolling and card clash\n\nPhysical NFC cards have a static UID. However, all Android mobile devices have a dynamic UID that\nchanges on every transaction. This adds a level of privacy for users because it prevents tracking, but\nit can cause a \"card clash,\" which is when transit terminals recognize more than one card in the\nNFC field.\n\nAs a user approaches a terminal with their phone, the NFC field strength increases and their\ndevice might start a transaction before the field is strong and stable enough to establish a\nconnection. If the phone loses connection, it stops and retries the transaction. This causes the\nmobile device UID to change, and if the terminal is configured with card clash logic, it might\nfalsely recognize more than one UID in a short span and stops the transaction. This situation is\nexacerbated when terminals with card clash logic have terminal polling speeds that are too high.\nTo resolve this situation, either disable the UID card clash logic or lower the polling speed of\nthe terminal.\n\nAID select, PPSE, and ePPSE\n\nFor terminals that support both open loop and closed loop cards, it's best to set them up in the\nfollowing order:\n\n1. All the closed loop cards that use AID select first.\n2. All open loop cards that use PPSE.\n\nePPSE\n\nePPSE is a new specification from EMVCo that helps provide information from the terminal to the\nmobile device about the type of transaction right before the transaction occurs. This allows the\nphone to choose a specific payment card, predefined by the user, for that particular type of\ntransaction. For transit, this could mean setting a default card for transit, which would override\nthe default payment card, when tapped on a transit terminal.\n\nGoogle Wallet does not currently support ePPSE, however if you are interested in enabling ePPSE\nfor transit, please indicate that when you submit the\n[open loop\ntransit form](https://support.google.com/pay/merchants/contact/open_loop_transit_onboarding) to Google Wallet."]]