Delivery address switch review
7/1/2026, 11:45:02 AM
Decision summary
If you see this, take these steps
Document merchant and rider controls that avoid exposing customers or riders.
Verify payments independently
Do not release goods or funds until you confirm inside your bank app.
Escalate suspicious requests
Use the official support channel instead of replying to the scam chat.
Report identifiers
Send handles, phone numbers, and payment links so TrustOps can corroborate.
Playbook sections
- What happened
- How it works
- Red flags
- What to do now
- Evidence / references
What happened
The scammer creates confusion between merchant, rider, and receiver, then extracts goods or money during a last-minute route change.
How it works
The pressure point is the moving rider. Fraudsters exploit weak address verification and real-time refund decisions.
Red flags
- The receiver changes address after dispatch.
- The rider is asked to pay a gate, security, or release fee.
- The buyer insists the merchant should refund before the rider returns.
What to do now
Freeze address changes after dispatch unless the merchant confirms through a known channel. Riders should call dispatch before paying any fee.
What not to do
Do not approve new addresses, refunds, or gate payments only through chat pressure.
Evidence notes
- Route screenshots, chat timestamps, and fee requests are useful after redaction.
Moderation brief
Document merchant and rider controls that avoid exposing customers or riders.
Forum status
Read-only curated thread
This public thread is a moderated briefing surface. Fresh evidence and supporting notes go through reviewed submission routes before TrustOps updates the public thread. Use reports for incident evidence, Ask TrustOps for questions, and fraud cards for card-specific deliberation.
Have more intelligence to add? Return to the forum index or review community rules.