Security
Security & Controls
Signed on the way in, logged all the way through
None of this is a badge in a footer. Each item below is a check that runs in code, on a request that has already reached us.
HMAC-SHA256 signature
Every request carries an X-Signature derived from your merchant secret, compared in constant time.
Timestamps that expire
X-Timestamp is mandatory and old signatures are rejected, so a captured request cannot be replayed.
API key per account
X-API-Key identifies the account making the call, separately from the secret that signs it.
IP whitelisting
Restrict which addresses may act for an account — applied to the API and the portal.
Role permissions, down to the action
Roles are defined per organization, with menu access and CRUD set independently.
Audit trail, kept separately
Logins, permission changes and significant actions are recorded apart from the money ledger.
Company-level endpoints
Some surfaces are restricted to the company tier — enforced server-side, not by hiding a menu.
Login protection
Login attempts are rate-limited, sessions can be revoked, and login history is kept.
Two-factor authentication
Available on the portal for an extra check at sign-in.
Slip verification
Checked against real bank records, and its hash is stored so the same slip cannot be used twice. Not OCR.
When one provider stops, the payment does not
A gateway that runs one channel fails whenever that channel does. AdeePay scores its channels continuously and moves away from the ones that are struggling.
Money never goes missing
Three independent confirmation layers make sure payment status reaches you, even if a webhook fails.
Layer 1 — Signed webhook
Delivered and retried until your server answers HTTP 200.
Layer 2 — Query API
Read the payin by its id any time — the stored status is authoritative.
Layer 3 — Slip fallback
The customer's slip is a third path that never touches your server.