Server-priced orders
Every SKU maps to an approved Stripe Price. A browser cannot lower the amount or select another merchant.
Payment infrastructure for focused SaaS teams
One Stripe payment gateway layer for every SaaS product.
Yito Pay gives approved products a consistent checkout contract while Stripe handles the sensitive payment form. Your server chooses the customer and SKU; verified webhooks decide when access begins.
A clear payment boundary
Keep Stripe payment gateway code simple without weakening controls.
A growing product portfolio should not require a different payment implementation for every launch. Yito Pay centralizes the parts that must stay trustworthy: app authentication, price lookup, order creation, Stripe account access, webhook verification, subscription state, refunds, and entitlement callbacks.
The product still owns its customer experience. It can open Stripe Embedded Checkout in a first-party modal or send the customer to a secure Yito Pay recovery page. In both paths, the browser receives only a publishable key and a short-lived Checkout client secret. Amounts, Stripe Price IDs, user identities, and return origins are selected on the server.
This is a control layer built on Stripe, not a replacement processor. Stripe collects payment details and moves funds for the configured merchant. Yito Pay maintains the application-side order record and sends signed outcomes back to the product.
Embedded by default
Show Stripe Checkout in a product modal, with a top-level hosted recovery page for browsers that need a fallback.
Webhook authority
Access changes only after a signed Stripe event reaches the idempotent order and entitlement pipeline.
A dependable sequence
One order moves through an observable path.
The product backend authenticates the signed-in user and sends an external order ID, external user ID, and SKU. Yito Pay verifies the app key, loads the catalog price, writes the local order, and creates one Stripe Checkout Session with a matching idempotency key.
When Stripe reports the result, the webhook endpoint validates the raw request signature before writing an event ID. A queue processes the event without assuming delivery order. Successful events update the order, grant the mapped entitlement, and create a signed callback for the product. Duplicate events are safe because the event ID, external order ID, and outbound entitlement event each have unique constraints.
Built for real failure modes
Retries are expected. Double charges are not.
Networks time out, customers close tabs, events arrive twice, and subscription updates can appear out of order. The payment design treats those conditions as routine rather than exceptional.
- Local orders exist before Stripe Sessions are created.
- Each external order ID is bound to one exact user, SKU, and quantity.
- Stripe requests carry deterministic idempotency keys.
- Webhook event IDs are recorded before asynchronous processing.
- Entitlement callbacks are signed, retried, and deduplicated.
- Checkout pages never grant access from a client-side success state.
The product sends
A small, auditable contract
POST /v1/checkout-sessions
{
"external_order_id": "writer_20260717_001",
"external_user_id": "usr_123",
"sku": "pro_monthly",
"quantity": 1
}The API key stays on the product server. The amount, currency, Price ID, return URL, and Stripe account never come from this request.
Designed for a product portfolio
Share infrastructure, preserve business responsibility.
Technical reuse does not erase merchant boundaries. Products that share the same legal seller, customer support, refund responsibility, tax treatment, and recognizable statement descriptor can use one Stripe account. A genuinely separate legal entity or business line should use its own Stripe account, while a marketplace with third-party sellers should use Stripe Connect.
Yito Pay keeps products unaware of that future routing decision. The integration remains an app ID, SKU, external order ID, and signed callback. When a business boundary changes, payment routing can change behind the control layer without teaching every product a new checkout flow.
1 APIfor approved SaaS backends
1 webhook pathwith event-level deduplication
0 card fieldshandled by Yito Pay servers
Questions, answered
Frequently asked questions
Is Yito Pay a payment processor or merchant of record?
No. Yito Pay is a software control layer built on Stripe. Stripe provides the payment form and payment processing for the configured merchant. The legal seller remains responsible for its products, taxes, refunds, disputes, and customer support.
Can customers pay without leaving the product page?
Yes. Approved products can mount Stripe Embedded Checkout inside a first-party modal. Payment methods that require bank authentication may still redirect temporarily, and a Yito Pay hosted recovery page remains available when embedding is not suitable.
Can the browser choose the payment amount?
No. The product server sends only a registered SKU and authenticated identifiers. Yito Pay reads the Stripe Price ID, currency, amount, payment mode, and return origin from its server-side catalog.
What confirms that a purchase is paid?
A verified Stripe webhook updates the authoritative order state. Client callbacks and success pages may show progress, but they never grant access by themselves.
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.