Credential stuffing defence,
merchant protection & payment fraud prevention
The device fingerprint is the constant — whether the attack is a bot on your login endpoint, a takeover of a merchant settlement account, or a compromised payer session.
Trusted by forward-thinking teams
Overview
Payment platforms sit at the infrastructure layer — every fraudulent transaction, compromised merchant account, and stolen credential has consequences across every business and end user connected to the platform.
Fraud operates on two levels: attacks on your authentication layer — credential stuffing, account takeover, session hijacking — and attacks that flow through the platform against merchants and payers who trust you to protect their transactions.
Keverd addresses both through device-level intelligence. The fingerprint connects stuffing bots, merchant settlement redirects, and compromised payer devices — even when the IP changes on every request.
The problem
What payment platform fraud looks like
Credential stuffing
Leaked email/password lists tested at high volume against your login endpoint. IP rate limits fail — residential proxies give a fresh IP per request. Each attempt looks legitimate; volume is distributed. The same device across 500 IPs is still one device.
Merchant account takeover
Compromised merchant credentials → login from a new device → settlement bank details changed → next payout goes to the attacker. Keverd catches step two before any sensitive action completes.
Fraudulent merchant onboarding
Fake businesses self-register to access processing, run fraudulent volume, and exit. Same device registering multiple merchants — or a device flagged elsewhere attempting a fresh signup — surfaces at onboarding.
Payment injection via automation
Scripts submit fraudulent payment requests with stolen keys or tokens. BOT and AUTOMATION flags fire on timing and interaction patterns — regardless of how valid the credentials look.
SIM swap & mobile money
Attacker takes control of a linked phone number, intercepts OTPs, authorises transactions. Device fingerprint and number relationship no longer match — alert before the transaction completes.
Slow payer account compromise
Small transactions over days stay under velocity rules. The device changed at the first session — Keverd flags new devices on existing accounts immediately, not after the pattern builds.
Intelligent rate limiting
Device-level limits — not IP-based
IP rate limiting fails when attackers rotate through residential proxies — a fresh IP every request, threshold never crossed. Keverd counts attempts per device across all IPs. Five hundred IPs, one device: blocked after attempt 10.
- Request arrives at the login endpoint
- Keverd identifies the device fingerprint from session signals
- Checks how many login attempts this device made in the past N minutes — any IP
- Threshold exceeded → blocked before credential validation runs
Start at 10–15 attempts per device per hour. A real user makes 3–5 tries before forgot-password; a stuffing script makes hundreds. Tune after 48 hours of live data.
How Keverd solves it
Five layers across payment touchpoints
Login, merchant, onboarding, payment, and OTP — Keverd captures:
- Device fingerprint on login — attempt history across all IPs
- Merchant dashboard continuity — new device on sensitive actions
- Onboarding fingerprint — same device registering multiple merchants
- Payment initiation — BOT, AUTOMATION, and session timing
- OTP and mobile money flows — device continuity vs. account history
- Payer session history — new device on long-established accounts
Intelligent rate limiting
Block login attempts at the device level, not the IP. One device across 500 rotating IPs still hits your threshold — stuffing bots never learn which credentials are valid.
Merchant account protection
Flag new devices on merchant logins and before bank changes, API key rotation, withdrawals, or settlement updates — before revenue is redirected.
Merchant onboarding
Fingerprint at registration. Previously flagged devices or repeat merchant signups from one cluster → hold for review before KYC completes.
Payment initiation
Score web and mobile payment sessions. BOT and AUTOMATION blocked before the transaction payload reaches your processor.
Mobile money & OTP
Continuity check at OTP entry — device should match the account’s established relationship. SIM swap breaks surface before authorisation completes.
Integration
Five touchpoints — login first
Prioritise the login endpoint for day-one value. For platforms with consumer login and merchant dashboards, all five touchpoints deploy from one script installation with per-touchpoint config.
Login endpoint
- Placement
- Login page
- Trigger
- Login form submission
- Response
- device_id, attempt_count_in_window, suspect_score, risk_tier, action_taken
Block fires before authentication — attackers get no feedback on which credentials are valid.
Merchant dashboard
- Placement
- Merchant login + sensitive actions
- Trigger
- Login, bank change, API key rotation, withdrawal, settlement update
- Response
- device continuity flag, is_new_device, risk_tier, action_taken
New device on any sensitive action → hold pending verification.
Merchant registration
- Placement
- Merchant registration form
- Trigger
- Registration submission
- Response
- device_id, previous_merchant_count, flag_history, risk_tier, action_taken
Runs before onboarding completes — flagged devices held before KYC documents are requested.
Payment initiation
- Placement
- Payment or checkout flow
- Trigger
- Payment form submission
- Response
- suspect_score, flags[], risk_tier, action_taken
Automated payment injection blocked before the processor sees the payload.
Mobile money / OTP
- Placement
- OTP entry and mobile money authorisation
- Trigger
- OTP submission
- Response
- device continuity flag, sim_swap_risk, risk_tier, action_taken
Critical for payroll disbursement flows — hold before a salary batch is redirected.
Workflow
Credential stuffing attack
- 1
Attacker
Runs a script testing leaked credentials against your login endpoint, rotating IPs on every request.
- 2
Keverd
Fingerprints the device on each attempt. Counts attempts per device across all IPs in the time window.
- 3
Your platform
After the device threshold (e.g. 10–15/hour), requests are rejected before credential validation runs.
- 4
Outcome
Stuffing bot never learns which passwords work. Legitimate users who mistype a few times stay under the threshold.
Merchant account takeover
- 1
Attacker
Obtains merchant credentials and logs in from a new device.
- 2
Keverd
Flags new device — no continuity with the merchant’s known device history.
- 3
Your platform
Bank detail change, withdrawal, or API key action held until verification completes.
- 4
Merchant
Revenue and settlement accounts protected before funds move to an attacker.
Field guide
Reading Keverd flags on payment flows
| Flag | What it means | How to use it |
|---|---|---|
| BOT | Session behaviour matches non-human patterns. | Block at login and payment initiation. Pair with AUTOMATION on stuffing flows. |
| AUTOMATION | Interaction timing inconsistent with human use. | Strong signal on login stuffing and payment injection. Block before auth or settlement. |
| USER_AGENT_SPOOFED | Device misrepresents browser or OS. | Common on scripted stacks. Review or block at login. |
| TIMEZONE_IP_MISMATCH | Timezone does not match IP location. | Context only with residential proxies. Do not block on this flag alone. |
| AD_BLOCKER | Ad blocker detected on device. | Informational for payment flows. Do not weight heavily in login risk scoring. |
First 30 days
What success looks like
- Day 1credential stuffing block count visible on dashboard — often higher than teams expect
- 100%of login attempts receive a device fingerprint
- 48hrate-limit thresholds calibrated from live legitimate retry behaviour
- Week 2merchant device baselines building — new-device alerts refining
- Day 30attack pattern report and threshold review with Keverd
The most visible metric on day one: credential stuffing block count. Teams often had no prior visibility into automated login volume — that number anchors the 30-day review.
Default configuration
Tuned for payment platforms
| Device rate limit | 10–15 login attempts per device per hour | Starting point — tune after 48h of live data |
| Login block | Before authentication runs | No credential validity feedback to attackers |
| Merchant new device | Verification on bank, API key, withdrawal, settlement | Sensitive action list confirmed at onboarding |
| AD_BLOCKER | Ignored in login score | Low correlation with stuffing attacks |
Security & sales
Starting the conversation
Practical openers for platform security teams and partnership conversations.
The opening question
How many automated login attempts hit your platform in a typical day — and how many do you currently block? Most teams either don’t know, or know it’s high with no way to act. Either answer opens the device-level conversation.
Payroll & disbursement
For platforms running salary batches: what happens if someone takes over a payroll admin account the night before a run? Device continuity at OTP can hold the batch before employee payments are redirected.
Beyond IP rate limits
IP-based defences are bypassed by rotating residential proxies. Device-level rate limiting closes that gap — the fingerprint persists when the IP changes.
48-hour passive scan
Offer a short passive scan on the login endpoint and bring real findings to a follow-up. Live data on stuffing volume is more persuasive than any pitch — and costs the prospect nothing to try.
Onboarding
5–7 working days — login endpoint first
- 01Share login, merchant dashboard, registration, and payment initiation URLs
- 02Add Keverd JavaScript snippet to each touchpoint page
- 03Configure webhook and authentication token on your backend
- 04Agree intelligent rate limiting: device attempt limit, time window, block duration
- 05Establish merchant device baselines for known-good devices
- 06Confirm sensitive dashboard actions requiring continuity checks
- 07Activate mobile money / OTP touchpoint if applicable
- 08Test run: simulate credential stuffing with known test devices
- 09Brief security team using workflows and field guide below
- 10Go live — Keverd monitors first 48 hours and delivers day-two attack pattern report
Known limitations
Interpret signals correctly
- Keverd operates at the device and session layer — not transaction amounts, merchant category, or AML pattern analysis. Complements transaction monitoring; does not replace it.
- Truly distributed device farms — one physical device per attempt — are costlier and less common in this market. Fingerprinting is less effective there.
- Merchant device baselines take 2–4 weeks on new platforms. Legitimate merchants may see more step-up verification until known devices are learned.
- Does not replace KYC or AML for merchant onboarding — an additional fraud signal before compliance review.
- App-only login flows with no web surface may need native SDK integration — scope during technical onboarding.
- Intelligent rate limiting is the fastest proof of value: stuffing block count in the first 48 hours anchors the 30-day review.