White Label
Automate High-Risk Onboarding: Streamline Risky Processes
Learn the best practices to automate high-risk onboarding, reduce security risks, and ensure a smooth, compliant onboarding experience.
-
Solutions
European BanksWhite-label payment infrastructure for acquiring banks
Low-Risk PSPsWhite-label payment gateway for low-risk PSPs
iGaming & Forex PSPsBuilt for high-risk PSPs — full control over your channels
-
Resources
Set up your payment processing system
Platform capability 01
Referer Control: know where your payment traffic actually comes from
Most PSPs trust what merchants declare. eComCharge checks what actually arrives.
Referer ControlDeclared domainsRules
live
Incoming transaction
Referer check
casino-a-bonus.net€85.00 · DE
lucky-spins.io€300.00 · PL
Rules — evaluated in order
- In declared listProcess
- Mirror patternFlag for review
- UndeclaredAlert PSP
Action
Processed
Referer matches a declared domain
Flagged for review
Tagged for the compliance team
Alert sent
PSP and account manager notified
Checking the referring domain…
What you can do
AlertFlag & tagBlockRoute elsewhere
Captured at checkout
The browser records where the customer came from · available in Smart Routing rules in real time
Feature
Smart Routing
The gap most platforms miss
Standard approachPSP trusts what the merchant declares at onboarding — no way to verify actual traffic sources at the transaction level
With Referer ControlEvery transaction carries the referring domain — visible in Smart Routing rules, actionable in real time
Why this matters
One declared domain. Several real ones.
Payment processing starts before the transaction is submitted. When a customer opens a checkout page, the browser records where they came from — the domain that sent them there. The platform captures this data and makes it available inside Smart Routing rules, so PSPs and banks can verify, in real time, whether incoming transactions originate from the domains their merchants actually declared — and act on any mismatch automatically.
Undisclosed storefronts
A merchant registers one domain
In practice they may run several subdomains, mirror sites, or parallel storefronts — some of which were never disclosed.
Not always fraud
Regional versions nobody registered
A merchant might expand to regional versions of their site without thinking to update their registration. But in some cases, undisclosed domains route traffic that would not pass a compliance check — grey-market products, unlicensed services, mirror sites designed to look identical to the registered one.
No visibility
The mismatch surfaces at the audit
Without referer tracking, neither the PSP nor the bank sees this. Transactions arrive and get processed — the mismatch only surfaces during an audit, or when an acquirer raises a question.
With referer tracking enabled in Smart Routing, the mismatch surfaces at the transaction level — immediately.
How it works
Captured at checkout, compared in real time
When a customer arrives at the payment page, the platform captures the referring domain. Smart Routing then compares this against the domains registered for that merchant in the system.
Step 1
Customer opens checkout
Browser records the referring domain — where the customer came from
Step 2
Platform captures domain
Referring domain recorded at the transaction level — available in Smart Routing
Step 3
Compared to declared domains
Smart Routing checks whether the domain matches what the merchant registered
Step 4
Rule triggered
Mismatch detected → configured action fires automatically
What you can do
Four responses, configured per merchant
Rules and alerts are configured by the eComCharge team based on the PSP’s or bank’s compliance requirements.
Alert
Notify — don’t block
PSP and account manager are notified when a transaction arrives from an unregistered domain. Transaction is processed, but the team is informed.
Flag
Process and tag for review
Transaction is processed normally but tagged in the system for compliance review. Useful when you need visibility without blocking legitimate traffic.
Block
Reject from specific domains
Transactions from specific unregistered domains are rejected at the routing layer. No manual intervention needed per transaction.
Monitor
Track volume by domain
Volume tracked per domain over time — patterns of undeclared traffic surface gradually, enabling proactive merchant conversations.
A real example
Three domains nobody declared
1Declared domainRegistered at onboarding
+3Undeclared variantsSubdomains and regional versions found in traffic
0BlockedVisibility first, a conversation with the merchant second
During traffic analysis on the platform, a pattern emerged: a merchant registered under one domain was generating transactions from three additional subdomains and regional variants of their site — none of which had been declared. The merchant was not blocked. But the PSP now had visibility they didn’t have before — and could have a conversation with the merchant about their actual traffic setup. That visibility is what Referer Control provides.
Who uses this and how
Banks, PSPs and compliance teams
Banks
Portfolio-wide merchant monitoring
When a merchant is onboarded, their declared domains are registered in the system. If transactions start arriving from domains outside that declaration, the bank receives an alert.
PSPs
Transparency with acquiring partners
Acquirers increasingly ask whether PSPs have any mechanism to validate traffic sources. Referer Control provides a concrete, demonstrable answer.
Compliance teams
One more signal in merchant reviews
The data supports merchant reviews — not as a standalone audit tool, but as an additional signal alongside transaction data.
How PSPs use this in practice
- Portfolio monitoring
- PSPs with large merchant portfolios run periodic checks — identifying merchants whose actual traffic sources don’t match what was declared at onboarding.
- Acquirer due diligence
- When applying for new acquiring relationships, PSPs use Referer Control data to demonstrate domain-level visibility into their merchants’ traffic — a question acquirers increasingly ask.
- Incident response
- When a merchant account is flagged by an acquirer or compliance team, Referer Control gives the PSP a documented transaction-level trail to present in their defence.
- Ongoing verification
- New merchants are monitored for the first 30–90 days to confirm that traffic comes from declared domains before risk limits are raised.
When to enable Referer Control
- Banks onboarding e-commerce merchants who process across multiple storefronts
- PSPs whose acquiring partners require traffic source transparency
- Any platform where merchant domain compliance is part of the onboarding agreement
- Situations where grey-market or mirror-site activity is a known risk in the vertical
Important note. Referer data is captured from browser sessions and reflects the domain visible at the point of checkout. It is not a fraud prevention system and can be circumvented by technically sophisticated actors. Its primary value is transparency and early detection of undeclared traffic sources — not blocking determined fraud.
Referer Control — FAQ
No. Referer Control works at the platform level. Merchants don't need to integrate or configure anything. You see the data. You decide what to do with it.
Yes. Rules are configured at the merchant or shop level. One merchant can be set to Alert, another to Block — depending on their risk profile and your relationship with their acquirer.
You can whitelist known domains per merchant. Referer Control only flags domains that aren't in the declared list — so legitimate multi-domain merchants won't generate false alerts once their domains are registered.
Referer Control captures the referring domain from the browser at checkout. It applies to card payments processed through the eComCharge checkout — where the browser initiates the session.