Deposit spam doesn't take your money. It takes your payment provider.
On P2P rails a player takes requisites from your provider's pool and pays from their own bank app. A flood of automated orders takes those requisites and never pays — real players find nothing to pay to, and your provider reprices you.
Does this sound like you?
If even a couple of these feel familiar, it’s probably already happening on your platform.
Your created-to-paid deposit conversion keeps sliding, even though real players haven't changed.
What it means: Orders are being created far faster than anyone could ever pay them — and that ratio is what your provider grades you on.
Your payment provider has started sending warnings: higher fees, a rolling reserve, tighter limits, questions about your conversion.
What it means: The provider prices your traffic by what it costs them to carry. Someone else's attack has become your rate card.
Deposit orders arrive in waves — hours of quiet, then thousands of unpaid ones in a burst.
What it means: That rhythm is a script working through your deposit form, not players deciding to top up all at once.
Real players write to support saying the deposit page gives them no requisites, or the same ones twice.
What it means: The pool your provider issues you is being held by orders nobody intends to pay.
How the attack actually works
No security background needed — here’s the whole play, start to finish.
The pool
Your provider issues you a finite pool of requisites — cards, phone numbers, wallets. A player takes a set, pays from their own bank app, and the provider matches the transfer. You're graded on how many created orders get paid.
The flood
A script creates order after order from many genuinely different devices, taking a set of requisites each time and never paying. Nobody is depositing to play. The pool empties, and real players find nothing to pay to.
The fallout
Your created-to-paid ratio collapses. To your payment provider you now look like the problem: higher fees, rolling reserves, holds — and eventually the threat of losing the relationship itself.
How SignalGate stops it
One call on your critical path. The verdict comes back before anything happens.
Campaign-scale detection
Sees thousands of unpaid orders from thousands of genuinely different devices as what they are — one coordinated operation — instead of a bad week on the deposit form.
Behavioral anomaly detection
Learns what a genuine player looks like on your own traffic. A script creating orders it never intends to pay moves nothing like a player funding an account.
Pre-provider verdict
Once you turn blocking on, the verdict lands before the order ever reaches your payment provider. Blocked orders never touch your created-to-paid conversion — the exact number the attack was burying.
Fingerprinting catches one device pretending to be many. SignalGate catches the opposite — many genuinely different devices working as one operation — the fraud that device fingerprinting alone was never built to see.
Wire it in, in minutes
Start with two fire-and-forget calls to /v0/log — log the action and the target action. No blocking, no user impact, nothing on your critical path.
Log deposit attempts and successful deposits
from datetime import datetime, timezone
from signalgate import Client, Event, EncryptedPayload
client = Client(api_key="pk_live_...")
def sg_event(body: dict, method: str) -> Event:
# Each request carries its OWN "signalgate" envelope from the browser SDK
return Event(
user_id=body["user_id"],
ip=request.headers.get("X-Forwarded-For", request.remote_addr),
method=method,
timestamp=datetime.now(timezone.utc).isoformat(),
payload=EncryptedPayload(**body["signalgate"]),
)
@app.post("/api/deposit")
def deposit_attempt():
body = request.get_json()
# Funnel point 1 — the order was created and a set of requisites
# (card / phone / wallet) was issued from the provider pool.
client.log(sg_event(body, method="deposit.attempt")) # AFTER the order is created
return {"ok": True}
@app.post("/api/deposit/confirmed")
def deposit_succeeded():
body = request.get_json()
# Funnel point 2 — the incoming transfer was matched to that order and the
# player was credited. This is the half of the ratio the attack kills.
client.log(sg_event(body, method="deposit.succeeded")) # its own fresh envelope
return {"ok": True}Within days the dashboard shows how much of your traffic is one coordinated operation — before you turn on blocking.
Stop fraud before it reaches your backend.
Free for everyone through 2026. Two lines of code. No demo required.