- 什么是费用上限?
-
费用上限是一种向用户收取一段时间内的行程费用的做法。 乘客乘坐多趟车的总费用不得高于他们根据使用情况购买最优时段卡的费用。当用户乘车并在设有上限的终端上感应时,公交公司后端会收集所有感应数据,并在当天结束时动态确定收费金额。目的是在无需用户的情况下为其提供最优惠的机票价格 以明确购买任何卡券。
例如,假设用户可以购买以下票价:
- 单程:1 美元
- 一日无限畅享通票:10 美元
- 7 天无限畅享通票:25 美元
设置机票价格上限后,用户始终可以尽可能享受最优惠的机票价格。以下示例展示了在不同情况下向用户收取的费率:
- 单次行程:1 美元
- 三趟行程:3 美元
- 一天内 13 次行程:10 美元
- 一周内 30 次行程:25 美元
许多公交公司已实施上限票价,以代表用户享受折扣。为了更好地向用户传达这些交易的结果,Google 钱包允许您实现收据汇总。有关详情,请参阅 费用上限时的汇总信息。
- 线下数据身份验证 (ODA) 如何运作?
- Android 移动设备和付款终端使用证书来验证 发卡机构和支付卡网络的真实性。不过,他们无法验证 卡账号中有可用余额或低于账号限额。如果卡在交易处理后被拒,我们建议您将该账号添加到拒绝名单,以禁止其进一步使用。
- 如何实现 ODA?
- 大多数大型支付网络都允许将 ODA 用于过境目的。ODA 实施 具体说明因付款网络而异。我们建议您与付款网络合作,了解其对 ODA 的要求,并按照其规范实现 ODA。
- 如何处理移动设备上的数据?
-
Google 钱包使用来自付款网络和发卡银行的密钥和证书。这个 允许在离线模式下使用付款终端进行身份验证。
下表介绍了 Android 设备使用的密钥和认证详细信息:
Secret 在触碰付款期间与终端分享 设备 卡片私钥
广告联盟键 ID
卡证书(和公钥)
颁发者证书(和公钥)
卡的私钥会保留在设备上,用于验证设备的真伪。
用于标识卡片所属的网络。
发卡机构签名的 Google 钱包卡证书和公钥。
每张卡都有一个证书和相应的公钥,该公钥由发卡机构的私钥(由支付卡网络签名)签名。
- 移动设备如何与付款终端通信?
-
下图显示了允许 Android 设备和付款终端交换数据并相互进行身份验证的具体顺序。
图 1. 用户设备与终端之间交换的数据。
常见问题解答
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eFare capping ensures riders pay the lowest possible fare by automatically applying the best-priced pass based on their trip frequency.\u003c/p\u003e\n"],["\u003cp\u003eOffline data authentication (ODA) allows for faster transit payments by verifying card and network authenticity directly on the device, but balance checks still occur later.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Wallet leverages payment network and bank-issued keys to facilitate offline authentication between your device and the transit terminal.\u003c/p\u003e\n"],["\u003cp\u003eTransit agencies can implement receipt rollups in Google Wallet to provide users with clear breakdowns of their fare-capped transactions.\u003c/p\u003e\n"]]],["Fare caps ensure users pay the lowest possible fare based on usage, without needing to buy passes. Transit agencies collect ride data and dynamically calculate the optimal charge at day's end. Offline Data Authentication (ODA) uses certificates for device and terminal verification but cannot check account balances. ODA implementation requires collaborating with payment networks. Google Wallet uses payment network keys and certificates on the device for offline authentication and exchanges data during tap interactions.\n"],null,["# Frequently asked questions\n\nWhat are fare caps?\n\n: A fare cap is a practice in which users are charged for their rides over a period of time.\n The combined fares over multiple rides can't be more than if they had purchased the optimal\n period pass based on their usage. When the user rides and taps on the terminal that has a\n fare cap, the transit agency backend collects all taps and decides how much to charge\n dynamically at the end of the day. The aim is to give the user the best fare without the need\n to explicitly purchase any passes.\n\n For example, suppose users can buy the following fares:\n\n - Single trip: $1\n - One day unlimited pass: $10\n - One week unlimited pass: $25\n\n With fare caps in place, users always get the best fare possible. The following examples show\n the fares charged to the user in various circumstances:\n\n - One trip: $1\n - Three trips: $3\n - Thirteen trips in one day: $10\n - Thirty trips in one week: $25\n\n Many transit agencies have implemented fare caps to discount users' fares on their behalf. To\n better communicate the results of these transactions to users, Google Wallet allows you\n to implement receipt rollups. For more details, see\n [Rollups when fare capping](/wallet/tickets/open-loop/mobile-features/transaction-receipts#rollups-when-fare-capping).\n\nHow does Offline data authentication (ODA) work?\n: The Android-powered mobile device and the payment terminal use certificates to verify the\n authenticity of the card issuer and the card network. However, they can't verify whether the\n card account has an available balance or is under the account's limit. If a card gets declined\n later when the transaction is processed, then we recommend that you add the account to your\n denylist so that no further use is allowed.\n\nHow do I implement ODA?\n: Most large payment networks allow the use of ODA for transit purposes. ODA implementation\n specifications vary by payment network. We recommend that you work with the payment networks to\n understand their requirements for ODA and implement it by their specifications.\n\nHow is data handled on the mobile device?\n\n: Google Wallet uses keys and certificates from the payment network and issuing bank. This\n allows authentication with the payment terminal in offline mode.\n\n The following table describes the keys and certification details used by the\n Android-powered device:\n\n | | Secret | Shared with terminal during tap |||\n | Device | Card Private Key | Network Key ID | Card Certificate (and Public Key) | Issuer Certificate (and Public Key) |\n | | The card's private key remains on the device and is used to authenticate that the device is genuine. | Identifies which network the card belongs to. | Issuer-signed card certificate and public key for Google Wallet. | Each card has a certificate, and corresponding public key, that's signed by the issuer's private key, which is signed by the card network. |\n |--------|------------------------------------------------------------------------------------------------------|-----------------------------------------------|------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|\n\nHow does the mobile device communicate with the payment terminal?\n\n: The following diagram shows the specific sequence that allows the Android-powered device and\n the payment terminal to exchange data and authenticate each other.\n\n **Figure 1.** Data exchanged between the user's device and the terminal.\n\n \u003cbr /\u003e"]]