Payment Security and Risk Control
The "Payment Security" group covers payment-domain security only: replay protection for the open payment APIs, and IP-level risk interception before payment. Account password policies, login security and two-factor auth belong to the system-domain "System Security Config" (System Management → System Config) — the two are separate, don't mix them up. Menu: Payment Management → Payment Security.
Defense Line Overview
The open-source defense line has two parts, spread over four pages:
| Page | Role |
|---|---|
| API Security Config | Replay protection parameters for open APIs (signature verification is always on and is not toggled here) |
| Risk Strategy | Master switch and per-dimension switches of IP-level risk control; block or record-only on hit |
| Blacklist Management | Manually maintained IP / province / city blacklists |
| Risk Hit Records | Read-only ledger of risk hits, for observation and troubleshooting |
The relationship: strategy and blacklists are the cause, hit records are the effect. A hit never becomes a blacklist entry automatically (no auto-blacklisting in the open-source edition) — handling means manually adding entries in blacklist management.
API Security Config
Signature verification of open payment APIs is always enabled (see Signature); this page configures two extra replay defenses:
| Setting | Default | Effect |
|---|---|---|
| Nonce verification | Off | Each request's random string can be consumed only once within its TTL; repeated submissions are rejected |
| Request time window | Off | Rejects requests whose timestamp deviates from server time beyond the tolerance (blocks stale and future-dated requests) |
| Time window tolerance | 300 s | Maximum allowed deviation, both directions |
| Nonce TTL | 300 s | How long a nonce is remembered for deduplication |
Once enabled, merchant requests must carry a nonce and a request time. With both switches off, requests pass through. Applies only to the open payment APIs, not to admin pages.
Risk Strategy
The open-source edition provides IP-level risk control. Switches on the strategy page:
| Switch | Default | Effect |
|---|---|---|
| Risk master switch | On | Off skips all risk checks and produces no hit records; other switches grey out |
| Blacklist blocking | On | Exact-match against the IP blacklist |
| Overseas IP blocking | Off | Blocks payments initiated from outside mainland China |
| Region blocking | Off | Matches IP-resolved province/city blacklists (a province hit skips the city check) |
| IPv6 region matching | Off | Makes province/city/overseas checks apply to IPv6; when off, IPv6 passes through. Offline IP data has limited accuracy — enable with care |
| Block on hit | On | On = reject the order when any enabled rule hits; Off = record the hit only, payment proceeds (good for the observation period) |
Record-only mode
When rolling out risk control, first turn "Block on hit" off: hits are still logged for observation while payments flow; turn blocking on after confirming there are no false positives.
Blacklist Management
Three blacklist types, all manually maintained:
| Type | Value | Notes |
|---|---|---|
| IP | A specific IP | Exact match, no CIDR ranges; platform-wide, not per merchant/app |
| Province | Region (dropdown) | Matches the IP's resolved province |
| City | City (province→city cascade) | Municipalities have no separate city level — pick the province |
Form fields: type (locked after creation), value, status (enabled/disabled), reason, expiry (empty = permanent; expired entries auto-invalidate), remark. Values cannot repeat within a type.
A blacklist entry alone does not block
The list is just data — blocking also needs the switches: IP lists require "Blacklist blocking", province/city lists require "Region blocking", and the master switch must be on. If a newly added entry has no effect, check the strategy page first.
Risk Hit Records
The hit ledger is read-only, recording each hit's: phase (pre-pay only in this edition), hit type (IP / overseas IP / province / city), hit value, IP city, trade number, merchant and time; the detail view adds app, order number, payment method and more.
The page has no allow/block actions. The operational loop: observe suspicious sources in hit records → add the corresponding IP or province/city in blacklist management → confirm the matching switches are on in risk strategy.
What Happens on a Hit
- Risk checks run at order time (covering normal payments, gateway payments and QR-code payments; refunds and transfers do not pass through risk control);
- Hit with "Block on hit" on: the order is rejected and never created; the merchant side receives a uniform "transaction restricted" message (deliberately vague to prevent probing);
- Hit with blocking off: the payment proceeds and only a hit record is left;
- Undecidable cases (intranet addresses, unresolvable IPs) are allowed through — expected behavior.
FAQ
A merchant reports "transaction restricted" — how to investigate? In order: check hit records for the trade → if found, note the hit type and value → check blacklist management for a false entry (e.g. an entire province added by mistake) → decide whether the block is intended.
Why didn't my blacklist entry block anything? Check in order: master switch on → the dimension switch on (IP → blacklist blocking; province/city → region blocking) → the entry enabled and not expired → the requester's IP exactly matches the entry.
All IPv6 requests pass through? That's the default. Enable "IPv6 region matching" to cover IPv6 — note the offline IP database has limited IPv6 accuracy and may misjudge.
Related Links
- Signature — the always-on signature verification of open APIs
- Configuration — deployment settings