No. Global-e is the Merchant of Record and therefore takes full fraud liability. Fraud prevention is part of Global-e's overall solution and cannot be removed. More importantly - Global-e operates one of the most advanced fraud prevention processes in cross-border e-commerce, combining top industry tools with the knowhow of a fully managed in-house fraud analyst team. This is significantly more effective than any merchant managing fraud independently, and it is one of the key advantages of the Global-e solution.
Merchants working with Global-e have zero fraud risk on cross-border orders. Global-e is fully covering all fraud chargebacks reported as fraudulent chargeback codes through the payment provider - this is not an independent interpretation, but follows the code reported by the payment service provider. Note that any service chargeback or other service/product-related chargebacks (e.g., item not as described, delivery dispute, subscription dispute) are NOT considered fraud chargebacks and are not covered by Global-e.
Global-e acts as the Merchant of Record for any order that goes through the Global-e checkout, as determined by the operated countries setup. As the MoR, Global-e handles the direct relationship with the Payment Service Providers, is liable for fraud chargebacks, and manages the full lifecycle of transaction processing. The merchant's brand is preserved in the customer experience, but the legal and financial counterparty to the end customer is Global-e.
Global-e operates a best-in-class fraud prevention process that combines top industry tools with the deep knowhow of a fully managed in-house fraud analyst team. Our multi-layered approach includes automated risk scoring, continuous model tuning, and dedicated expert manual review - giving merchants a level of protection that is not achievable independently. Signals are aggregated across ALL merchants on Global-e's platform, so cross-brand history is factored into every decision.
If a card is reported stolen to its issuing bank, that signal reaches Global-e. All orders attempting to use that card are cancelled and we cannot approve future orders from that customer using the same card or related identifiers. If the customer insists the card is theirs, they must contact their issuing bank directly to clear the fraud report - Global-e cannot override a bank-confirmed stolen-card flag.
Three common causes:
Network-level fraud history at other merchants on our platform.
Bank-confirmed stolen card overriding customer's belief.
Merchant policy rule (velocity), not a fraud-score decision.
The fraud team will share the specific reason internally, and the customer should not be told specifics.
A spike can be a fraud campaign or bot attack targeting that geography, a payment-related issue, a model recalibration, or a merchant promotion. If you're also seeing a drop in payment success rates, the issue should go to the payments team first. Otherwise, escalate via the CSM for analyst review.
Yes. If the merchant has valid information that the customer is fraudulent, they can share it with their CSM who will pass it to the Global-e fraud team. The fraud team will add negative feedback for the user in our fraud engine and future orders by that user should be rejected. Include if possible: customer email/ID, order numbers involved, reason for the block, and supporting evidence.
Yes. The CSM should send a request to [email protected]. The fraud team will check for any known risk ratings and if the customer/IP can be unblocked, will add this to our fraud engine. Note: our fraud engine is AI-based, so updates can take a few days to propagate after approval.
The request should explain why the merchant believes the customer should be re-evaluated - positive history, a direct/known relationship, etc. - preferably with more than 6 months of history, since older claims carry lower risk. Include: customer email / ID / IP to unblock, reason for the request, whether one-time release or ongoing allowlist, and any context contradicting the fraud signal. Global-e has cross-merchant visibility - the justification helps weigh the trade-off.
No. The fraud engine cannot block or allowlist a specific payment method for an individual customer. We can: block a customer entirely, unblock from blocklist, maintain a global blocklist at the catalogue level. Payment-method preferences for risk reasons are a configuration discussion with the CSM, not a fraud-team request.
After approval, the change is added to our fraud engine immediately, but because the engine is AI-based, it can take a few days for the updated signal to fully propagate. Recommend the customer wait 48-72 hours after notification before retrying.
Yes. CSM emails [email protected] with IP address, business justification, and merchant ID. Caveat: IP allowlisting only reduces the IP-based signal - if an order shows other strong fraud indicators, it can still be cancelled.
Yes, with 1–2 weeks planning. Fraud team needs: event dates/hours, eligible SKUs, coupon/promo code, IP address or range used at venue, staff device details, venue address. Caveat: without a strong technical identifier, the fraud team cannot guarantee automatic approval - orders are still risk-assessed individually.
Yes. Report setup is handled through the BI team, with the fraud team CC'd on the request. Contact [email protected] via the CSM. Options: weekly (Mondays at 22:05 UTC) or daily (each morning). The report is a fixed format and includes: order numbers, cancellation timestamps, and reason categories. Custom report formats are not available - the report content is standardised to ensure consistency.
Merchants can view Canceled orders directly in the merchant portal. Additionally: review the fraud cancellation report (if subscribed), or contact CSM for an ad-hoc pull or report setup.
No. Per-order email notifications aren't scalable. Order status is visible to the merchant directly on the portal. Other options: automated daily/weekly fraud report, ad-hoc lookups via CSM, or the order-status webhook feed. Note: in sensitive cases (e.g. high-value orders or VIP customers), the fraud team may proactively reach out to the CSM by email.
Fraud KPIs are available in Global-e's BI/Insights platform. Standard metrics include: Fraud Approval Rate, Fraud Rejection Rate, Fraud Team Approval Rate, and Fraud Savings (orders saved by manual review). CSM can pull on request. We are also exploring adding these metrics directly to the merchant admin portal under Analytics (via BI).
There is no single "normal" rate - it depends heavily on the merchant's product category, target markets, average order value, geography, whether the catalogue includes rare/limited-edition items, social media trends and activity around the merchant's products, and sale periods or discount campaigns. What matters is that Global-e's fraud prevention process is designed to maximise approvals while minimising fraud exposure - continuously optimised by our in-house team. If a merchant is concerned about their rejection rate, the CSM can request a fraud analyst review of their specific profile.
Customers receive an automated email notification when their order is cancelled for fraud risk.
Non-Shopify email: "Dear [customer name], Your order has been cancelled because we are unable to verify your information. Please note that any amount debited to us will be refunded."
Shopify email: "Dear [customer name], Your order has been cancelled."
The message intentionally does not reveal the fraud check.
The fraud team shares as much context as it can with merchant/CS/CSM, but not the specific signals or detection methods behind a decision - and this should not be passed on to the customer either.
Security: revealing how detection works would let fraudsters adjust their behaviour to get around it.
Liability: sharing signals with a potentially fraudulent customer exposes Global-e and the merchant to social-engineering attempts.
Try a different payment method (Apple/Google Pay, Alipay), try from a different network if on VPN/hotspot, wait 24h before retrying (resets velocity rules), ensure billing address exactly matches card issuer. If retries still fail, cancellation is likely network-level or bank-confirmed - escalate to CSM.
No. Most cancellations are routine. Standard customer guidance resolves the majority of legitimate cases. Escalate only when: long-history customer is repeatedly cancelled, VIP needs urgent assistance, customer's bank has reported confirmed fraud, unusual pattern (volume spike, single geography, single product), customer has tried 3+ times with different payment methods.
For Shopify merchants on Global-e for cross-border: Global-e is MoR on the cross-border order and does the fraud check. Shopify's own fraud signals (Shopify Fraud Protect, Shop Pay) are NOT applied to Global-e orders - they apply only to Shopify's direct (domestic) flow. Cancellation messages are abbreviated because Shopify envelope handles the rest. A customer cancelled at Global-e layer who passed Shopify's checks is expected behaviour.
The SLA for fraud escalation tickets depends on volume and urgency. If something is genuinely urgent, flag it to the fraud team directly ([email protected]) so it can be prioritized accordingly.
The fraud team cannot adjust a country's customs laws or thresholds. What we can do is exclude a specific merchant from the threshold - only with a formal agreement between the CSM, CS and the merchant, and only after the merchant understands the implications (including impact on fulfillment liability). The CSM opens a ticket with merchant ID, country and business justification.
Question / cue |
Goes to section |
|---|---|
Are we covered for chargebacks? |
1 - How Global-e fraud works |
Why was THIS specific order cancelled? |
2 - Why orders get cancelled |
Stolen card / bank report |
2 + 3 - bank-reported |
How do I block/unblock a customer? |
3 - Blocking and unblocking |
Pre-event / VIP exception |
3 - Event exception |
Can we send a fraud report? |
4 - Reporting and visibility |
What does the customer see? |
5 - Customer communication |
How does Shopify integration work? |
6 - Operational process |
Country threshold question |
7 - Edge cases |