Core Concepts
IP Allowlist
An IP allowlist on the s2s surface layers on top of HMAC — blocked source IPs get 403 IP_NOT_ALLOWED
UnknownPay has an IP allowlist separated by surface, where the surface for the S2S API is "s2s" (the other surface is "dashboard" for the portal).
Who sets it
Managing the allowlist is the responsibility of the platform team (System) only — in the current phase merchants cannot set it themselves (no self-service). So a merchant must report the IP/CIDR they will use to call S2S to the UnknownPay team for the team to add (see the IP-report steps in Portal Preparation → IP allowlist).
Pending confirmation — the real channel a merchant uses to send their IP to the team (email / form / account-manager contact)
Meaning of the enabled status
The enabled status of the s2s surface behaves as follows (behavior from the real code):
Status of surface s2s | Effect on the merchant's request |
|---|---|
enabled = false (or not yet configured) | All IPs pass — the allowlist is not enforced (fail-open) |
enabled = true + empty IP list | All IPs blocked (enabled but no allowed IP = nobody passes) |
enabled = true + non-empty IP list | Only IPs within the configured CIDR ranges pass |
- When the allowlist is on and blocks a request, it responds with
403codeIP_NOT_ALLOWED("source ip not allowed"), with no effect on the ledger/transaction — it is a block at the auth layer, before reaching the money handler. - Turning the allowlist on adds a layer of protection on top of HMAC (a request must pass both a valid signature and an allowed IP).
- Entries are stored as CIDR (a single IP is stored as
/32or/128) —/0(allow-all) is forbidden; the system rejects it. If you want to "allow all IPs", disable the surface instead. - After the allowlist is edited there may be a short delay (cache ~30 seconds) before it takes effect on every instance.
Turning the allowlist on with an empty IP list blocks all traffic. And
/0 is forbidden — to allow all IPs, disable the surface; do not try to use /0.Example error when an IP is blocked:
{
"error": {
"code": "IP_NOT_ALLOWED",
"message": "source ip not allowed",
"request_id": "..."
}
}
Diagram coming soon — sequence diagram — merchant request → HMAC check (X-Api-Key/X-Signature/X-Timestamp) → replay window ±300s check → IP allowlist (s2s) check → money handler
Pending confirmation — if self-service for merchants to manage IPs via the portal is enabled in the future, update this section
