サーバー上で確認できないクレジットを、アプリは確定しません

クレジットを購入したあとに普段目にする確認表示は、レシートではありません。比較の結果です。アプリは購入の前にサーバーが保持しているウォレットを読み取り、購入のあとにもう一度読み取ります。祝いの表示が出るのはその2回の読み取りが食い違ったときだけで、そこに印字される残高も、クライアントが割り出した数字ではなくサーバーから返ってきた数字です(apps/jewelry-mobile/src/app/store/index.tsx)。

この設計には直接の帰結があります。変化を証明できないとき、アプリは数字を出しません。代わりに固定の文面を表示します。支払いは受け取られたこと、クレジットはサーバー側で検証中であること、しばらくしてからもう一度確認してほしいことを伝える文面です(apps/jewelry-mobile/src/i18n/catalogs/en-US.ts:195)。

つまりこの通知は、支払いについての表明ではなく、アプリ自身の証拠についての表明です。アプリが確認を続ける範囲の中では比較が肯定的な結果にならなかった、と言っているにすぎません。サーバー上でクレジットが作成されなかった、とは言っていません。

サーバー側の仕組みはソースツリーから読み取ったものであり、ここに書くのは、アプリの沈黙が破棄された支払いと取り違えられないようにするためだけです。どれも、操作したり、依頼したり、待ったりする対象ではありません。

クレジットに変換できなかったストアからの通知は破棄されません。イベントは失敗として記録され、理由の短縮版が保存され、ロックが解放され、あとの再試行が予約されます。その理由の欄に書き込まれるのは制御された短い文字列だけなので、保存される記録が持つ診断情報は限られています(apps/api/src/webhooks/revenuecat.service.ts)。

失敗したイベントは、自前の内部ジョブによって定期的に再処理されます。そのため、支払われたのにクレジットにならなかったイベントが、一度の配信の機会だけに縛られることはありません。このジョブはテスト環境では起動しません(apps/api/src/webhooks/revenuecat.service.ts)。

再試行は無制限ではありません。上限はコードに組み込まれた固定値で、設定で変えることはできず、その値はここにも、このサイトのどこにも意図的に書きません。上限を使い切ると、イベントは手動での確認に引き上げられ、アラームログが書かれます。自動で処理できないイベントにも同じように印が付けられ、人の手でクレジットが付与されるか、返金が開始されます。コードには自動返金も自動補償もありません。

外から見ると支払いが失われたように見えるため、もう一つの場合にも名前を付けておきます。そのアプリにウォレットがまだ存在しない場合、クレジットは付与されず、イベントはエラーとして数えられ、あとの再試行のために残されます。この探索はユーザーとアプリの組み合わせを鍵にしており、それが、あるアプリでの購入を別のアプリのウォレットに書き込ませない関門でもあります。