BillingMeld：アプリではなくサーバーによる購入確認の理由

モバイルアプリ内での購入は、利用者にとっては非常にシンプルに見えることが多いです。ボタンを押して支払いを確認し、機能やサブスクリプションにアクセスし、その後は自動的にすべてが進むと期待しています。

しかし、開発者にとって、このボタンの背後にははるかに複雑なプロセスが待ち受けています。購入を確認し、延長や終了、払い戻し、操作履歴の追跡、デバイス変更、AppleとGoogleのストア間の違いを考慮する必要があります。

最大の問題は、サーバーがクライアントアプリケーションを真実の源とみなすときに発生します。

アプリが「購入完了」と通知した場合、サーバーはアクセスを許可し、一度取得した状態に基づいて動き続けます。しかし、購入のライフサイクルはこれで終わりません。

サブスクリプションは延長されることがあり、自動延長を停止することもでき、支払いが返金される場合もあり、操作自体がストアによって取り消されることもあります。

だからこそ、BillingMeldでは購入を確認するのはアプリではなくサーバーです。

クライアントは通知を出すが、決めるのはサーバー

BillingMeldのアーキテクチャでは、モバイルアプリは購入情報の主な情報源ではありません。

クライアントは購入済みの情報を伝えることはできますが、それはあくまで確認のためのものであり、最終的な判断はBillingMeldのサーバー側が行います。サーバーはAppleやGoogleのインフラを通じて情報を検証します。

これが基本的な違いです。

スマートフォンのアプリは古い状態の情報を持っている場合があり、最新の変更をタイムリーに受け取れなかったり、既に解決済みの購入情報を伝えることがあります。

さらに、ユーザーが支払いの権利を自己判断で決めるべきではありません。例えば、BillingMeldは次のことを検証します：

• 実際にその購入が存在するか
• それが正しいアプリと商品に関するものか
• 支払い期間が有効か
• 次回の延長が行われたか
• 自動延長がオフになっているか
• 払い戻しが行われたか
• 操作が取り消されていないか
• 支払い期間が終了していないか

このように、クライアントの通知は購入の証拠ではなく、実際の状態を確認するための手段となります。

サーバーにとっての唯一の真実の源

連携するサービスは、AppleやGoogleと完全な統合を個別に行う必要はありません。

BillingMeldに問い合わせることで、正規化された購入状態を取得できます。

例えば：アクセスが有効か、支払い期間が終了したか、次回の延長が確認されているか、自動延長が停止されているか、購入が取り消されているかなどです。

これにより、責任範囲が明確になり、AppleとGoogleは購入の状態の情報源となります。BillingMeldはこれらのデータを検証して統一モデルに変換し、最新の状態を保持します。最終的にアクセスの可否を決定するのは、このBillingMeldの状態に基づきます。

これにより、複数の製品サーバーは異なる統合を行う必要がなくなり、コードの重複や異なる解釈によるエラーのリスクを減らせます。

クライアントに完全な信頼を置けない理由

クライアントアプリはユーザーの端末上で動作しています。

アプリは閉じたり再起動したり、バックアップから復元したり、後で更新したり、別の端末にインストールして起動したりできます。一時的に古い情報を持っていたり、購入後に発生したイベントを受け取らないこともあります。

これにより、クライアントは最終的な状態の信頼できる情報源ではなくなります。たとえば、ユーザーがサブスクリプションを購入してアクセスを得ても、その後返金や操作の取り消しが行われることがあります。

サーバーが最初の通知だけを知っている場合、購入が有効だとみなしてしまいます。自動延長をオフにした場合も、既に支払われた期間は引き続き有効です。

もしシステムが「サブスクリプションあり／なし」だけの単純な状態にしか対応しないと、アクセスを早期に停止したり、利用権を遅れて解除したりする可能性があります。

BillingMeldは、クライアントによる自己申告ではなく、実際の状態に基づいて判断します。

購入は一つのイベントではない

ビリングアーキテクチャ上の主な誤解の一つは、購入を単一のイベントと考えることです。

実際には、ライフサイクルを持ったものであり、複数の段階があります。

最初は操作が行われ、ストアによって確認されます。サブスクリプションの場合、料金を支払った期間が開始され、その後は延長やキャンセルが行われることがあります。ユーザーは自動延長を停止できますが、既存の有効期間内は利用を続けられます。支払いが次回に行われなかったり、払い戻し、操作の取消、取り消しがあったりします。

これらすべてを「この購入はかつて存在した」とだけでは把握できません。サーバー側は、現在どうなっているのかを把握する必要があります。

取消や返金の情報は見逃さない

特に返金や操作の取り消しに関して、サーバーの役割は重要です。最初の購入は正しかったかもしれませんが、その後状態が変わることがあります。BillingMeldは変更情報を受け取れば、購入状態を更新し、必要に応じてストアの情報も再検証します。その結果、連携サービスは最新の状態で動作します。これにより、アプリは繰り返し過去の購入情報に頼る必要がなくなります。ストアが権利の有効性を否定すれば、BillingMeldはそれを反映させます。

