No trusted browser price
The browser submits no amount, currency, Stripe Price ID, merchant account, 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 signed Stripe events instead of browser claims.
Reduced payment data exposure
Payment gateway security sends card details directly to Stripe.
Yito Pay does not provide card-number fields and does not ask a product to collect sensitive payment details. Stripe Checkout renders the payment interface and sends payment information to Stripe. Yito Pay receives Stripe object identifiers and business status, not full card numbers or CVC values.
This boundary reduces exposure, but it does not erase the merchant’s compliance duties. Each seller remains responsible for its Stripe account, product claims, customer support, taxes, refund terms, disputes, and the PCI validation that applies to its integration.
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 page can inform the customer, but only verified server events 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, portal sessions, 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 Price ID.
Exact return origins and checkout 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, and payment mode are validated.
- Order retries must preserve the original request contract.
- Refunds and portal sessions are app-scoped server actions.
Event integrity
Verify at every asynchronous boundary.
The Stripe webhook validates the exact raw body and endpoint signature before persistence. A unique event ID prevents duplicate processing. Queue consumers claim events and record concrete failures rather than silently swallowing them.
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.
Operational logs exclude secret keys, webhook secrets, app keys, Checkout client secrets, full signature headers, card details, and authentication payloads. Errors identify the failed object without printing the credential that authorized it.
Responsible operations
Security continues after deployment.
Dependencies, Worker configuration, response headers, endpoint behavior, and live checkout paths require ongoing review. Access to Stripe, 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 card 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
HMACat Stripe and product boundaries
Fail fastwith specific, non-secret errors
Questions, answered
Frequently asked questions
Does Yito Pay store card numbers or CVC values?
No. Stripe Checkout collects payment details directly. Yito Pay stores order and Stripe 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.