How CODARAB Redirect Works: High Risk Site to Low Risk Checkout

CODARAB Redirect is a WooCommerce plugin that silently transfers customers from a high risk store (Site 1) to the checkout page of a clean, low risk store (Site 2), so your PayPal, Stripe, or any other payment processor never sees the sensitive domain name or product details that could trigger a suspension. If your domain is already flagged on a payment processor blacklist, CODARAB Redirect is the complementary layer that keeps your revenue flowing even when CODARAB Payments alone cannot fully shield you.

What Is CODARAB Redirect and Why Does It Exist?

CODARAB Redirect is a WooCommerce plugin developed by CODARAB specifically to protect payment processor accounts for merchants operating in high risk niches such as IPTV subscriptions, digital products, peptides, dropshipping, and high copy goods. It redirects the customer from the checkout of a high risk site to the checkout of a separate, clean low risk site, while keeping the entire experience transparent to the buyer.

The plugin was created as a direct response to a limitation of CODARAB Payments. Even though CODARAB Payments hides product names on PayPal receipts and disables the yellow PayPal button, PayPal can still detect a blacklisted domain through its Webhook functionality. CODARAB Redirect eliminates that vector entirely by routing the actual payment transaction through a domain that has no negative history.

The Core Problem: Why High Risk Domains Get Flagged

Payment processors like PayPal and Stripe use automated systems, often called robots, that continuously scan merchant data for signals associated with prohibited or high risk activity. When a domain name itself appears on an internal or external blacklist, every transaction originating from that domain becomes a liability, regardless of how the product names are masked at the receipt level.

The Webhook mechanism is the critical exposure point. When WooCommerce sends a payment request, the processor receives metadata that includes the originating domain. If that domain is flagged, the processor can act immediately, freezing funds or suspending the account without any human review.

This is precisely why CODARAB Redirect was engineered. By routing the payment through a second, clean domain, the processor only ever sees the low risk site. The high risk domain never appears in the payment data trail.

How CODARAB Redirect Works Step by Step

CODARAB Redirect creates a seamless bridge between two WooCommerce installations. The customer browses and adds products on Site 1 (the high risk store), but the payment is processed entirely on Site 2 (the low risk store). Here is the precise flow:

CODARAB Redirect handles the entire data transfer automatically. No manual order duplication is required, and neither the merchant nor the customer needs to take any additional action once the plugin is configured.

The 3 Redirect Trigger Options Explained

CODARAB Redirect gives merchants precise control over exactly when the redirect to the low risk checkout fires. There are three distinct trigger modes, and each serves a different checkout architecture.

Trigger A1: Add to Cart, Buy Now, or Order Now Button

When this trigger is active, clicking any of these product-level buttons immediately redirects the customer to the Site 2 checkout page. The cart is populated automatically on Site 2 before the customer even sees the checkout form. This is the most aggressive option and is ideal when you want to minimise the time the customer spends on Site 1 before the payment phase.

Trigger A2: Proceed to Checkout Button

This trigger fires when the customer clicks the Proceed to Checkout button on the cart page of Site 1. The customer can browse and manage their cart normally on Site 1, but the moment they initiate the checkout process, CODARAB Redirect takes over and transfers them to Site 2. This option balances a natural shopping experience with strong payment protection.

Trigger A3: Custom Payment Method Selection

This is the most granular option. The redirect fires only when the customer selects a specific custom payment method on the Site 1 checkout page. This allows merchants to offer multiple payment options on Site 1 and route only certain payment flows through Site 2. It is particularly useful when some payment processors are safe on Site 1 while others require the clean domain of Site 2.

Real-Time Order Synchronisation Between Two Stores

CODARAB Redirect synchronises orders automatically and immediately between Site 1 and Site 2. The moment a payment is confirmed on Site 2, the corresponding order record is created or updated on Site 1 without any manual intervention. For more background on this subject, see WooCommerce official documentation.

This bidirectional sync covers all standard WooCommerce order statuses: Processing, Completed, Cancelled, On Hold, and Failed. If a customer requests a refund or a payment fails on Site 2, the status change propagates to Site 1 instantly.

The sync architecture means your fulfilment workflow, inventory management, and reporting all happen on Site 1 as if no redirect ever occurred. Your team operates from a single dashboard and never needs to log into Site 2 to manage orders.

For merchants managing large volumes, this real-time synchronisation eliminates the reconciliation overhead that would otherwise come with running two separate stores. CODARAB Redirect handles the technical bridge entirely through its own API layer.

iFrame Checkout: Staying on Your Domain During Payment

CODARAB Redirect includes an iFrame mode that embeds the Site 2 checkout page directly inside the Site 1 domain, so the customer never sees a URL change. From the customer perspective, they are completing payment on highrisk.com/checkout, but the checkout form they are interacting with is actually served from lowrisk.com.

This feature is critical for conversion rates. URL changes during checkout create friction and can trigger abandonment, especially for returning customers who notice a domain switch. The iFrame mode eliminates that concern entirely.

It also provides a layer of operational security. If a competitor or a processor compliance team manually reviews the checkout experience, they see only the high risk domain URL in the browser address bar. The underlying payment routing through Site 2 remains invisible at the URL level.

The iFrame is fully responsive and adapts to all screen sizes. Mobile customers experience the same seamless checkout as desktop users, with no layout breaks or scroll issues introduced by the embedding.

