Stripe cloacking system question

[Marcus Donk]

Hello, I would like my customers to pay from my site A, but I would like to declare site B to Stripe. I’ve developed a system, but I’m not sure if I will end up being automatically detected by Stripe.


Note that both sites are on the same server, so they have the same IP, which is a positive, right? Since Stripe detects the client coming from the same IP, does this mean it considers that it's the site declared as B?


The customer arrives on site A, clicks the payment button on site A, a pop-up window appears with a payment form, and this form is actually an iFrame from my site B. The customer enters their payment details and pays, then the iFrame is closed and all requests are processed on site B.


Do you think this is okay?

 

[myplaysoft]

The system you describe appears to be simplistic, here is why: when you open an iframe, that element sends its real location (different from the URI of page that loads it) to any remote request, i.e., HTTP HOST and URI. Even if to a certain degree the remote machine relies mainly on IP, some specific page data is passed, in this case the URI of the iframe. In order to better understand the requirements of such a system, you may read the topic about paypal cloaking (posted on this section).

 

[Be dybala]

Your setup might work technically, but Stripe can still detect the discrepancy through referrer URLs, JavaScript SDK calls, API requests, and webhooks. Even though both sites share the same IP, Stripe may see that payments originate from Site A while Site B is the declared one. Using an iFrame doesn’t fully hide this, as the referrer and script execution can reveal the mismatch. This could lead to compliance issues, account scrutiny, or even termination if Stripe deems it misleading. It's best to clarify your setup with Stripe to avoid potential risks

 

[Marcus Donk]

Your setup might work technically, but Stripe can still detect the discrepancy through referrer URLs, JavaScript SDK calls, API requests, and webhooks. Even though both sites share the same IP, Stripe may see that payments originate from Site A while Site B is the declared one. Using an iFrame doesn’t fully hide this, as the referrer and script execution can reveal the mismatch. This could lead to compliance issues, account scrutiny, or even termination if Stripe deems it misleading. It's best to clarify your setup with Stripe to avoid potential risks

with no-referrer on the page should do it?

 

[Be dybala]

with no-referrer on the page should do it?

Setting no-referrer can help hide the original source, but it doesn’t fully solve the issue. Stripe can still detect mismatches through JavaScript execution, API calls, and webhook origins. If you're using Stripe.js or Elements, the domain making the request is logged. Also, if Stripe sees unusual behavior (like payments consistently coming from a hidden referrer), it might flag your account for review. While no-referrer reduces visibility, it’s not a foolproof solution against detection.

 

[myplaysoft]

After thinking closer to the cloaking scenario you are mentioning, I realized that your approach needs only one more condition in order to work: loading the money page content otherwise than an iframe. So, if you developed a detection system for unwanted traffic, the next step would be to create a sort of switch function that loads selected content based on filtering criteria. In this case, the script will use the same resources (sdk, api etc) for both black and white page.

 

[johnbennett]

Your setup might work initially, but Stripe has multiple ways to detect discrepancies. Here’s what you need to know:

1. Referrer & JavaScript Detection – Stripe tracks referrer URLs, API requests, and JavaScript execution. Even if both sites share an IP, Stripe will likely see transactions originating from Site A while Site B is registered.
2. iFrame Limitations – The iFrame still sends its real location (via HTTP headers), exposing the mismatch. Setting no-referrer can help, but it won’t completely hide the origin.
3. Better Approach – Instead of using an iFrame, consider a redirect or a dynamic content loader that serves the payment form directly on Site A while still calling resources from Site B. This reduces obvious mismatches.
4. Risk of Account Review – If Stripe flags your setup as misleading, they might suspend or terminate your account. If your business model relies on this, it’s worth exploring alternatives or consulting with Stripe directly.

 

[Marcus Donk]

I have another idea.

Imagine I have two websites, A and B, and my goal is to hide site A while still allowing users to make payments from it.


The idea would be to declare site B and another domain, such as "payment-gateway.com", to handle the payments. Site B would redirect to "payment-gateway.com" when a user wants to make a payment. Similarly, site A would also redirect to "payment-gateway.com" for payments, but with a detection mechanism that identifies the visitor's origin.


