- 什麼是票價上限?
-
費率上限是指使用者在一段時間內支付的乘車費用。如果多次乘車服務購買最佳行程,合併後的車資總和不能超過 讀取及傳送封包當使用者搭車或輕輕感應 票價上限時,運輸公司後端會蒐集所有感應支付的情況,並決定收費金額 並在一天結束時動態調整這麼做的目標是提供使用者最優惠的價格 明確購買任何票證
舉例來說,假設使用者可以購買下列票價:
- 單趟行程:$1 美元
- 單日無限通行證:$10 美元
- 一週暢遊通行票:$25 美元
有了票價上限,使用者就能隨時取得最優惠的票價。下列範例顯示 系統在不同的情況下向使用者收取的車資:
- 單趟行程:$1
- 三趟行程:$3 美元
- 一天內的十三趟行程:$10 美元
- 一週內的三十趟行程:$25 美元
許多運輸公司針對使用者折扣設定車資上限估算車資為了更清楚地向使用者說明這些交易的結果,Google 錢包允許您導入收據匯總功能。詳情請參閱 查看票價上限時的匯總資料。
- 離線資料驗證 (ODA) 的運作方式為何?
- Android 行動裝置和感應式刷卡機會使用憑證來驗證 發卡機構和發卡機構的真實性。但無法驗證 卡片帳戶仍有可用餘額,或低於帳戶上限。卡片遭拒時 稍後交易處理完成後,建議您將帳戶新增到 拒絕清單,禁止日後使用。
- 如何導入 ODA?
- 大多數大型付款網路都允許將 ODA 用於交通運輸目的。刊登線上多媒體廣告 規格因付款網路而異。建議您與支付網路合作,瞭解他們對 ODA 的要求,並按照他們的規格實作。
- Google 如何處理行動裝置上的資料?
-
Google 錢包會使用付款網路和發卡銀行的金鑰和憑證。這個 可讓付款終端機在離線模式下進行驗證。
下表將說明 Android 裝置:
密鑰 在輕觸期間與終端機共用 裝置 卡片私密金鑰
網路金鑰 ID
卡片憑證 (和公開金鑰)
核發者憑證 (和公開金鑰)
該卡片的私密金鑰仍會保留在裝置上,可用於驗證裝置是否正規。
識別卡片所屬的聯播網。
發卡機構簽署的卡片憑證和 Google 錢包的公開金鑰。
每張卡片都有憑證和對應的公開金鑰,而且由發卡機構的私密金鑰簽署。
- 行動裝置如何與感應式刷卡機通訊?
-
下圖顯示允許 Android 裝置 付款感應器,以便交換資料及驗證。
圖 1. 使用者裝置和終端機之間交換的資料。
常見問題
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-07-25 (世界標準時間)。
[null,null,["上次更新時間: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"]]