決済経路とPG・MoR：TossとLemon Squeezy

なぜ必要なのか

顧客が成功画面に戻ったのに利用できない、または再送された通知で商品が二重に付与されることがあります。決済画面だけでは信頼できる販売になりません。注文、検証済みの支払い証拠、約束した権利を結び付け、販売と問い合わせの責任を明確にする必要があります。

どう解決するのか

1. ボタンの前に商品、価格、通貨、顧客識別、利用期間、返金動作を決めます。契約上の販売者と支援担当も確認します。決済処理会社と外部の販売者では責任が異なります。分類名だけで全部の義務が移ると考えず、実際の契約で誰が何をするかを読みます。
2. 信頼できるサーバーで合意した商品価格から注文を作り、事業者の注文やセッション識別子と結びます。ブラウザーからの金額や成功URLの訪問だけでは、想定した注文の支払いを証明できません。どの顧客の何の商品かをサーバー記録で対応させます。
3. 検証した事業者イベントを受け取るか、信頼できる支払い記録を照会します。注文、通貨、金額、完了状態を確認します。遅れて完了する手段もあるため、画面から戻っただけで付与せず保留を表します。認証とイベント検証は事業者の公式手順に従います。
4. 繰り返しても安全な処理にします。どの支払いからどの権利を付与したか保存し、並行処理や再試行でも二重付与しないようにします。支払い後に権利の保存が失敗したら、回復できる状態を残してその処理を再試行します。再課金は付与の復旧の代わりにはなりません。
5. 試験環境で重複通知、遅延成功、失敗、ブラウザーの復帰中断、返金を試します。支払い記録と製品側のアクセス記録の両方を確認します。成功URLの試験だけでは通知の欠落を検証できず、返金だけではアプリのアクセス方針は実装されません。

秘密を公開せずに注文、事業者参照、権利状態をつないで支援用の履歴を残します。支払い済みだが未付与の注文を運用者がどう発見・復旧するか決めます。公開前には対象商品、国、配布経路を現在の契約やプラットフォーム規則で確認します。販売形態で残る義務は違うため、宣伝上の分類名だけで判断しません。

運用者が再試行するときも、同じ注文への付与が増えないことを確認します。復旧のための操作にも同じ一意性の規則が必要です。

注文を保留できる期間と、未解決の決済を調査している間に顧客へ示す案内も決めます。

どんな考え方なのか

決済チャネルは経路、処理会社は決済の役割、MoRは対象取引の販売者です。Stripeの付与手順は支払いの証拠と提供を結びます。Lemon Squeezyは自社の販売者としての役割を説明し、残る仕事は契約ごとに確認が必要です。出典確認日：2026-09-23。実装の検証と実際の販売契約の検討は、それぞれ必要です。