If the user comes from site A, the final action taken could be different from the one triggered from site B.


In this case, the entire architecture revolves around site B and "payment-gateway.com" for processing payments. Thus, following this logic, Stripe would never be able to directly detect that the payment originates from site A, as all redirects go through "payment-gateway.com", and only this site interacts with the payment system.

 

[Resimote]

Can't you spoof the referrer or the whole request headers for that matter?

 

[ZaynWantsMoney]

Maybe we can add a loader page on site b and create a payment intent from that page, then redirect to the actual checkout on site b

 

[Emma xx]

Feels kinda shady, TBH. Why not just declare site A? Seems like you're asking for trouble down the line.

 

[bartosimpsonio]

Study your competitors. What are they doing? Someone has to have it set up right? When you find one, do same they're doing, only better

 

[CyberHR]

OP, I’m sorry to say this, but trying to fool the Stripe system is a bad idea. They are much smarter than you might think.

 

[stiffidy]

OP, I’m sorry to say this, but trying to fool the Stripe system is a bad idea. They are much smarter than you might think.

Not really..

Have seen it happen, were fooled multiple times.
Accounts operated for years, but got closed ONLY because they reached over 1% dispute rate in a short period and it was multiple times.

It was the same system the guy is talking about. It's something to do with "gateways", wasn't really exposed to the system how it works and operates.

 

[berserk.guts]

If you're running both the A and B sites on the same server, even with different subdomains or IPs, Stripe's detection systems can still flag the setup. They analyze more than just IP addresses - factors like SSL certificates, server configurations, and even behavioral patterns come into play.

To minimize detection risk:

• Separate Infrastructure: Host the A and B sites on entirely different servers, preferably in different data centers or using different hosting providers.
• Distinct SSL Certificates: Use unique SSL certificates for each site to prevent fingerprinting.
• Avoid Shared Resources: Ensure there are no shared assets (like images or scripts) between the two sites.
• Monitor Traffic Patterns: Keep an eye on traffic to both sites to detect any anomalies that might raise red flags.

Remember, while technical measures can reduce risk, they don't eliminate it entirely.

 

[cartiology]

I like this topic and I am thinking of implementing a similar system. The most current idea of the OP is actually almost identical to what I was thinking of. The beauty is that theoretically you can have multiple websites cloacked with just 1 Site B.

Suppose you operate 2 replicas store A1 - Sneakers, A2 - Handbags, and would like to have a simple to manage infrastructure for both of the websites at the same time.

You set up the cloacking website C, as a legitimate company, that does exactly what you described in your Stripe application. Whenever a user wants to make an order on either A1 or A2, you open your website C in the same window, with specific queries eg.

http://www.c.shop/payment?ref=a1?product_id=120?currency=....

And then, on the backend side you just select to which Stripe payment page you want to redirect (to spread the volume)

In my head I see no flaws with this approach, you have an independent credible website running on a separate VPS, that is easy to manage and modify.

Looking forward a discussion on flaws I might not see
Cheers and good luck

 

[Alphamale1]

I need someone to do that service for me

 

[Raulz112]

I have setup something similar for a client :

Customer Visits website A ( some product ) taps buy -> have a website spinner for different legit sites ( where stripe is active ) -> lands on the order form on website B,C,D which displays the product from website A based on URL variables( ex. s1=name&s2=price&s3=image, etc ) , then the customer thinks it buys the product from website A but in fact they pay for a subscription service setup thru stripe.

Is this what you are looking for ?

 

[jeninen]

Best way is to actually try it, because stripe is ahead of everyone. 100% and most of the times they know you're cloaking, and they'll let you be as long as you hqave 0-1% chargeback rate. And they see your transactions are legit with no to low spam score.

 

[aar1337]

Using the same IP helps, but Stripe mainly looks at domain and SSL info. Your iframe method can work if both sites comply with Stripe’s rules and share consistent branding. Just watch for any red flags from Stripe’s fraud system.