サブスクリプションのキャンセルとアクセス終了は異なる

この点で重要な違いがあります。自動更新を停止した場合でも、すぐにアクセスが切れるわけではありません。既に支払った期間は引き続き有効です。BillingMeldは、この状況を正しく反映させる必要があります。自動更新停止の情報と、既に支払われている期間の終了日を記録します。期間終了後に新たな確認がなければ、アクセスは停止します。単純な真偽値 subscription = true だけでは十分ではなく、契約の時間軸やライフサイクルのイベントも考慮する必要があります。

延長は別の検証ポイント

サブスクリプションは最初の支払いだけで終わりません。サーバーは次回の延長時に次の期間が確認されたかを把握する必要があります。BillingMeldは、その変化を追跡し、状態を更新します。もし延長が確認されれば、権利は継続します。次の支払いがない、もしくはストアが次回の確認を否定している場合は、アクセスを無理に延長しません。これにより、利用者には実際に有効なサブスクリプションと同じ体験が提供されます。開発者にとっては、延長ロジックを各アプリで再実装しなくて済み、効率的です。

普通のシナリオ例

利用者はモバイルアプリでサブスクリプションを申し込みます。クライアントは購入情報を取得し、必要なデータをBillingMeldに送付します。ただし、その通知だけでは購入が最終的に確認されたとはみなされません。BillingMeldはストアを通じて操作を検証します。App StoreやGoogle Playが購入と状態を正しく確認し、ルールに適合すればActiveな状態を記録します。連携サービスはその後、有料の機能やコンテンツを提供します。状態は最初の通知から独立して変化します。サブスクリプションの延長、停止、キャンセル、払い戻しなどが反映されるのです。アプリは、あくまでBillingMeldが確認・保存した状態とやり取りを行うため、最終的な真実はBillingMeldにあります。

端末変更時の動き

サーバーベースのモデルは、特にユーザーが端末を変えたり、アプリを再インストールしたりした場合に有効です。購入権は、アプリが一度でも成功した取引を見たからといって継続されるものではありません。逆に、再インストールしても、サーバに保存された確認済みの権利は失われません。購入状態がサーバ側にあり、確認済みのストア操作と連動しているなら、新しい端末もサーバを通じて最新状態を取得可能です。これは、アクセスロジックをクライアントのみに依存させないもう一つの理由です。

開発者にもたらすメリット

複数のモバイルアプリをリリースしたり、iOSとAndroidを並行して扱ったりするチームにとって、ビリングはすぐにインフラの一部となります。考慮すべきポイントには：

• AppleとGoogleのデータフォーマットの違い
• 最初の購入の認証
• サブスクリプションの延長
• 支払い期間の終了
• 自動延長停止
• 払い戻し
• 操作の取り消し
• アプリの再インストール
• 端末変更
• 購入履歴の復元
• 無断のステータス変更

BillingMeldはこれらを専用の層に切り出し、製品サーバーはそれと統一された契約の下に動作します。各ストアの特有設定やイベントを個別に扱う必要はなくなり、コードの重複と誤差軽減に寄与します。

チェックではなく権利が重要

このアーキテクチャの最大の魅力は、単一の購入確認から、実時点の状態確認へと移行した点です。支払いの歴史だけでは、利用者が今も正当に権利を持っているのかはわかりません。可能な状態は：

• 成功した初回購入
• 終了した期間
• 自動延長停止としながら有効な期間
• 確認済みの延長
• 払い戻し済
• ストアの操作取り消し

これらすべてを踏まえ、最も重要な情報は、「今ユーザーが権利を持っているか」になるわけです。BillingMeldは、これを確認して各サービスに伝えます。

ストアと商品間の信頼の境界

この仕組みは、明確なアーキテクチャ境界も生み出します。一方にはApp StoreとGoogle Playがあり、それぞれ独自のフォーマット・イベント・ルール・ライフサイクルがあります。もう一方には、アプリや内部サービスがあり、多くの場合、シンプルに「今、ユーザーにどんな権利があるか」の情報だけが必要です。その中間にBillingMeldが位置し、ストアからのデータを正規化し、他のインフラへ整形済状態を提供します。これにより、商品側は各プラットフォームの細かな仕様を理解せずとも済むのです。

ユーザーにとってのメリット

理想的には、ユーザーにはこのシステムの存在を意識させずに済むことが望ましいです。購入が承認され、支払い期間が有効ならアクセスは継続します。自動延長の停止や払い戻しも正しく反映されます。端末変更やアプリ再インストールの際も、購入が確実に存在し、正しい権利が反映されるように、通信の複雑さをユーザーに感じさせない仕組みとなっています。最終的には、「クライアントは購入を通知し、ストアは状態の外部ソース、BillingMeldはそれを検証・正規化し、最終的に全サービスがその確認済み情報に基づいて判断する」というシンプルなルールです。これが、BillingMeldが単なる決済システムを超えた、信頼のサーバーレイヤーとなる所以です。詳細はbillingmeld.deをご参照ください。