Original-site checkout
Mount Stripe Embedded Checkout in the product modal; use the top-level Yito page only as explicit recovery.
A billing control layer for a product portfolio
A SaaS billing platform built around one trustworthy order model.
Connect multiple products to a shared billing contract without letting the browser choose prices, users, providers, merchant routes, or return destinations.
Catalog before checkout
A SaaS billing platform keeps price identity on the server.
Every billable feature begins as an app and SKU in the Yito Pay catalog. The canonical record identifies a verified Stripe Price, currency, amount in minor units, payment mode, and entitlement key. A PayPal subscription also needs a matching approved Plan. Product browsers never send a trusted amount or provider object ID.
When a backend requests checkout, its app API key selects the app. The SKU selects the catalog entry. The authenticated product user becomes the external user ID, and the product’s own order becomes the external order ID. The server validates the requested provider against the app’s switches and immutable merchant route. Yito Pay rejects an idempotency key if a retry changes any of those values.
This design gives finance and engineering one answer to a basic question: which approved product, seller route, provider, and price produced this charge? Provider metadata aids investigation, while the Yito Pay order remains the application ledger for fulfillment.
Subscriptions
Track provider subscription and renewal outcomes without reducing the lifecycle to a fragile paid boolean.
Provider-aware management
Open Stripe Billing Portal or PayPal Automatic Payments from the provider stored on the subscription.
Explicit state
Billing is a state machine, not a success flag.
A one-time order can be created, open, processing, paid, fulfilled, failed, expired, partially refunded, refunded, or disputed. A subscription can be trialing, active, past due, paused, canceled, or unpaid. Preserving these states prevents a temporary payment delay from looking like permanent success or failure.
Delayed payment methods may finish browser checkout before money is available. Yito Pay keeps the order processing until an authoritative provider fact arrives. Stripe subscriptions follow paid invoices; PayPal subscriptions require completed renewal sales. Refund and dispute events can revoke or restore an entitlement without editing an append-only payment fact.
| Signal | Order action | Product effect |
|---|---|---|
| verified payment completed | Mark paid | Grant mapped entitlement |
| provider payment pending | Keep processing | Wait for settlement |
| renewal failed | Keep order history | Mark subscription access past due |
| refund succeeds | Partial or full refund | Revoke on full refund |
| dispute created | Mark disputed | Pause access pending outcome |
Product isolation
Share a platform without sharing customer assumptions.
Each app has its own server key, allowed payment origins, return paths, callback URL, provider switches, Stripe merchant route, customer namespace, and catalog. A key for one product cannot read another product’s orders or request a refund for them. App authentication happens before order lookup, and public recovery links use a separate short-lived token.
Every order snapshots its provider and merchant route. Stripe event retrieval, reconciliation, Portal, and refunds use the same Shinstar or Mindepy account that created the order. PayPal uses the approved Shinstar seller boundary and cannot be enabled for a Mindepy-routed app.
Product callbacks use an independently versioned per-app signing secret. The receiving backend verifies the timestamp, raw body, app ID, and event ID, then stores the event ID before granting access. Retries deliver the same semantic event rather than issuing access twice.
App-scopedkeys, customers, orders, prices
Immutableprovider and merchant order route
Signedentitlement callbacks with event IDs
Merchant responsibility
Accounts follow the real seller.
Products can share a Stripe account only when the legal seller, statement identity, invoice issuer, refund owner, dispute owner, and tax responsibility are aligned. Separate legal entities require separate accounts. Third-party sellers require a Stripe Connect design.
Yito Pay’s shared API does not hide those responsibilities. It makes an approved routing change an infrastructure concern instead of a rewrite in every product.
Explicit routes
Shinstar by default, alternatives only by assignment.
Shinstar is the default Stripe route and uses USD catalog Prices by policy. Mindepy is an alternate EUR route that must be fully configured and explicitly assigned per app. PayPal is separately switched and remains disabled until its credentials, webhook, catalog, and acceptance tests are complete.
No route is selected because another provider failed. That avoids creating a payment under one seller and later trying to reconcile or refund it with another seller’s credentials.
Questions, answered
Frequently asked questions
Does every SaaS product need its own Stripe account?
No. Products can share an account when the same legal seller, billing identity, support team, refund owner, dispute owner, and tax responsibility apply. Separate business responsibility should use a separate Stripe account or Stripe Connect.
Where do product prices come from?
Prices come from the Yito Pay server-side catalog and the exact merchant route assigned to the app. The browser cannot override the provider Price or Plan, amount, currency, mode, or entitlement.
How are subscriptions managed?
Yito Pay stores the subscription provider, synchronizes verified lifecycle events, and opens Stripe Billing Portal or PayPal Automatic Payments according to that stored route.
Build on a reliable payment boundary
Give every SaaS product one secure way to charge.
Start with the integration guide, then register the app, domain, and server credentials before enabling checkout.