Product Name Masking on PayPal and Stripe Receipts

CODARAB Redirect replaces sensitive product names with the WooCommerce order number on all payment processor receipts, regardless of which processor is active on Site 2. Instead of displaying a line item like “IPTV: Monthly Subscription” or “Jordan Nike High Copy,” the receipt shows only “Order #1234.”

This masking is essential because payment processor robots scan receipt data for keywords associated with prohibited categories. A product name containing “IPTV,” “replica,” or “peptide” can trigger an automated account review or suspension even when the payment itself is legitimate.

The order number format used by CODARAB Redirect follows the standard WooCommerce order ID structure, which looks entirely routine to any automated compliance scan. There are no unusual patterns that would draw attention.

This feature works in combination with the domain routing: the processor sees a clean domain in the Webhook data and a neutral order number in the receipt data. Both signals together present the lowest possible risk profile for your payment account.

For a deeper look at how product name masking works at the receipt level, see the detailed guide on anonymising WooCommerce orders for high risk product stores.

Customer Notification Flow: Only One Store Sends Emails

One of the most thoughtful design decisions in CODARAB Redirect is the email notification architecture. Customers receive all order status communications exclusively from Site 1, the high risk store. Site 2 never sends any emails to the customer.

This matters for two reasons. First, it prevents customer confusion. If a buyer received emails from two different domain names about the same order, they would likely suspect fraud or a technical error, leading to disputes or chargebacks.

Second, it protects the merchant from exposing the existence of Site 2. If a customer received an email from the low risk domain, they might investigate that domain, discover it is a shell checkout site, and report it to the payment processor, triggering exactly the kind of review the redirect architecture is designed to avoid.

The notification flow is fully automated. When an order status changes on Site 2, the sync updates Site 1, and Site 1 triggers its own standard WooCommerce email to the customer. The merchant’s branding, email templates, and sender address all remain consistent.

CODARAB Redirect vs CODARAB Payments: Which Do You Need?

CODARAB Redirect and CODARAB Payments are complementary solutions designed for different stages of payment account risk. Understanding which one applies to your situation prevents unnecessary expense and ensures you implement the right level of protection.

When CODARAB Payments Is Sufficient

If your domain is not yet on any payment processor blacklist, CODARAB Payments provides strong protection on its own. It hides product names on PayPal receipts, disables the yellow PayPal button to reduce disputes, and processes card payments through the PayPal API without exposing your product categories. For merchants just starting out in high risk niches, CODARAB Payments is the right first tool.

When CODARAB Redirect Is Required

If your domain has already been flagged, suspended, or placed on a blacklist by PayPal or Stripe, CODARAB Payments alone cannot solve the problem because the Webhook still exposes your domain. CODARAB Redirect is the correct solution in this scenario. It routes all payment activity through a clean domain, making the flagged domain invisible to the processor.

Many established merchants use both solutions together: CODARAB Payments on Site 2 for card processing, and CODARAB Redirect on Site 1 to route customers there. This layered approach provides the maximum available protection for high risk WooCommerce stores.

For a full comparison of both solutions, the article on CODARAB Pay vs CODARAB Redirect covers every use case in detail.

Prerequisites and Setup Requirements

CODARAB Redirect requires a specific technical setup before it can be installed and configured. Understanding these requirements in advance prevents delays and ensures the redirect architecture functions correctly from day one.

What You Need Before Installing CODARAB Redirect

You need two separate WordPress/WooCommerce installations. Site 1 is your existing high risk store where customers browse and discover products. Site 2 is a new, clean WooCommerce store on a domain with no payment processor history. Site 2 must have a payment processor configured, which can be CODARAB Payments, Stripe, or any other gateway you prefer.

Both sites must be on separate hosting accounts or at minimum separate hosting plans. Using the same IP address for both sites can reduce the effectiveness of the domain separation if a processor performs IP-level checks.

Setting Up the Low Risk Site 2

Site 2 should be a minimal, professional WooCommerce store with no high risk product listings visible to the public. Its checkout page should be clean and functional, with no branding elements that connect it visually to Site 1. The CODARAB Redirect plugin handles the cart data transfer, so Site 2 does not need a full product catalogue.

If you do not yet have a professional WordPress site ready, CODARAB offers web development services at competitive rates. You can contact them directly through codarab.com to request a ready-made site with an integrated payment gateway.

Plugin Installation and Configuration

Once both sites are ready, the CODARAB Redirect plugin is installed on Site 1. The configuration panel allows you to set the Site 2 checkout URL, choose your redirect trigger mode, enable or disable the iFrame option, and activate product name masking. Full documentation and pricing are available at codarab.com/redirect. For more background on this subject, see PayPal merchant account information.

To see how the checkout cloaking mechanism prevents account bans in practice, the guide on how checkout cloaking prevents account bans provides an in-depth technical walkthrough.

For merchants who want to understand the dual site strategy at a strategic level before committing to implementation, the article on WooCommerce dual store strategy explains the broader business rationale.

You can also watch a live demonstration of CODARAB Redirect in action at the official demo site: dev.wpchatbox.com. The demo shows the full customer journey from product selection on Site 1 through to payment confirmation, including the iFrame mode.

Merchants who have already experienced a payment account ban and need to resume selling immediately will find the recovery steps outlined in the guide on how to continue selling on WooCommerce after account suspension directly applicable to the CODARAB Redirect setup process.