Simple product contract
Apps integrate through an authenticated server request, a checkout client secret, order status, and signed entitlement events.
About Yito Pay
Yito Pay is a payment control layer for focused SaaS products.
Yito Pay centralizes the payment responsibilities that benefit from one carefully operated system while leaving product experience and merchant responsibility visible.
Why it exists
Yito Pay reduces the risk of repeated checkout code.
Small SaaS products should be able to test real demand without rebuilding price validation, order idempotency, webhook verification, subscription synchronization, refunds, and access callbacks for every launch. Yito Pay provides that shared boundary for approved applications.
The system is intentionally narrow. It is not a card network, bank, merchant of record, or attempt to hide what a product sells. Stripe processes payments for the configured seller. Yito Pay creates an application order, selects an approved Stripe Price, receives verified payment events, and reports an auditable outcome to the product.
That separation makes the customer experience consistent and keeps legal responsibility honest. Shared infrastructure does not require unrelated sellers to appear as one merchant, and a new domain does not automatically justify a new Stripe account.
Visible customer context
Checkout, recovery, contact, privacy, terms, and refund information remain understandable to the person paying.
Explicit merchant boundary
Stripe accounts follow the actual seller, statement identity, support, refund, dispute, tax, and invoicing responsibility.
Design principles
Correctness before surface area.
The first production version uses one Worker, one existing Neon database schema, one queue pipeline, one Stripe account, and a small set of server endpoints. Features are added only when a real product requires them. That focus gives teams a repeatable launch path without hiding commercial responsibility.
Functions have focused responsibilities, public modules expose clear contracts, and database inputs are validated at the boundary. Errors are concrete and visible. The system does not hide unexpected failures behind empty catch blocks or optimistic browser messages.
Customer promise
A checkout should explain what happens next.
Customers can see what they are buying, who supports the purchase, how payment is processed, and where to ask about billing. When confirmation is delayed, the interface shows a pending state rather than claiming success. When a refund depends on a product’s policy, that responsibility is stated directly.
Approved product teams receive integration documentation and server credentials. Customers receive a secure Stripe payment experience and a single Yito Pay contact path for routing billing questions to the appropriate seller.
Questions, answered
Frequently asked questions
Who can integrate with Yito Pay?
Yito Pay is available to approved Yito products and SaaS applications whose product, domain, pricing, support, and merchant responsibility have been registered.
Is Yito Pay a merchant of record?
No. The configured seller remains responsible for the product, taxes, invoices, refunds, disputes, and customer service. Stripe provides payment processing.
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.