Apple はいったん認めた払い戻しを取り消すことができ、サーバーが無視した取り消された払い戻しは、支払った顧客を締め出す

払い戻しは必ずしも最後の言葉ではありません。App Store は、顧客が異議を申し立てた後、いったん認めた払い戻しを取り消すことができ、その取り消された払い戻しがサーバーに届くとき、それは一つの指示を伴います。アクセスを返せ、というものです。ほとんどのチームは単純な REFUND 通知を配線し、顧客を締め出し、そこで止まります。彼らはもう半分を決して作りません。ですから取り消しが届いても、何も実行されず、再び支払っている顧客は購入したものから締め出されたまま座り込みます。App Store と Google Play における払い戻し通知の全体像と、無視したときにそれぞれが何を招くのかを解説します。

App Store は払い戻し通知を一つではなく三つ送信する

ほとんどの払い戻し処理は単一のイベント向けに作られています。お金が戻った、顧客を締め出せ、というものです。App Store Server Notifications V2 のフィードは実際には三つの別々の払い戻し結果を運んでおり、それぞれが異なることを求めます。そのうち二つは顧客がアクセスできるものを変えます。もう一つは最初のものを取り消します。以下が、Apple 自身の言葉による全体像です。

REFUND、どのチームも処理するもの

App Store が払い戻しを処理すると、設定した URL に REFUND 通知を送信します。Apple の定義は明快です。それは「App Store が消費型 In-App Purchase、非消費型 In-App Purchase、自動更新サブスクリプション、または非更新サブスクリプションの取引を正常に払い戻したことを示す」ものです。あなたは払い戻された取引を保存し、それが購入したものを取り消し、Apple はアプリ内の文脈に応じたメッセージで何が変わったのかを顧客に伝えるよう求めます。これは誰もが最初に配線する通知であり、しばしば唯一のものです。

REFUND_DECLINED、あなたに何も求めないもの

REFUND_DECLINED はその名の通りの意味です。「App Store が払い戻し要求を却下した」というものです。顧客が要求し、Apple がノーと言い、取引はそのまま残ります。顧客のアクセスについては何も変わらないため、あなたの権限ロジックはここでは何もしません。この通知の価値は記録にあります。それは、あなたが CONSUMPTION_REQUEST で応答したかもしれない払い戻し要求のループを閉じ、顧客が支払ったものを依然として持っていることを確認します。アクションではなく記録として扱ってください。

REFUND_REVERSED、チームの不意を突くもの

これは、ほとんどの払い戻しパイプラインが決して処理しない通知です。Apple の定義は明確です。REFUND_REVERSED は「App Store が、顧客が提起した異議のために以前に認めた払い戻しを取り消したことを示す。あなたのアプリが関連する払い戻しの結果としてコンテンツやサービスを取り消していた場合、それらを復元する必要がある」ものです。これを二度読んでください。Apple が顧客に払い戻しを与え、あなたがアクセスを取り消し、その後 Apple がその払い戻しは成立すべきではないと判断して取り下げました。請求は再び有効です。顧客は支払っており、あなたのサーバーが取り消す方法しか知らなければ、顧客は依然として締め出されたままです。取り消された払い戻しは、アクセスを追加で戻す唯一の払い戻しイベントであり、ほとんど誰も対応を作らないものです。

取り消された払い戻しが実際にあなたに招く代償

見逃した取り消しは丸め誤差ではありません。お金を両方向にたどってください。どちらの半分を間違えても代償があるからです。

取り消しを見逃すと、支払っている顧客を締め出したままにします。Apple が請求を復元したため、顧客は再び自腹を切っており、あなたのアプリは購入したものを拒否しています。即座の代償はサポートの時間と、今や自分で発行することになるかもしれない善意の払い戻しであり、今回はそれを和らげるストアの手数料の払い戻しはありません。より遅い代償はレビューと解約であり、Google Play では、まさにその締め出しへの不満がチャージバックに変わるものです。

最初の払い戻しを見逃すと、何も支払っていない顧客に提供し続けることになります。鏡像の誤りは、そもそも一切取り消さないことです。払い戻されたのに依然として画像を生成し、あなたの API を呼び出し、あなたのストレージを満たす顧客は、取り消された売上に対して実際のコストを積み上げます。計算資源、サードパーティの呼び出し、ストレージは、あなたがすでに費やしたお金であり、そのどれも払い戻しとともに戻ってきません。

• サポートコスト。あなた自身のコードが削除し、決して復元しなかったアクセスについてのチケットに対応する人間。
• 善意の払い戻し。誤って締め出した顧客にお金を再発行すること。手動の対応にはストアの手数料の払い戻しはありません。
• 無駄な支出。決して締め出さなかった払い戻し済みのアカウントによって消費される計算資源、API 呼び出し、ストレージ。
• チャージバックのリスク。Google Play では、二重に請求されたと感じる顧客が異議を申し立てることができ、敗れた異議は今やあなたに降りかかります。

