Simple product contract
Apps integrate through an authenticated server request, provider checkout configuration, 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 and PayPal process payment for the configured seller. Yito Pay creates an application order, selects an approved catalog entry and merchant route, receives verified payment facts, 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
Provider accounts follow the actual seller, statement identity, support, refund, dispute, tax, and invoicing responsibility.
Design principles
Correctness before surface area.
The production system uses one Worker, one existing Neon database schema, provider-specific Queue pipelines, explicit merchant routes, and a small set of server endpoints. Stripe/Shinstar remains the default. Mindepy and PayPal require deliberate app assignment and complete provider configuration; neither is automatic failover.
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 or provider policy, that responsibility is stated directly.
Approved product teams receive integration documentation and server credentials. Customers receive a provider-owned payment experience in the product context and a single Yito Pay contact path for routing billing questions to the appropriate seller or provider.
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, provider routes, and merchant responsibility have been registered.
Is Yito Pay a merchant of record?
Yito Pay itself is not a merchant of record. The configured seller remains responsible on Stripe and PayPal routes.
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.