【Google】アプリ内課金の注文情報(orders)を取得する
Google Play のアプリ内課金には、購入によって発生した「注文(Order)」の情報を扱う API が用意されています。
定期購入や 1 回限りの購入の状態を見る API とは別に、注文という単位で取引の情報を取得できるのが特徴です。
このページでは、注文情報(orders)で何が取得できるのか、その全体像をまとめていきます。
アプリ内課金全体の中での位置づけは、以下のまとめページもあわせてご覧ください。
注文情報(orders)とは
注文情報(orders)は、Google Play 上で行われた 1 回の取引をまとめて表す情報です。
定期購入の状態は purchases.subscriptionsv2.get、1 回限りの購入の状態は purchases.products.get で確認します。
ですが、これらは「いま購入がどういう状態か」を見るための API です。
一方の注文情報は、金額・税・返金・購入者の所在地といった、取引そのものの情報を扱います。
注文情報(Order)に含まれる主な情報
注文情報を取得すると、Order というリソースが返ります。
Order には、おもに次のような情報が含まれます。
| フィールド | 内容 |
|---|---|
| orderId | 注文ID |
| purchaseToken | 購入時にユーザーの端末へ渡される購入トークン |
| state | 注文の状態 |
| createTime | 注文が作成された日時 |
| lastEventTime | 注文に最後の変更が加わった日時 |
| lineItems | 注文に含まれる個々の商品 |
| total / tax | 支払い総額と税額 |
| developerRevenueInBuyerCurrency | 購入者の通貨建てのデベロッパー収益(部分返金・税・手数料を差し引いた後の金額) |
| buyerAddress | 購入者の所在地情報(国・地域・郵便番号など) |
| orderHistory | 返金やキャンセルなど、注文に加わったイベントの履歴 |
1 つの注文に、金額・税・履歴までまとまっているのがポイントです。
なお total は購入者が支払った総額で、developerRevenueInBuyerCurrency はそこから手数料や税が引かれた手取りの金額です。
売上を集計するときは、この 2 つを取り違えないよう注意してください。
注文の状態(state)
注文の state には、取引の進み具合を表す値が入ります。
| 状態 | 内容 |
|---|---|
| PENDING | 処理待ちの注文 |
| PROCESSED | 正常に処理された注文 |
| CANCELED | 処理される前にキャンセルされた注文 |
| PENDING_REFUND | 返金の処理待ちの注文 |
| PARTIALLY_REFUNDED | 一部返金が適用された注文 |
| REFUNDED | 全額返金が適用された注文 |
注文情報を取得する API
注文情報は、Google Play Developer API の orders リソースから取得します。
取得方法は、用途に応じて 2 つあります。
| メソッド | 内容 |
|---|---|
| orders.get | 注文IDを 1 つ指定して、その注文の詳細を取得する |
| orders.batchget | 注文IDを複数(1〜1000 件)指定して、まとめて取得する |
多数の注文を扱う場合は、1 件ずつ呼び出すよりも orders.batchget でまとめて取得する方が効率的です。
購入トークン系 API との使い分け
注文情報の API は、購入の状態を管理する API とは役割が異なります。
| API | 主な用途 |
|---|---|
| subscriptionsv2.get / products.get | 購入トークンから、購入が「いまどういう状態か」を確認する |
| orders.get / orders.batchget | 注文IDから、金額・税・返金・履歴といった取引情報を取得する |
コンテンツへのアクセス権を付与・剥奪する判断は、これまでどおり購入トークン系の API で行います。
注文情報は、その取引が「いくらで、いつ、どう返金されたか」を後から把握したいときに活躍します。
利用上の注意(クォータ)
注文情報の API 呼び出しは、Google Play Developer API のクォータ(利用上限)を消費します。
Google Play Developer API のクォータはバケットと呼ばれる区分ごとの「1 分あたりの上限」で管理されていて、デフォルトは各バケット 3000 クエリ / 分です。
注文情報の API は Orders バケットに属します。
このバケットは Voided Purchases API と共有されているため、払い戻し済み購入の取得を並行して行っている場合は、合算で上限に当たらないか意識しておくと安心です。
定期購入や 1 回限りの購入の API は別バケットなので、そちらの呼び出し回数とは互いに影響しません。
大量の注文履歴を同期したい場合は、orders.batchget の orderIds に1 回のリクエストあたり最大 1000 件までまとめて指定し、呼び出し回数そのものを減らすのがコツです。
現在の使用状況は Google Cloud Console のクォータ画面で確認でき、足りない場合は増枠のリクエストを出すこともできます。
まとめ
Google Play のアプリ内課金における注文情報(orders)について、全体像を紹介してきました。
注文情報は、購入の状態管理ではなく、金額・税・返金といった取引そのものを扱う API です。
コンテンツの付与や剥奪は購入トークン系の API、売上や返金の把握は注文情報の API、と役割を分けて考えると設計がすっきりします。
参考(出典)
- REST Resource: orders(Google Play Developer API)
- Method: orders.batchget(Google Play Developer API)
- Quotas(Google Play Developer API)
