アプリはアプリ内で返金リクエストシートを表示できます。顧客が送信をタップした後にAppleが何をするかを解説します

Appleは、顧客がアプリを一度も離れることなく返金を申請できるようにしています。StoreKitの呼び出し一つ、beginRefundRequestで、あなたのインターフェースの中にApple自身の返金シートが表示され、顧客が理由を選ぶと、リクエストが審査のためAppleへ送られます。フォームを作ることもなく、お金に触れることもなく、結果を決めることもありません。得られるのは、不満を抱えた顧客がすでにいる場所に返金経路を置く手段であり、彼らを銀行に流出させずに済みます。これがアプリ内返金リクエストであり、このボタンを出荷するかどうかを決める前に理解しておく価値があります。

ここからが売上に関わる部分です。このボタンはそれ自体では何も返金しません。リクエストを開くだけで、Appleは承認または却下に最大48時間かけ、消耗型の購入については、まずサーバーへCONSUMPTION_REQUESTを送ります。ですからこのシートは無償の譲渡ではありません。あなたがすでに影響を及ぼせる返金審査へ導く漏斗であり、争いがあなたに争えないチャージバックへ変わる前に、それをカードネットワークから引き戻すことができます。

アプリ内返金リクエストシートとは実際に何か

beginRefundRequestは、window scene内で特定のトランザクションに対して返金リクエストシートを表示するStoreKit 2のメソッドです。シグネチャは短く、func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatusです。呼び出すと、システムは顧客の購入内容と、選ばせるための理由コードの一覧を載せたシートを表示します。そのUIを構築し制御するのはAppleです。あなたが渡すのはsceneとトランザクションだけで、それ以外はありません。

配置場所についてのAppleのガイダンスは明確です。この関数はアカウント設定やヘルプメニューから呼び出してください。そうすれば返金を望む顧客が、サポートを探すのと同じ場所でそれを見つけられます。iOS 15とiPadOS 15、Mac Catalyst 15、visionOS 1で出荷されたので、それらのバージョンを対象とするアプリなら今日から表示できます。

シートを開く二つの方法

入口は二つあります。すでに手元にある特定のトランザクションに対してbeginRefundRequest(in:)を呼び出せば、シートをその一つの購入に限定できます。ある製品の購入を顧客に返金してもらいたいときは、製品識別子でシートを開くこともできます。どちらの方法でも、シート、理由の一覧、そして判断はAppleに属します。あなたの仕事はそれを表示し、結果を読むところで終わります。

呼び出しが何を返すか、そして何が起こり得るか

このメソッドはasync throwsなので、ステータスを返すか、エラーをスローするかのいずれかです。どちらも短い一覧で、どちらも扱う価値があります。そうすればシートが閉じた後にUIが本当のことを言えます。

顧客が送信をタップした後、サーバー上で何が起こるか

シートが閉じることはプロセスの始まりであって終わりではありません。Appleはリクエストを審査し、承認または却下に最大48時間かけます。消耗型のアプリ内課金については、判断する前に、App Storeが利用データを求めるCONSUMPTION_REQUEST通知をサーバーへ送ります。顧客がそのデータの共有に同意していれば、Send Consumption Informationエンドポイントを通じて応答します。同意していなければ、Apple自身の指示は、その通知にはいっさい応答しないことです。

Appleが裁定を下すと、結果はApp Store Server Notificationとしてサーバーに届きます。これはすでに受信しているのと同じフィードで、アプリ内リクエストは、顧客がAppleのreportaproblemページで開始する返金とまったく同じようにそこへ流れ込みます。リクエストがアプリの中で始まったからといって、処理について変わることは何もありません。

このボタンにかかるコストと、節約できるもの

あなたが争える返金は、争えないチャージバックに勝る

アプリの中で返金経路を見つけられない顧客は、あきらめません。銀行へ行きます。カードのチャージバックは銀行との間で最終的であり、争議手数料がかかり、判断をあなたとAppleの双方の手から奪います。アプリ内返金リクエストは、その同じ顧客をAppleのシステムの中にとどめます。そこでは消耗型の購入が、応答できるCONSUMPTION_REQUESTと、影響を及ぼせる判断を起動します。争えないチャージバックを、争えるApple審査と引き換えにすること、それがこのボタンの財務的な論点のすべてです。

あなたは返金の摩擦を下げている

正直な反面は、目に見える一タップの返金経路は、奥に埋もれたサポートメールよりも多くの返金リクエストを生むということです。その一部は本来決して起きなかったはずのものです。それは実在するコストであり、だからこそAppleは、入口を購入画面ではなくアカウント設定やヘルプメニューに置くよう指示します。すでに不満な顧客に見つけてほしいのであって、単に好奇心のある顧客に見つけてほしいわけではありません。

最初から最後まで動き続けるコストは、返金済みのアカウントにサービスを提供し続けること

判断がどちらに転んでも、あなたが結果に基づいて動くまで、提供側のメーターは回り続けます。返金済みの権利が生きている一時間ごとに、その裏にある本当のコストを払い続けます。計算資源、モデルのAPI呼び出し、ストレージ、そしてその顧客の利用に紐づくクリエイターやパートナーへの支払いです。アプリ内リクエストはそれを変えません。REFUND通知で速やかに取り消すことが変えます。このボタンの安さは、最終的に生み出される通知をどう処理するか次第です。

アプリ内返金リクエストを出荷すべきか

販売のある場所ではなく、サポートのある場所に置く

Appleの配置ガイダンスに従ってください。アカウント設定とヘルプメニューが正しい置き場所です。ペイウォールの隣の返金リンクは、お金が戻ってくると人々に期待させるよう仕向け、提供する必要のなかった好奇心による返金を招きます。

信頼する前に、サンドボックスで全体のフローをテストする

サンドボックスとXcodeのStoreKitテストで、リクエストを保留中から承認済みまたは却下済みへ動かしながら、経路全体をシミュレートできます。承認はサーバーにREFUND通知を届け、却下はREFUND_DECLINEDを届けるので、実際の顧客が送信をタップする前に、ハンドラーが正しく反応することを証明できます。

すべての結果を扱い、決して過大に主張しない

successでは保留中を表示し、failedでは再試行を提示し、userCancelledでは何も変わっていないと伝え、duplicateRequestは、顧客の以前のリクエストがまだ有効だという静かな注記として扱ってください。害になる唯一の誤りは、手元にあるのが送信済みのリクエストだけなのに、返金が完了したと顧客に伝えることです。

RefundHaltはその後をどう処理するか

アプリ内シートはAppleのものです。その後に来るものはあなたのものであり、そこがRefundHaltの担う部分です。顧客がアプリの中から返金を送信すると、RefundHaltは消耗型の購入についてCONSUMPTION_REQUESTを捕捉し、Appleの判断を助ける利用の証拠とともに12時間の枠の中でそれに応答します。Appleが裁定すると、REFUNDでは取り消し、REFUND_DECLINEDではアクセスをそのまま保持し、それぞれを正確にそのトランザクションに紐づけます。あなたは、審査も証拠も取り消しも手作業の慌てふためきに委ねることなく、より親切なアプリ内返金経路を提供できます。