Security

Clear boundaries, written down.

Security in a payment system is mostly about saying precisely what the system does and does not do — and enforcing it in code. This page describes the boundaries GRYPHEM PAY is built around.

Custody model

Live payments are custodial: customers pay the platform’s wallets through GRYPHEM PAY’s Bitcart account, and each merchant’s balance is kept in an append-only ledger.
Live payments are enabled once an account is verified and approved; until then no funds are held for it.
Payouts go only to allow-listed addresses after a cooling-off period. By default a second team member approves each one, a GRYPHEM operator always reviews it, and Bitcart sends it from the platform’s hot wallets.
No private keys or seed phrases in GRYPHEM PAY’s databases, logs, fixtures, screenshots or CI. The keys of the platform’s wallets stay in the platform’s Bitcart account, which signs payouts.
Extended public keys and wallet descriptors are never returned by the public API.

Keys and secrets

API keys are shown once, stored as HMAC hashes with a server-side pepper, scoped per environment and revocable.
Webhook signing secrets and MFA seeds are encrypted at rest (AES-GCM) and never written to logs.
Authorization headers, secrets and full personal data are excluded from logging by design.

Tenant isolation

The tenant is always resolved from the authenticated principal, never from the request body.
Defence in depth: tenant-scoped queries, database constraints and row-level security policies.
Cross-tenant access tests cover every merchant object.

Webhook delivery

HMAC-SHA256 signatures over timestamp and raw body, with a bounded replay window.
SSRF protection at dial time: DNS and IP checks, no private, link-local or metadata ranges, no redirects.
Bounded timeouts and payload sizes; every attempt is logged without secrets.

Operator access

Operators use a separate identity system with mandatory multi-factor authentication.
High-impact actions such as KYB decisions, manual resolutions, feature flags and live mode require a second operator’s approval (four-eyes) and leave immutable audit evidence.
No operator can mark an external payment confirmed without documented evidence and dual approval.

Release gates

Production fund movement and live networks are switched off by default.
Enabling them requires every release gate to be approved by two operators: independent security review, threat-model sign-off, incident runbooks, disaster-recovery drills and legal approval.
Because live mode is custodial, one legal gate requires authorisation to hold and transfer customers’ crypto-assets for every launch country and legal entity, or counsel’s written opinion that none is required.
Contracts used on-chain, if any, require a separate audit before mainnet use.

Honesty

What we do not claim.

Reporting

Found something? Tell us.

Report vulnerabilities through the contact form with the topic “Security report”. Describe the impact; we reply with a secure channel before you share exploit details. Please do not test against other merchants’ data.

Report an issue System status