取り消された払い戻しと単純な払い戻しは、反対方向を指す同じ webhook フィードです。一方を処理してもう一方を飛ばすと、両端で代償を払います。

なぜ Apple は払い戻しを取り消すのか、そして revocationReason の読み方

取り消しはランダムではありません。Apple はそれを「顧客が提起した異議」に結びつけます。これは顧客が事後に払い戻しの決定に異を唱えることです。払い戻しが最初に認められたとき、取引には revocationDate と revocationReason が付いており、下流の何かがそれに基づいて動作する前に、その理由を読む価値があります。

• revocationReason 1。App Store は「あなたのアプリ内の実際のまたは知覚された問題のために」払い戻しました。それはこの顧客だけでなく、あなたの製品についての信号です。
• revocationReason 0。App Store は「その他の理由、たとえば誤購入のために」払い戻しました。アプリ品質に関する信号は付いていません。

その取引に REFUND_REVERSED が届くと、取り消しが取り消されています。あなたの復元ロジックは、元の取引 id を検索し、それを取り消したことを確認し、権限を元の通りにそっくり戻すべきです。

Google Play は取り消しを送信しないため、代わりに照合する

Google Play のモデルは異なり、両方のストアを一つの webhook ハンドラーで処理している場合、その違いは重要です。REFUND_REVERSED に相当する Google のものはありません。Google のリアルタイム開発者通知は払い戻しイベントを二つのメッセージに分割し、取り消しはプッシュではなく照合によって処理されます。

無効化された購入の通知

Google Play の購入が無効化されると、サーバーは VoidedPurchaseNotification を受け取ります。それは purchaseToken と orderId、サブスクリプションまたは一回限りの productType、そして完全な無効化か、複数数量の購入における数量ベースの部分払い戻しのいずれかである refundType を示します。Google は、そのデータが正しい購入を見つけて権限を調整するのに十分だと言います。それ以上のことについては、あなたが照会するタイムスタンプ範囲内の無効化された注文を一覧表示するプルモデルである Voided Purchases API を案内します。

チャージバックのレビューと、その 24 時間の時計

チャージバックは別のメッセージ、PendingRefundReviewNotification を通じて届きます。顧客が銀行に対して請求に異議を申し立てると、Google Play はこの通知を送信し、時計を始動させます。あなたには、Google があなたに代わって不正なチャージバックに異議を唱えられるよう、払い戻しの希望とあらゆる利用の証拠を添えて orders.reviewrefund を呼び出す 24 時間があります。Google はあなたの最初の呼び出しを記録し、残りを無視します。これは Apple の CONSUMPTION_REQUEST に対する Google の対応物であり、あなたの側の異議が意味を持つ唯一の窓です。

取り消しのプッシュがないため、Google が争って勝ったチャージバックは、きちんとした復元イベントとしては届きません。あなたはそれを Voided Purchases API と自分自身の記録に照らして照合します。教訓は App Store と同じです。無効化された注文は必ずしも永久ではなく、あなたの権限の状態は前に進むだけでなく、後ろに戻ることもできなければなりません。

誰も締め出さずにすべての払い戻し通知を処理する方法

ストアごとに別々のパイプラインは必要ありません。必要なのは、権限を両方向に動かすことができ、すべてのメッセージを重複している可能性があるものとして扱うハンドラーです。

• 取り消しだけでなく、復元を作る。REFUND でアクセスを削除するすべての経路に対して、同じ取引 id に紐付けて REFUND_REVERSED でそれを復元する逆の処理を書く。
• 冪等にする。両方のストアが同じ通知を複数回配信することがあるので、各取り消しと復元を取引または orderId に紐付け、繰り返しを何もしない操作にする。
• 行動する前に理由を読む。revocationReason を使って、アプリ品質の払い戻しを誤操作のものと区別し、アプリ品質のものを製品品質の責任者に振り分ける。
• 証拠の窓に間に合うように応答する。CONSUMPTION_REQUEST から 12 時間以内に Apple の消費データを送信し、PendingRefundReviewNotification から 24 時間以内に orders.reviewrefund を呼び出す。
• すべてのイベントを保存する。REFUND_DECLINED と生の通知を保持し、後で届く取り消しを、それが取り消す払い戻しに突き合わせられるようにする。

これらのどれも、払い戻しが起きるかどうかを変えるものではありません。変えるのは、取り消された払い戻しの向こう側にいる顧客が、あなたのサーバーが誤ったことに気づくかどうかです。