A WooCommerce iFrame checkout is a technique that embeds an external payment page directly inside your own domain, so customers complete their purchase without ever seeing a different URL. This approach is used by high-risk merchants who need to protect their PayPal or Stripe accounts from detection while still delivering a seamless buying experience. In this guide you will learn exactly how the WooCommerce iFrame checkout works, when to use it, and the seven most reliable methods available today.
- A WooCommerce iFrame checkout renders a second site’s payment page inside the first site’s domain via an HTML iFrame element.
- The buyer sees your high-risk domain URL while the actual payment is processed on a clean, low-risk site.
- CODARAB Redirect is the dedicated plugin that automates iFrame embedding, order sync, and customer notifications.
- iFrame cloaking reduces the risk of payment processor account bans triggered by domain blacklisting or keyword detection.
- Orders are synchronized in real time between both WooCommerce stores so you manage everything from one dashboard.
- A clean, minimal checkout on the second site is essential for the iFrame to load without CORS or X-Frame-Options errors.
- The WooCommerce iFrame checkout keeps your customer on your domain while routing payment data through a separate clean site.
- You need two WordPress/WooCommerce sites: one high-risk (Site A) and one low-risk (Site B).
- CODARAB Redirect offers three redirect triggers: Add to Cart, Proceed to Checkout, and custom payment method selection.
- Product names on PayPal receipts are automatically replaced with order numbers to hide sensitive keywords.
- Order status emails are sent only from Site A, preventing customer confusion.
- This strategy works alongside CODARAB Payments or any other processor including Stripe.
- What Is a WooCommerce iFrame Checkout?
- Why High-Risk Merchants Need iFrame Checkout Cloaking
- How the WooCommerce iFrame Checkout Works Technically
- Setting Up Two WooCommerce Sites: The Dual-Store Strategy
- CODARAB Redirect: The Dedicated iFrame Checkout Plugin
- 7 Proven Methods to Implement WooCommerce iFrame Checkout
- Comparison Table: iFrame Checkout vs Standard Redirect vs Direct Gateway
- Common Errors and How to Fix Them
- Order Sync and Customer Notifications Explained
- Hiding Product Names on PayPal Receipts
- Frequently Asked Questions
What Is a WooCommerce iFrame Checkout?
A WooCommerce iFrame checkout is a method of embedding the checkout page of one WooCommerce site (Site B) inside the checkout page of another WooCommerce site (Site A) using an HTML <iframe> element. The customer fills in their card details and clicks Pay while still seeing the URL of Site A in their browser address bar.
This is fundamentally different from a standard checkout redirect, where the customer is visibly sent to a new domain. With an iFrame approach, the transition is invisible. The buyer perceives a single, uninterrupted shopping experience from product page to order confirmation.
The technique is also called checkout cloaking because it masks the true payment processor domain from both the customer and, in many cases, from automated risk-detection systems that scan referrer URLs and webhook domain data.
Why High-Risk Merchants Need iFrame Checkout Cloaking
The WooCommerce iFrame checkout strategy exists because payment processors like PayPal and Stripe actively monitor the domains associated with merchant accounts. When a domain is flagged or blacklisted, the processor can detect it through webhook callbacks and suspend the account even if the merchant has opened a fresh account.
High-risk niches — including IPTV subscriptions, digital downloads, dropshipping of restricted products, peptides, and high-copy goods — are especially vulnerable. These businesses often have perfectly legitimate operations, but the product category alone can trigger automated risk algorithms.
By routing the payment through a clean, low-risk Site B while the customer remains on Site A, the merchant decouples the product domain from the payment domain. The processor’s webhook only ever sees the clean domain, never the high-risk one.
This is precisely the problem that CODARAB Redirect was designed to solve: a complete, automated solution for embedding Site B’s checkout inside Site A via an iFrame, with full order synchronization.
How the WooCommerce iFrame Checkout Works Technically
Understanding the technical flow of a WooCommerce iFrame checkout helps you configure it correctly and avoid common pitfalls like broken iFrames or CORS errors.
When a customer on Site A clicks a purchase button, one of three triggers fires:
- Add to Cart / Buy Now / Order Now — the customer is immediately redirected to a page on Site A that contains an iFrame pointing to Site B’s checkout.
- Proceed to Checkout — the redirect fires when the customer moves from the cart to the checkout step.
- Custom Payment Method — the iFrame appears only when the customer selects a specific payment option on Site A’s checkout page.
Site B must be configured with a clean, minimal checkout page that does not load unnecessary plugins, headers, or footers. This prevents the page from being blocked by the browser’s X-Frame-Options or Content-Security-Policy headers.
Once the customer submits payment on Site B’s form (rendered inside the iFrame on Site A), the order is created on Site B. CODARAB Redirect then instantly pushes the order data back to Site A via a REST API call, creating a mirrored order on Site A with the correct status.
You can learn more about building the right second-site setup in this detailed guide: how to build a clean low-risk checkout for iFrame cloaking.
Setting Up Two WooCommerce Sites: The Dual-Store Strategy
Implementing a WooCommerce iFrame checkout requires two separate WordPress installations. Each site plays a distinct role, and getting this architecture right is the foundation of the entire strategy.
Site A: The High-Risk Store
Site A is your public-facing store. It carries your brand, your product catalog, and all customer-facing pages. This is the domain your customers know and trust. It is also the domain that may be associated with a high-risk niche.
Site A does not need a payment gateway configured for live transactions. Its checkout page simply triggers the iFrame that loads Site B. For more background on this subject, see WooCommerce official documentation.
Site B: The Clean Payment Site
Site B is a separate WordPress/WooCommerce installation on a new, clean domain with no history of high-risk activity. It must have a working payment gateway — this can be CODARAB Payments (PayPal API), Stripe, or any other processor you prefer.
Site B’s checkout page should be stripped of all unnecessary elements: no navigation menu, no sidebar, no footer. The goal is a fast-loading, minimal form that renders well inside an iFrame.
Products on Site B do not need to be publicly visible. They exist only to receive order data forwarded from Site A. The full guide to setting up a low-risk backup store walks through every configuration step.
CODARAB Redirect: The Dedicated iFrame Checkout Plugin
CODARAB Redirect is the plugin built specifically to automate the WooCommerce iFrame checkout workflow between two WooCommerce sites. It handles every technical layer so you do not need custom code.
Core Features of CODARAB Redirect
The plugin provides three redirect trigger options (Add to Cart, Proceed to Checkout, custom payment method), real-time order synchronization between Site A and Site B, and automatic replacement of product names with order numbers on PayPal receipts.
Customer email notifications are sent exclusively from Site A. This means buyers receive order confirmations, status updates (Processing, Completed, On Hold, Failed, Cancelled), and invoices all from your branded store — they never see Site B’s domain in their inbox.
A live demonstration of CODARAB Redirect in action is available at the CODARAB demo site. Pricing details are published at codarab.com/redirect.
For a complete walkthrough of the plugin’s architecture, see the guide on showing external checkout pages on your own domain.
7 Proven Methods to Implement WooCommerce iFrame Checkout
There are multiple ways to implement a WooCommerce iFrame checkout, ranging from fully automated plugins to manual code approaches. Here are the seven most reliable methods, ranked by ease of implementation and reliability.
Method 1: CODARAB Redirect Plugin (Recommended)
Install CODARAB Redirect on both Site A and Site B. Configure the API connection between the two sites, set your preferred trigger (Add to Cart is the most seamless), and define which products on Site B correspond to those on Site A. The plugin handles iFrame injection, order sync, and notifications automatically.
Method 2: Custom Payment Method Trigger
Using CODARAB Redirect’s third trigger option, you can create a custom payment method on Site A’s checkout (for example, labeled “Pay by Card”). When the customer selects it, the iFrame loads Site B’s checkout inside Site A’s payment area. This is ideal if you want to keep other payment methods (like cash on delivery) active on Site A.
Method 3: Proceed to Checkout Trigger
Configure the redirect to fire when the customer clicks “Proceed to Checkout” in the cart. The customer sees Site A’s cart, clicks the button, and the next page they see is Site A’s checkout URL — but the payment form inside is Site B’s checkout rendered in an iFrame.
Method 4: Add to Cart / Buy Now Trigger
This is the most aggressive trigger. The moment a customer clicks Add to Cart or Buy Now on any product page, they are taken directly to the iFrame checkout. This shortens the funnel and is particularly effective for single-product stores or one-click upsell flows.
Method 5: Manual iFrame via Custom Page Template
For developers who prefer a code-based approach, you can create a custom WooCommerce page template in Site A’s theme that embeds an <iframe src="https://siteb.com/checkout/">. You must ensure Site B’s server sends permissive X-Frame-Options headers. This method requires manual order sync logic and is not recommended unless you have development resources.
Method 6: Payment Link Manager as iFrame Source
Instead of a full WooCommerce checkout, you can embed a payment link (from CODARAB Payments, Stripe, or another processor) inside an iFrame on Site A’s checkout page. This is a lighter setup but lacks automatic order synchronization. It works well for stores with a small, fixed product catalog.
Method 7: Hybrid Approach with CODARAB Payments on Site B
Combine CODARAB Redirect (for the iFrame embedding and order sync) with CODARAB Payments (for the actual card processing on Site B). CODARAB Payments uses the PayPal API to accept international cards without displaying the yellow PayPal button, and it automatically replaces product names with order numbers on PayPal receipts. This hybrid is the most complete protection stack available for high-risk WooCommerce merchants.
Comparison Table: iFrame Checkout vs Standard Redirect vs Direct Gateway
| Feature | iFrame Checkout (CODARAB Redirect) | Standard Checkout Redirect | Direct Payment Gateway |
|---|---|---|---|
| Customer stays on your domain | Yes | No | Yes |
| Payment processor sees clean domain | Yes | Yes | No |
| Real-time order sync | Automatic | Manual or plugin | Native |
| Customer notifications from Site A only | Yes | Configurable | Yes |
| Product name masking on receipts | Yes (order number) | Yes (with plugin) | Depends on gateway |
| Risk of domain blacklist detection | Very low | Low | High (for high-risk niches) |
| Setup complexity | Moderate (two sites) | Moderate | Low |
| Works with Stripe, PayPal, CODARAB Pay | Yes | Yes | Yes |
Common Errors and How to Fix Them
Even a well-configured WooCommerce iFrame checkout can fail if certain server or plugin settings are not adjusted. Here are the most frequent issues and their solutions.
X-Frame-Options Blocking the iFrame
If Site B’s server sends an X-Frame-Options: SAMEORIGIN or DENY header, the browser will refuse to render the iFrame. The fix is to add a server-level rule (in .htaccess or Nginx config) that permits iFrame embedding from Site A’s domain specifically.
CDN Blocking iFrame Requests
Some CDN providers (including Cloudflare on certain plans) add security headers that block cross-origin iFrame loading. If you are using a CDN on Site B, you may need to disable or configure the relevant security header rules. A similar issue affects n8n integrations on Hostinger — the fix involves disabling CDN for the relevant subdomain.
WooCommerce Session Conflicts
When Site B’s checkout is loaded inside an iFrame on Site A, the browser may block third-party cookies, which WooCommerce uses for session management. The solution is to configure Site B to use URL-based session tokens rather than cookie-based sessions, or to ensure both sites share a parent domain so cookies are treated as first-party.
iFrame Height Not Adjusting Dynamically
A fixed-height iFrame will cut off Site B’s checkout if the form is taller than expected (for example, when validation errors appear). Use JavaScript’s postMessage API to allow Site B to communicate its current height to Site A, which then resizes the iFrame dynamically.
Order Sync and Customer Notifications Explained
One of the most important features of a properly implemented WooCommerce iFrame checkout is seamless order synchronization. Without it, your Site A dashboard would show no orders even though payments are being processed on Site B.
This architecture means your customer service team works entirely within Site A. They see all orders, update statuses, and communicate with buyers — all without any awareness that a second site was involved in the transaction.
For a deeper technical explanation of how this sync works, see the article on how CODARAB Redirect syncs orders between two WooCommerce stores instantly.
Hiding Product Names on PayPal Receipts
A WooCommerce iFrame checkout protects your domain from being seen by the payment processor’s webhook system, but there is a second exposure point: the product name that appears on the PayPal receipt sent to the buyer.
If your product is named “IPTV Monthly Subscription” or “High Copy Jordan Shoes,” that text is transmitted to PayPal as the item description. PayPal’s automated systems scan these strings for keywords associated with restricted product categories. A match can trigger an account review or immediate limitation. For more background on this subject, see WordPress platform overview.
CODARAB Redirect solves this by replacing the product name on all PayPal receipts with the WooCommerce order number in the format Order#1234. The buyer still receives a clear receipt showing the total amount charged, but no product keywords are exposed to PayPal’s detection algorithms.
This feature is also available in CODARAB Payments as a standalone option, independent of the iFrame redirect setup. You can read the full explanation in the guide on how to anonymize WooCommerce orders for high-risk product stores.
Frequently Asked Questions
What exactly is a WooCommerce iFrame checkout?
A WooCommerce iFrame checkout embeds the checkout page of a second WooCommerce site inside the checkout page of your main site using an HTML iFrame. The customer completes payment while still seeing your domain in the browser address bar, giving a seamless experience and protecting your payment account from domain-based risk detection.
Do I need two separate hosting accounts for the iFrame checkout strategy?
You need two separate WordPress/WooCommerce installations, but they can share the same hosting provider as long as they run on different domains. It is generally advisable to use separate hosting accounts to ensure the two sites have distinct IP addresses, which further reduces the risk of cross-contamination in payment processor records.
Will customers know their payment is being processed on a different site?
No. With a correctly configured WooCommerce iFrame checkout, customers see only your Site A domain in their browser address bar throughout the entire purchase flow. The iFrame is invisible to them — they interact with what appears to be a single, unified checkout form on your store.
Which payment gateways work with the iFrame checkout approach?
Any payment gateway that can be installed on a WooCommerce site works on Site B. This includes CODARAB Payments (PayPal API), Stripe, and other standard gateways. The iFrame approach is gateway-agnostic — it only controls which domain the customer sees, not how the payment is processed.
What happens if Site B goes down during a customer’s checkout?
If Site B is unavailable, the iFrame will fail to load and the customer will see an empty or broken checkout area. To mitigate this risk, ensure Site B is hosted on reliable infrastructure with good uptime, and consider adding a fallback message or alternative payment method on Site A that activates if the iFrame fails to render within a set timeout.
Does the WooCommerce iFrame checkout work on mobile devices?
Yes, but mobile browsers handle iFrames differently. You must ensure the iFrame is fully responsive and that Site B’s checkout form is optimized for small screens. Use a minimal checkout template on Site B with no fixed-width elements. Testing on multiple mobile browsers before going live is strongly recommended.
How does CODARAB Redirect handle order status updates?
When an order status changes on Site B (for example, from Processing to Completed), CODARAB Redirect pushes the update to Site A via the REST API. Site A then sends the corresponding customer notification email. Site B’s own notification emails are suppressed, so the customer receives only one set of emails from your branded Site A domain.
Can I use the iFrame checkout with a free trial or subscription product?
Yes. As long as Site B supports subscription billing (via WooCommerce Subscriptions or a compatible gateway), the iFrame approach works for recurring payments. The initial subscription is processed through the iFrame, and subsequent renewals are handled directly by Site B’s gateway without requiring the customer to go through the iFrame again.
Is the iFrame checkout method legal and compliant with payment processor terms?
Using an iFrame to render a checkout page is a standard web development technique. However, you must ensure that both sites are compliant with your payment processor’s terms of service, that you are not using the setup to process payments for explicitly prohibited products, and that customers are not deceived about who is processing their payment. Always consult the terms of your specific payment processor and applicable local regulations.
What is the difference between checkout cloaking and a standard checkout redirect?
A standard checkout redirect visibly sends the customer to a new URL on a different domain. Checkout cloaking via an iFrame keeps the customer on the original domain while loading the payment form from a second site inside an invisible iFrame. Cloaking provides a better user experience and a higher level of domain separation from the payment processor’s perspective.
The WooCommerce iFrame checkout is the most effective way to accept payments on a high-risk domain without exposing that domain to your payment processor’s automated detection systems. By combining the dual-store architecture with CODARAB Redirect’s iFrame embedding, real-time order sync, and product name masking, you get a complete protection and conversion solution in a single plugin. To get started with the full setup, visit the CODARAB Redirect plugin page and explore the documentation and live demo.