Understand Rivya plan and credit-pack checkout, Stripe redirects, the /payment bridge, webhooks, billing updates, and purchase checks.

Use this payment checkout guide when you need to understand what happens after buying a plan or credit pack in Rivya.

What people usually misunderstand about payment in Rivya is this:

Stripe completing the payment is not the last step. The product still has to catch up and reflect that change correctly.

That is why the checkout flow does not end on Stripe, and it does not end the moment the browser comes back.

The Payment Flow Has Three Real Stages

Right now, checkout is easier to understand if you break it into three stages:

Rivya creates the checkout session
the user completes Stripe Checkout
Rivya waits for product state to become trustworthy again

That third stage is exactly why /payment exists.

Where Checkout Can Start

Checkout currently starts from places that already match the user’s intent:

Pricing
/settings/billing
/settings/credits

And the two main purchase shapes are:

subscription plan checkout
one-time credit-pack checkout

Those are different commercial decisions, but they still converge into the same confirmation path.

Plan Checkout and Credit-Pack Checkout Are Similar, but Not the Same

Plan checkout is subscription-shaped.

Credit-pack checkout is shaped like a one-time wallet top-up.

That difference matters because after payment Rivya needs to know whether it should refresh:

subscription state
or wallet state

This is why the same Stripe success moment can still send you back to different product surfaces afterward.

Why `/payment` Exists at All

/payment is not a receipt page in the usual sense.

It is a processing bridge.

Its job is to:

read the Stripe session_id
check whether the product-side payment record has settled
keep polling for a short period if needed
only then redirect you back into the right part of the app

That makes it more like a state-synchronization page than a content page.

When Is a Payment “Really Done” From the Product’s Perspective?

From the user’s point of view, payment feels complete once Stripe says it worked.

From the product’s point of view, payment is only really complete once the account state is visibly updated in Rivya.

That usually means:

the payment record is marked as paid or completed
subscription or wallet effects are visible
you can safely return to billing or credits without seeing stale state

This is the real reason the product waits on /payment instead of immediately throwing the user back into the app.

Why Webhooks Still Matter Even Though `/payment` Polls

/payment does not replace Stripe webhooks.

Webhooks are still what update durable backend state.

The /payment page exists so the experience can wait until that state is reflected well enough to trust before redirecting.

That is the difference between:

“Stripe processed something”
and “Rivya now clearly reflects that change”

Where You Go After Payment

The return path is intentionally tied to what changed.

If the purchase was subscription-related, you are generally sent back toward billing.

If the purchase was a credit pack, you are generally sent back toward credits.

That is not cosmetic routing. It matches the question users usually have right after paying:

did my plan update?
or did my wallet update?

What a Timeout or Failure Actually Means

If /payment times out or fails, that does not automatically mean the payment itself disappeared.

More often it means one of these:

the product-side payment record has not settled yet
the redirect is waiting on state that is still catching up
the account page would still look stale if the user were redirected too early

That is why a timeout state is better than a fake success state. It tells the user that product confirmation is the part that is still incomplete.

The Best Way to Check Whether Payment Really Landed

After checkout, the cleanest verification path is:

let /payment finish its flow
check /settings/billing if the purchase was a plan
check /settings/credits if the purchase was a pack
check Notifications Center if the account still looks out of sync

This is usually better than refreshing random pages and guessing.

Payment Also Becomes Account Memory

Payment is not only a checkout action. It also becomes part of account history through durable events such as:

subscription started
subscription renewed
payment failed
credit package added

That is why notifications matter here too. Closing the Stripe tab is not the end of the account story.

A Better Mental Model

The simplest way to think about Rivya checkout is:

Stripe handles the money movement
/payment handles the product-side re-entry

If you keep those two roles separate, the whole flow gets easier to reason about.

Checkout State Checklist

When a purchase looks unfinished or confusing, check:

Confirm where Checkout started: public pricing, billing settings, or credits settings.
Check whether Stripe completed the payment and returned the user to /payment.
Wait for Rivya to refresh subscription, pack, invoice, and wallet state before starting another paid task.
Use billing pages for subscriptions and credits pages for packs or wallet history.
Do not treat a browser redirect as proof that webhook and account state already settled.

Recheck Before Retrying Payment

Recheck before retrying if the user sees a stale plan, missing credits, duplicate Checkout windows, failed payment, or a successful Stripe receipt that is not reflected in Rivya yet.

Rivya Payment Checkout Guide