No trusted browser price
The browser submits no amount, currency, provider Price or Plan ID, merchant route, or arbitrary return URL.
Security by explicit boundaries
Payment gateway security that keeps trust on the server.
Yito Pay minimizes exposed payment data, validates every application boundary, and makes fulfillment traceable to verified provider facts instead of browser claims.
Reduced payment data exposure
Payment details go directly to the selected provider.
Yito Pay does not provide card-number fields and does not ask a product to collect sensitive payment details. Stripe Embedded Checkout or an approved PayPal experience renders the provider interface and sends payment information directly to that provider. Yito Pay receives provider object identifiers and business status, not full card numbers or CVC values.
This boundary reduces exposure, but it does not erase the applicable seller or integration compliance duties. Each route preserves the product claims, customer support, tax, refund, dispute, and account responsibility disclosed for that transaction.
All production traffic uses HTTPS. Secrets are stored as Cloudflare Worker secrets rather than source-controlled variables, public JavaScript, or general-purpose database columns.
No recoverable app key
The database contains a keyed digest. Plaintext product credentials are issued once and rotated if lost.
No client-side fulfillment
A success screen can inform the customer, but only verified server facts change access.
Application isolation
Every request is scoped to one approved app.
The app credential resolves to one active application record. Orders, customer mappings, products, domains, provider routes, subscription management, and refunds are queried under that app ID. The product cannot use its credential to inspect another app’s order or choose another app’s catalog entry.
Exact return origins and Stripe payment domains are registered ahead of time. A request cannot introduce an open redirect by supplying a new URL. Server-side rate limits and unique external order IDs reduce abuse without replacing financial idempotency.
- App credentials are sent only with bearer authentication over HTTPS.
- Customer identities come from the authenticated product backend.
- SKU, quantity limits, price, currency, provider, and payment mode are validated.
- Order retries must preserve the original request contract.
- Refunds and subscription-management calls are app-scoped server actions.
Event integrity
Verify at every asynchronous boundary.
Stripe validates the exact raw body and endpoint signature. PayPal validates its complete webhook signature envelope against the untouched body. Provider-scoped unique event IDs prevent duplicate processing, and Queue consumers record concrete failures rather than silently swallowing them.
Every order snapshots its provider and merchant route. Later webhook retrieval, reconciliation, refunds, and subscription management must match that route, so a Mindepy object cannot be settled with Shinstar credentials and a PayPal object cannot be treated as Stripe.
Product callbacks have a separate app-derived signing secret. Their timestamp, raw body, and stable event ID let the receiver reject forged or replayed updates. Database uniqueness ensures a retry cannot grant an entitlement twice.
Responsible operations
Security continues after deployment.
Dependencies, Worker configuration, response headers, endpoint behavior, and live checkout paths require ongoing review. Access to Stripe, PayPal, Cloudflare, GitHub, Neon, analytics, and search tools should be granted by role and removed when no longer necessary.
Potential vulnerabilities should be sent privately to contact@pay.yito.ai with the affected URL, a concise reproduction, and the reporter’s contact information. Do not include real payment data, customer secrets, or exploit unrelated accounts. We will acknowledge a credible report and coordinate a safe review.
Availability, payment status, and downstream callback failures are observable separately. A product should retain a pending customer state when confirmation is delayed and must never trade correctness for a misleading success screen.
HTTPSfor every production endpoint
Verifiedprovider events and signed callbacks
Fail fastwith specific, non-secret errors
Questions, answered
Frequently asked questions
Does Yito Pay store card numbers or CVC values?
No. Stripe or PayPal collects payment details in its provider-owned interface. Yito Pay stores the order and provider object identifiers needed to reconcile the purchase.
How are product API keys protected?
The plaintext key is issued once to the product backend. Yito Pay stores a keyed digest, and production master keys are kept as Cloudflare Worker secrets.
How should a vulnerability be reported?
Email contact@pay.yito.ai with the affected URL and a safe reproduction. Do not include real payment details or access data that does not belong to you.
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.