- 運賃の上限とは何ですか?
-
運賃の上限とは、一定期間の乗車に対してユーザーに適用される上限のことです。使用状況に基づいて最適期間が設定されるパスを購入した場合、複数乗車の合計運賃はその上限を超えることはできません。運賃に上限がある端末を通して乗車した場合、交通機関のバックエンドがすべてのタップデータを収集し、1 日の終わりに請求金額を決定します。これは、パスを明示的に購入しなくても、ユーザーに最安の運賃を提供することを目的としています。
たとえば、ユーザーが次の運賃を購入できるとします。
- 片道: $1
- 1 日無制限パス: $10
- 1 週間無制限のパス: $25
運賃の上限を設定すると、ユーザーには常に最安の運賃が提供されます。次の例は、さまざまな状況でユーザーに請求される運賃を示しています。
- 1 回乗車: $1
- 3 回乗車: $3
- 1 日に 13 回乗車: $10
- 1 週間で 30 回乗車: $25
多くの交通機関には、ユーザーに割引運賃を適用するための運賃の上限が導入されています。こうした取引の結果をユーザーに適切に伝えるために、Google ウォレットでは領収書のロールアップを実装できます。詳しくは、運賃の上限を適用した場合のロールアップをご覧ください。
- オフライン データ認証(ODA)の仕組み
- Android 搭載のモバイル デバイスと決済デバイスでは、証明書を使用して、カード発行者とカード ネットワークの真正性を確認します。ただし、カード口座に利用可能な残高があるかどうかや、アカウントの上限を超えているかどうかは確認できません。取引が処理されたときにカードが不承認となった場合は、以降の使用ができないように、アカウントを拒否リストに追加することをおすすめします。
- ODA を実装するにはどうすればよいですか?
- 大半の大規模な決済ネットワークでは、交通機関が ODA を使用できるようになっています。ODA の実装仕様は決済ネットワークによって異なります。決済ネットワークと連携して、ODA の要件を把握し、その仕様に沿って実装することをおすすめします。
- モバイル デバイスでのデータの取り扱い
-
Google ウォレットでは、決済ネットワークとカード会社の鍵と証明書を使用します。これにより、オフラインでも決済デバイスでの認証が可能になります。
次の表に、Android 搭載デバイスで使用する鍵の認証の詳細を示します。
シークレット タップで端末と共有 デバイス カードの秘密鍵
ネットワーク キー ID
カード証明書(および公開鍵)
発行元の証明書(および公開鍵)
カードの秘密鍵はデバイスに残り、デバイスが正規のものであることの認証に使用されます。
カードが属しているネットワークを識別します。
カード会社が署名したカード証明書と Google ウォレットの公開鍵。
各カードには証明書とそれに対応する公開鍵があります。公開鍵はカード会社の秘密鍵によって署名されます。秘密鍵は、カード ネットワークによって署名されます。
- モバイル デバイスと決済デバイスはどのように通信しますか?
-
次の図は、Android デバイスと決済デバイスがデータを交換して相互に認証するための特定のシーケンスを示しています。
図 1. ユーザーのデバイスと端末間で交換されるデータ。
よくある質問
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-07-31 UTC。
[null,null,["最終更新日 2024-07-31 UTC。"],[[["\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"]]