Google Standard Payments の世界では、キャリア決済はトークン化された支払い方法（FOP）とみなされます。つまり、Google と決済インテグレータは、トークンを確立するためにアカウント ID 認証情報の 1 回限りの交換を行います。その後、このトークンは決済インテグレータに返され、請求対象のアカウントを識別します。
他の支払い方法でもトークン化が使用されるため、ここでは、キャリア決済に関連するトークン化された FOP の概要について説明します。認証、関連付け、購入、送金の各フローについては、こちらの概要で詳しく説明しています。このページでは、キャリア決済固有のコンテキストについて詳しく説明します。
携帯通信会社は、次のフローを構成する API を実装して、Google Standard Payments にオンボーディングします。
| フロー | 説明 | DCB3 と同等の仕様 |
|---|---|---|
| 認証 | DCB の支払いに使用される、決済インテグレータのシステムのユーザーのアカウントを特定して認証します。 | GoogleUserToken を使用した SMS-MO |
| 関連付け | Google と決済インテグレータが合意した有効期間の長いトークンを交換し、ユーザーの決済インテグレータ アカウントを使用して支払いを行うことができます。 | OperatorUserToken と GetProvisioning()で ユーザーを承認するユーザーコールバックです |
| FundsTransfer | ユーザーの決済インテグレーターの口座から同期的に資金を出金します。責任を決済インテグレータに移転する | バッチ リクエスト ファイルの Auth() 行と CHARGE 行 |
| 払い戻し | 以前の FindsTransfer に関連付けられた資金の一部またはすべてを、ユーザーの決済インテグレーター アカウントに同期的に返します。責任を Google に譲渡する | バッチ リクエスト ファイルの REFUND 行 |
| 送金 | API ベースの決済 | 毎月の請求書の PDF、毎月の請求書の詳細ファイル、日次調整ファイル |
| UpdateAssociatedAccount | ユーザーの決済インテグレーター アカウントの変更（取引上限やプロビジョニング ステータスなど）を Google に通知します。 | GetProvisioning() ポーリング |
| 不正行為 | ユーザーの紛争により取り消された取引を Google に通知します。これは Google のリスクエンジンの改善に使用されますが、金銭的責任には影響しません。 | なし |
DCB3 の仕様との全体的な比較
Google Standard Payments の仕様は、DCB3 Spec で解決される問題と同じ問題を解決します。ただし、ソリューションを改善するさまざまなテクノロジーや API 設計を使用しています。主な違いは次のとおりです。
スタック テクノロジーの比較
API 通信はすべて、PGP で暗号化および署名された JSON による HTTPS POST を使用して行われます。つまり、Google と決済インテグレータはそれぞれ、ローテーションする PGP 鍵を 1 つだけ持つということです。また、これらの技術では SOAP よりもサポートが優れています。通信スタックの詳細についてはこちらをご覧ください。
API の理念の比較
DCB3 は、支払い状態を調整するためにファイルに大きく依存します。Google 標準お支払いにファイルはありません。API 呼び出しは、最終状態が決定されるまで、べき等かつ無期限に再試行されます。
最終状態は、特定のべき等性のキーに対して真に最終状態になります。バグと不確定状態は不承認としてモデル化されず、200 以外の HTTP レスポンスとしてモデル化されます。これにより、バグをより迅速に発見し、バグが不承認としてマスクされることを回避できます。
新機能
Google Standard Payments では、次のような新機能がサポートされています。
- Google の不正行為者のリスクエンジンに情報を伝える Fraud API
- プロビジョニング、取引の上限、アカウント ステータスの変更を Google に知らせるために、Associated Account API を更新します。
- USSD の PIN など、購入時の認証チャレンジのサポートを強化
- 日別の送金サイクル
DCB3 から Google 標準支払いへの用語のマップ
このドキュメントと仕様自体には、新しく見えても、実際には既存のコンセプトとは異なる用語が含まれています。
- 携帯通信会社 -> 決済インテグレータ
警告: DCB インテグレータの概念との混同を避けるため、このドキュメントでは、単に「インテグレータ」ではなく「決済インテグレータ」と「DCB インテグレータ」を使用します。ただし、Google Standard Payments の一般的なドキュメントでは、「Payment Integrator」の短縮形として「インテグレータ」が広く使用されています。
- 請求契約 ID -> 決済インテグレーター アカウント ID
- OperatorUserToken（OUT）-> GooglePaymentToken（GPT）
- interaction_id -> requestId
- 収益分配 -> 手数料
認証フロー
トークン化された FOP の認証フローの一般的な概要については、こちらのページをご覧ください。
キャリア決済の詳細
キャリア決済の場合の認証フローの目的は、ユーザーが携帯通信会社のアカウントに関連付けられた SIM カードを操作できることを証明することです。キャリア決済ユーザーは、次の 3 つのメカニズムのいずれかを使用して認証できます。
- SMS-MO 認証（トークン化された FOP の概要での定義）
- リダイレクト認証（トークン化された FOP の概要での定義）
- SMS-MT OTP（トークン化された FOP での定義）
決済インテグレータは Google と協力して、自社のプロダクトに最適な認証メカニズムを選択できます。
DCB3 との比較
認証フローは、Google への approveuser コールバックを DCB3 仕様に含まれないものに置き換えます。
DCB3 では、認証と関連付けが 1 つのフローに統合されていました。Google Standard Payments では、認証はアカウントの関連付けとは別の問題です。
関連付けフロー
トークン化された FOP の関連付けフローの概要については、こちらのページをご覧ください。
キャリア決済に使用される関連付けフローと一般的なトークン化された FOP のフローの主な違いは、associateAccount メソッドで提供される認証の証明が、決済インテグレータが追加のユーザー確認をリクエストしたかどうかによって異なる点です。
決済インテグレータが追加のユーザー チャレンジを希望していると回答した場合、認証の証明は、Google が追加のチャレンジに使用した特定の認証メカニズムによって生成される本人確認になります。たとえば、SMS-MT OTP メカニズムによって生成される認証の証明は、sendOtp メソッドの requestId と OTP 自体です。
楽器の属性
トークン化された FOP の概要の概要の支払い方法属性セクションでは、accountAlias、accountNickname、fullAccountNickname のコンセプトについて説明しています。
キャリア決済の詳細
accountAliasはユーザーの電話番号にする必要があります。ユーザーがアカウントに関して Google サポートに問い合わせたときに、支払い方法を特定するために使用します。accountNicknameとfullAccountNicknameは、UI で計測を識別するために使用される表示名です。
DCB3 の仕様との比較
関連付けフローは、DCB3 仕様の次のコンポーネントに代わるものです。
- GetProvisioning SOAP の呼び出し
- GetSubscriberAddress SOAP 呼び出し
- キャリアによって生成された OUT
大きな違いは、Google Payment Token（GPT）が関連付けフローの際に、携帯通信会社ではなく Google によって生成される点です。
また、アウトのスコープが特定の BillingAgreementId である DCB3 とは異なり、GPT のスコープが特定の PaymentIntegratorAccountID に設定されない点にも注意が必要です。
更新トークンのフロー
トークン化された FOP の更新トークンのフローの一般的な概要については、こちらのページをご覧ください。
キャリア決済の詳細
キャリア決済の場合、Google 支払いトークンが期限切れになると定期購入の注文はキャンセルされるため、期限切れにならないことを強くおすすめします。多くの場合、有効期限のあるトークンを使用して更新トークンのフローでトークンを修正する代わりに、以下に説明するアカウント更新フローを使用してユースケースを実現できます。
アカウント更新フロー
アカウント更新フローでは、決済インテグレータは、ユーザーのインテグレータ アカウントの更新について Google に通知できます。これらのフィールドは、元々関連付けフローで Google に提供されます。決済インテグレータが更新するアカウント データの例を次に示します。
- ユーザーの月ごと、日ごと、商品アイテムごとの取引限度額
- ユーザーのインテグレータ アカウントのプロビジョニング ステータス
- ユーザーのインテグレータ アカウントの種類（前払い、後払い、エンタープライズなど）
- ユーザーの「accountAlias」、「accountNickname」、「fullAccountNickname」
- ユーザーが事前共有静的 PIN を設定、削除、変更したか
- ユーザーがアカウントを閉鎖したのか、電話番号を変更したのかなど、Google のシステムでユーザーの支払い方法が無効になります。
- トークン削除フロー
DCB3 の仕様との比較
アカウント更新フローは、DCB3 仕様の次の構成要素に代わるものです。
- GetProvisioning SOAP 呼び出しのポーリング
- 定期的なトークンの無効化
購入フロー
トークン化された FOP の購入フローの一般的な概要については、こちらのページをご覧ください。
キャリア決済の詳細
一部の携帯通信会社では、USSD などの技術を使用して、購入のたびにユーザーから PIN を収集します。このような携帯通信会社では、Capture() を呼び出す代わりに asyncCapture() を呼び出します。30 秒間、携帯通信会社がユーザーに PIN の入力を求め、キャプチャを完了します。支払いの最終状態が決定されると、携帯通信会社は captureResultNotification() を呼び出してその結果を Google に通知します。
DCB3 の仕様との比較
ここには大きな変更点があります。
- 単一の同期メソッド呼び出し -- auth() + バッチファイルではなく capture() を使用する
- バッチファイルはまったくない
- cancel() メソッドなし（認証 + キャンセルの代わりにキャプチャ + 払い戻し）
- レスポンスに user_message フィールドがない -- 不承認コードは、ユーザーのアカウントの言語にローカライズされた Google 所有のメッセージにマッピングされます。
- 主な用語の変更:
- CorrelationId -> requestId
- BillingAgreementId -> paymentIntegratorAccountId
- OperatorUserToken -> googlePaymentToken
チャレンジ購入フロー
各購入前にユーザーに認証による本人確認を行う購入フローをサポートするため、開発が進行中です。関連付けフローの前に使用できるほとんどの認証方法は、チャレンジ購入フローの前に使用して追加のユーザー認証を行うこともできます。
払い戻しフロー
トークン化された FOP の払い戻しフローの一般的な概要については、こちらのページをご覧ください。
トークン化された FOP は、単一のメッセージの払い戻しフローをサポートします。払い戻しメソッドでは、購入全体の払い戻しまたは購入の一部の払い戻しがサポートされます。1 回の購入で一部払い戻しを複数回行うことができる。
キャリア決済の詳細
払い戻しフローにおいて、キャリア決済の方法に特別なことは何もありません。
DCB3 の仕様との比較
払い戻しはファイルではなく同期 API 呼び出しによってトリガーされます。また、1 件の全額払い戻しのみに対応するのではなく、元のお支払い 1 回に対して一部払い戻しを複数作成することもできます。
送金フロー
トークン化された FOP の送金フローの概要については、こちらのページをご覧ください。
送金フローは、Google と決済インテグレータが決済を行うフローです。Google は会計システムであり、送金の会計を行います。Google は定期的に、決済インテグレータに送金明細書を送付します。この明細書には、決済インテグレータが Google に支払うべき金額の概要と、Google へのお支払い方法が記載されています。決済インテグレータが調整するために、決済インテグレータは、送金明細書を構成する取引レベルの詳細情報を Google に照会できます。
キャリア決済の詳細
キャリア決済の remittanceStatementDetails には、送金フローの API 定義にまだ記載されていない追加のフィールドが含まれています。たとえば
- revshareCategory
- itemPrice
- tax
- timestamp
Google と 50 対 50 の収益分配率の分割契約を結んでいる携帯通信会社の場合、remittanceStatementDetails に記載されている料金は、イベント単位ではなく revshareCategory 単位で集計されます。
DCB3 の仕様との比較
送金フローは、DCB3 仕様の次の概念に代わるものです。
- 月額料金レポート/支払いレポートの PDF
- 毎月の請求書の詳細が記載された CSV ファイル
- 日次調整 CSV ファイル
主な違いは、ファイルの削除と日次送金のサポートです。送金額はファイルではなく同期 API を介して提供され、別の API は送金明細書の詳細のクエリをサポートします。
不正行為の報告フロー
不正行為の報告フローでは、決済インテグレータは fraudNotification メソッドを呼び出して、不正な取引の可能性があることを Google に通知できます。このフローは Google の内部リスクエンジンを更新するために使用されます。金銭の移動は開始されません。
キャリア決済の詳細
支払い取り消し通知フローにおいて、キャリア決済のお支払い方法については特別な点はありません。