The payment provider only ever sees your domain

Merchants with several Stripe accounts usually have them for ordinary reasons: separate legal entities, separate countries, a limit on one account that the business has outgrown. What they do not want is for the payment provider to see a single orchestration platform sitting across all of them. orcapayz is designed so that, from the provider’s side, each checkout is just the merchant’s own site.

Checkout on your domain

When a merchant connects orcapayz, they add a CNAME for pay.theirshop.com pointing at our edge. The checkout page, the return URL after a payment, the webhook endpoints Stripe calls: all of them live under that hostname. Stripe sees a request from pay.theirshop.com with a card form on it. The orcapayz hostname never appears in a URL the provider receives.

This needs the domain to be verified before any traffic is routed to it, otherwise anyone could point a CNAME at us and host a checkout page that looks like someone else’s shop. Verification is a file at /.well-known/payment-domain-verification that orcapayz serves with a token tied to the merchant. The merchant’s DNS has to resolve to us, and the token has to match. It works behind Cloudflare’s proxy because the check is over HTTP, not DNS.

Locking the host

The checkout application only answers on verified hostnames. A request to the raw orcapayz domain for a merchant route returns a 404, and a request on a verified domain for a different merchant’s checkout session also returns a 404. The middleware does this before any controller runs. It sounds obvious; it was the first thing a security review asked about.

Referrers

The return redirect after a payment goes through an interstitial page under the merchant’s domain that sets Referrer-Policy: no-referrer and then forwards to the final thank-you URL. Without that, the provider’s dashboard could show the orcapayz domain in the referrer chain of a successful payment.

The same interstitial checks a session cookie set when the checkout started, so a user who bookmarks the return URL cannot replay it into a fake success page.

Routing, briefly

With the domain handled, the routing itself is the simpler part. Each account has a target share of traffic, a daily cap and a monthly cap. A payment intent goes to the account that is furthest below its target share among those under their caps. If that account rejects it, the next eligible account is tried inside the same request, so the customer never sees the failure. After a configurable number of consecutive rejections the account is paused and a Telegram message goes out.

Shares are computed from successful payments, not attempts, and are renormalised across the accounts that are not paused. If you set 50/30/20 and the 30 is paused, the other two run at 71/29 until it comes back.

What the merchant keeps

Their Stripe accounts, exactly as they were. orcapayz uses restricted keys, never touches payout settings, and refunds go through the same account that took the payment. If a merchant stops using orcapayz, they delete the CNAME and the keys and nothing on the Stripe side changes.