Security model

Trust boundaries

Principal	Credential	Can
Your server	Secret live API key (gp_live_…), scoped — available once your account is activated	Use the merchant API for its organization and environment
Your team	Dashboard session (server-held HttpOnly cookie), role-based, MFA available	Manage the organization within their role
Your customer	Unguessable checkout session id	See a sanitised view of one payment and act on its checkout
Platform operators	Separate identity with mandatory MFA	Support and risk work; consequential actions (KYB decisions, manual resolutions, flags, live mode) need a second operator’s approval. An operator also reviews every payout
Chain watchers	Internal credential on an internal listener	Submit observations, which the gateway re-validates

The organization is always derived from the authenticated principal — never from a request body. Tenant isolation is enforced in queries and, as defence in depth, by database row-level security for the application role.

What we never ask for

• Private keys, seed phrases or wallet files.
• Card numbers or CVV (no card processing is offered; partner-hosted fields would be required).
• Your webhook signing secret after it has been shown to you.

Secrets and data at rest

• API keys and session tokens are stored only as keyed hashes; the full value is shown once.
• Webhook signing secrets, MFA seeds and wallet extended public keys are encrypted at rest; extended keys are never returned by the API (fingerprint only).
• Logs never contain Authorization headers, signing secrets or full personal data. Request logs record method, path, status, latency and the key prefix — not bodies.
• Customer data is minimised: an email and/or your reference, only if you send them.

Webhook egress (SSRF protection)

Endpoint URLs must be public HTTPS. At delivery time the destination address is checked when the connection is made, so DNS rebinding cannot point a hostname at an internal service. Private, loopback, link-local, carrier-grade NAT and metadata ranges are refused; redirects are reported, not followed; request and response sizes and timeouts are capped.

Integrity of financial records

• Payment state changes, chain allocations, ledger postings and audit events are append-only at the database level.
• Ledger entries must balance per currency or the transaction is rejected.
• The audit log is hash-chained per organization (GET /v1/audit-events returns chain_valid for the window).
• Operators cannot mark an external payment confirmed without documented evidence and a second operator’s approval; original events are preserved.

Live custody

Live payments are custodial and are enabled once your account is verified and approved. For an activated account:

• Received funds sit in the platform’s Bitcart wallets. Each organization’s balance is the sum of append-only ledger movements in integer base units, and an invoice can be credited only once.
• Bitcart callback bodies are never trusted: GRYPHEM PAY re-fetches the invoice or payout from Bitcart with the platform credential, and workers also poll.
• Payouts go only to allow-listed addresses that passed a format and checksum check and a cooling-off period. The amount is held when the payout is requested, a second member of the organization approves it (on by default), a GRYPHEM operator always reviews it, and Bitcart sends it from the platform’s hot wallet. A send is never retried automatically.
• GRYPHEM PAY itself stores no private keys or seed phrases: the keys of the platform’s wallets stay in its Bitcart account, which signs payouts.

Your responsibilities

• Keep secret keys and webhook secrets in a secret manager; rotate them on staff changes and suspected exposure.
• Verify webhook signatures over the raw body and dedupe on event_id.
• Fulfil only on fulfillable, re-checking with the API.
• Enforce MFA for team members with high-impact roles.

Reporting a vulnerability

Report suspected vulnerabilities through the contact form on the website (topic Security). Please include the request id of any affected call and avoid testing against other merchants’ data.