Rivya のプランとクレジットパックの checkout、Stripe リダイレクト、/payment ブリッジ、webhook、請求更新、購入確認を理解するためのガイド。

Rivya でプランまたはクレジットパックを購入したあとに何が起きるかを理解する必要がある場合は、この支払いと checkout ガイドを使います。

Rivya の支払いでよく誤解されるのは、次の点です。

Stripe で支払いが完了しても、それが最後のステップではありません。プロダクト側も追いつき、その変更を正しく反映する必要があります。

そのため、checkout フローは Stripe で終わらず、ブラウザが戻ってきた瞬間にも終わりません。

支払いフローには実際に 3 つの段階がある

現在の checkout は、3 つの段階に分けると理解しやすくなります。

Rivya が checkout session を作成する
ユーザーが Stripe Checkout を完了する
Rivya がプロダクト状態を再び信頼できる状態に戻すのを待つ

この 3 番目の段階こそが、/payment が存在する理由です。

Checkout を開始できる場所

現在、checkout はユーザーの意図にすでに合っている場所から始まります。

Pricing
/settings/billing
/settings/credits

主な購入形態は次の 2 つです。

サブスクリプションプランの checkout
1 回限りのクレジットパック checkout

これらは異なる商業上の判断ですが、それでも同じ確認経路に合流します。

プラン Checkout とクレジットパック Checkout は似ているが同じではない

プラン checkout はサブスクリプション型です。

クレジットパック checkout は、1 回限りのウォレットチャージ型です。

支払い後、Rivya は何を更新すべきかを知る必要があるため、この違いは重要です。

サブスクリプション状態
またはウォレット状態

そのため、同じ Stripe 成功の瞬間でも、その後に戻されるプロダクトサーフェスが異なることがあります。

`/payment` が存在する理由

/payment は、通常の意味での領収書ページではありません。

これは処理用のブリッジです。

役割は次のとおりです。

Stripe の session_id を読む
プロダクト側の支払い記録が確定したか確認する
必要なら短時間 polling を続ける
そのあとで初めて、アプリ内の正しい場所へ戻す

つまり、通常のコンテンツページというより、状態同期ページに近いものです。

プロダクト視点で支払いが「本当に完了」するタイミング

ユーザー視点では、Stripe が成功したと言えば支払いは完了したように感じます。

プロダクト視点では、アカウント状態が Rivya 上で目に見えて更新されたときに、支払いが本当に完了します。

通常は次を意味します。

支払い記録が paid または completed としてマークされている
サブスクリプションまたはウォレットへの反映が見える
古い状態を見ずに billing または credits へ安全に戻れる

これが、ユーザーをすぐアプリへ戻すのではなく、プロダクトが /payment で待つ本当の理由です。

`/payment` が polling しても Webhooks が重要な理由

/payment は Stripe webhooks を置き換えるものではありません。

耐久的なバックエンド状態を更新するのは、引き続き webhooks です。

/payment ページは、リダイレクト前にその状態が信頼できる程度に反映されるまで体験側で待つために存在します。

これは次の違いです。

「Stripe が何かを処理した」
「Rivya がその変更を明確に反映した」

支払い後にどこへ戻るか

戻り先は、何が変わったかに意図的に結びつけられています。

購入がサブスクリプション関連なら、通常は billing に戻されます。

購入がクレジットパックなら、通常は credits に戻されます。

これは見た目だけのルーティングではありません。支払い直後にユーザーが通常持つ質問に合っています。

プランは更新されたか。
それともウォレットが更新されたか。

Timeout または Failure が実際に意味すること

/payment が timeout または failure になっても、それは支払い自体が消えたことを自動的に意味するわけではありません。

多くの場合、次のいずれかを意味します。

プロダクト側の支払い記録がまだ確定していない
リダイレクトが、まだ追いついていない状態を待っている
早すぎる段階でユーザーを戻すと、アカウントページが古い状態に見える

だからこそ、タイムアウト状態は偽の成功状態よりも優れています。まだ未完了なのがプロダクト確認の部分であることをユーザーに伝えられるためです。

支払いが本当に反映されたか確認する最善の方法

checkout 後の最もきれいな確認経路は次のとおりです。

/payment のフローを完了させる
購入がプランなら /settings/billing を確認する
購入がパックなら /settings/credits を確認する
アカウントがまだ同期していないように見える場合は、Notifications Center を確認する

これは、ランダムなページを更新して推測するより、通常は確実です。

支払いはアカウントの記憶にもなる

支払いは checkout アクションだけではありません。次のような耐久的なイベントを通じて、アカウント履歴の一部にもなります。

サブスクリプション開始
サブスクリプション更新
支払い失敗
クレジットパッケージ追加

そのため、ここでも notifications が重要です。Stripe タブを閉じても、アカウント側の流れが終わったわけではありません。

よりよいメンタルモデル

Rivya checkout を最もシンプルに考えるなら、次のように分けます。

Stripe はお金の移動を扱う
/payment はプロダクト側への再入場を扱う

この 2 つの役割を分けておくと、フロー全体を理解しやすくなります。

次に読む

Checkout 状態チェックリスト

購入が未完了またはわかりにくく見える場合は、次を確認します。

Checkout がどこから始まったかを確認する: public pricing、billing settings、または credits settings。
Stripe が支払いを完了し、ユーザーを /payment に戻したか確認する。
別の有料タスクを始める前に、Rivya が subscription、pack、invoice、wallet state を更新するのを待つ。
サブスクリプションには billing ページ、パックまたは wallet history には credits ページを使う。
ブラウザのリダイレクトだけを、webhook とアカウント状態がすでに確定した証拠として扱わない。

支払いを再試行する前に再確認する

古いプラン、見つからないクレジット、重複した Checkout ウィンドウ、支払い失敗、または成功した Stripe receipt がまだ Rivya に反映されていない状態が見える場合は、支払いを再試行する前に再確認します。

Rivya 支払いと Checkout ガイド