Begrijp Rivya plan- en credit-pack-checkout, Stripe redirects, de /payment bridge, webhooks, billing updates en purchase checks.

Gebruik deze payment checkout-gids wanneer je wilt begrijpen wat er gebeurt nadat je in Rivya een plan of credit pack koopt.

Wat mensen meestal verkeerd begrijpen over betaling in Rivya is dit:

dat Stripe de betaling afrondt, is niet de laatste stap. Het product moet nog bijwerken en die wijziging correct tonen.

Daarom eindigt de checkoutflow niet op Stripe, en ook niet op het moment dat de browser terugkomt.

De betalingsflow heeft drie echte fases

Op dit moment is checkout makkelijker te begrijpen als je die in drie fases splitst:

Rivya maakt de checkout session aan
de gebruiker voltooit Stripe Checkout
Rivya wacht tot de productstatus weer betrouwbaar is

Die derde fase is precies waarom /payment bestaat.

Waar checkout kan starten

Checkout start momenteel vanaf plekken die al passen bij de intentie van de gebruiker:

Pricing
/settings/billing
/settings/credits

De twee belangrijkste aankoopvormen zijn:

checkout voor abonnement
eenmalige credit-pack checkout

Dat zijn verschillende commerciele beslissingen, maar ze komen samen in hetzelfde bevestigingspad.

Plan Checkout en Credit-Pack Checkout lijken op elkaar, maar zijn niet hetzelfde

Plan checkout heeft de vorm van een subscription.

Credit-pack checkout is een eenmalige wallet top-up.

Dat verschil is belangrijk, omdat Rivya na betaling moet weten of het moet verversen:

subscription state
of wallet state

Daarom kan hetzelfde Stripe-successmoment je daarna toch terugsturen naar verschillende productvlakken.

Waarom `/payment` bestaat

/payment is geen receipt page in de gebruikelijke zin.

Het is een processing bridge.

De taak ervan is:

de Stripe session_id lezen
controleren of de product-side payment record is gesetteld
indien nodig korte tijd blijven pollen
je pas daarna terugsturen naar het juiste deel van de app

Dat maakt het meer een state-synchronization page dan een content page.

Wanneer is een betaling "echt klaar" vanuit productperspectief?

Vanuit de gebruiker voelt betaling klaar zodra Stripe zegt dat het is gelukt.

Vanuit het product is betaling pas echt klaar wanneer de accountstatus zichtbaar is bijgewerkt in Rivya.

Dat betekent meestal:

de payment record is gemarkeerd als paid of completed
subscription- of walleteffecten zijn zichtbaar
je kunt veilig terug naar billing of credits zonder stale state te zien

Dit is de echte reden dat het product op /payment wacht in plaats van de gebruiker meteen terug de app in te sturen.

Waarom webhooks nog steeds belangrijk zijn terwijl `/payment` pollt

/payment vervangt Stripe webhooks niet.

Webhooks blijven de plek waar duurzame backend state wordt bijgewerkt.

De /payment pagina bestaat zodat de ervaring kan wachten totdat die state betrouwbaar genoeg wordt weerspiegeld voordat er wordt geredirect.

Dat is het verschil tussen:

"Stripe heeft iets verwerkt"
en "Rivya laat die wijziging nu duidelijk zien"

Waar je na betaling naartoe gaat

Het return path is bewust gekoppeld aan wat er veranderde.

Als de aankoop subscription-related was, word je meestal teruggestuurd richting billing.

Als de aankoop een credit pack was, word je meestal teruggestuurd richting credits.

Dat is geen cosmetische routing. Het past bij de vraag die gebruikers meestal direct na betalen hebben:

is mijn plan bijgewerkt?
of is mijn wallet bijgewerkt?

Wat een timeout of failure echt betekent

Als /payment een timeout of failure toont, betekent dat niet automatisch dat de betaling zelf verdwenen is.

Vaker betekent het een van deze dingen:

de product-side payment record is nog niet gesetteld
de redirect wacht op state die nog aan het bijwerken is
de accountpagina zou nog stale lijken als de gebruiker te vroeg werd doorgestuurd

Daarom is een timeout state beter dan een neppe success state. Die vertelt de gebruiker dat productbevestiging het deel is dat nog niet compleet is.

De beste manier om te controleren of betaling echt geland is

Na checkout is dit het schoonste verificatiepad:

laat /payment de eigen flow afmaken
check /settings/billing als de aankoop een plan was
check /settings/credits als de aankoop een pack was
check Rivya gids voor het notificatiecentrum als het account nog niet synchroon lijkt

Dit is meestal beter dan willekeurige pagina's refreshen en gokken.

Betaling wordt ook accountgeheugen

Betaling is niet alleen een checkoutactie. Het wordt ook onderdeel van account history via duurzame events zoals:

subscription started
subscription renewed
payment failed
credit package added

Daarom doen notificaties hier ook mee. Het Stripe-tabblad sluiten is niet het einde van het accountverhaal.

Een beter mentaal model

De eenvoudigste manier om over Rivya checkout te denken is:

Stripe verwerkt de geldbeweging
/payment verzorgt de product-side re-entry

Als je die twee rollen gescheiden houdt, wordt de hele flow makkelijker te begrijpen.

Checklist voor checkoutstatus

Wanneer een aankoop onaf of verwarrend lijkt, controleer dan:

Bevestig waar Checkout startte: public pricing, billing settings of credits settings.
Controleer of Stripe de betaling voltooide en de gebruiker terugbracht naar /payment.
Wacht tot Rivya subscription, pack, invoice en wallet state heeft ververst voordat je een nieuwe betaalde taak start.
Gebruik billingpagina's voor subscriptions en creditspagina's voor packs of wallet history.
Behandel een browserredirect niet als bewijs dat webhook en account state al gesetteld zijn.

Controleer opnieuw voordat je betaling opnieuw probeert

Controleer opnieuw voordat je opnieuw probeert te betalen als de gebruiker een stale plan, ontbrekende credits, dubbele Checkout-vensters, failed payment of een succesvolle Stripe receipt ziet die nog niet in Rivya wordt weerspiegeld.

Rivya gids voor payment checkout