Skip to content
GRYPHEM PAYGRYPHEM PAYGRYPHEM PAY Docs

Introduction

GRYPHEM PAY is a multi-tenant payment gateway API for merchants: e-commerce stores, SaaS products, API businesses and platforms. You create payment intents (or invoices and payment links), send customers to a hosted checkout, and receive signed webhooks as the payment moves through a strictly defined state machine. Finance teams reconcile against processor evidence, reports and an append-only timeline.

Account activation

Section titled “Account activation”

Every API key is a live key and every payment is real. Live payments are enabled once your account is verified and approved: you sign up, set up your organization and submit your business verification, GRYPHEM reviews it, and live API keys, payments and payouts become available once your account is activated.

Activation is decided by GRYPHEM. Besides an approved business verification, it depends on the platform’s own release requirements, including the authorisations described in Regulatory status, so an approved verification does not by itself activate an account.

Capability Status
Sign-up, email verification, organizations, stores, team invitations Available
Business verification (KYB merchant application) Available — reviewed manually by GRYPHEM operators; submitting it is not an approval
Support tickets Available
Webhook endpoints Can be registered. Endpoints belong to one environment and live events go only to live endpoints, so register yours once your account is activated
Live API keys (gp_live_…) Available once your account is activated; refused before that with live_keys_disabled
Payment intents, hosted checkout, invoices and payment links Once your account is activated
Custodial balances and payouts Once your account is activated; payouts are enabled separately
PIX, cards, SEPA Not available — requires licensed partners; none are under contract

Until your account is activated, requests for live features fail with feature_unavailable_error; see Errors.

Custody

Section titled “Custody”

Live payments are custodial. They are processed through the platform’s own Bitcart account:

  • the customer pays a wallet of the platform’s Bitcart store, not a wallet of yours; the checkout opens one Bitcart invoice per intent, and only the Bitcart status complete makes an intent confirmed;
  • the amount received is then credited to your organization’s custodial balance: GRYPHEM PAY holds the funds in the platform’s wallets on your behalf and records what it owes you in an append-only ledger (GET /v1/balances). Partial or late payments are credited only after an operator has verified them;
  • you withdraw through payouts to allow-listed addresses, in the same asset (no conversion). By default a second member of your organization approves each payout, a GRYPHEM operator always reviews it, and Bitcart sends it from the platform’s hot wallet.

Accounts are activated for live payments only once every release gate is approved by two operators — including the legal gate custody_authorisation, because holding and transferring customers’ crypto-assets is a regulated activity in most jurisdictions. GRYPHEM PAY holds no such authorisation and claims none.

Also:

  • Platform fees are billed to the merchant separately (monthly invoice or subscription). They are never silently deducted from customer payments.
  • Network fees of incoming payments are paid by the sender and are not part of the amount due.
  • There is no card-style chargeback. Refunds are never automatic: you return funds yourself, for example with a payout to an allow-listed address the customer gives you.

Custody is not, by itself, a regulatory exemption — it is the opposite. See Regulatory status.

How the pieces fit

Section titled “How the pieces fit”
  1. Your server creates a payment intent with a live API key and an Idempotency-Key.
  2. The customer opens the hosted checkout URL (an unguessable, short-lived capability URL — no keys involved). The checkout opens an invoice in the platform’s Bitcart account and shows, for each accepted asset, an address and the exact amount to send.
  3. The processor reports the invoice status. GRYPHEM PAY never trusts a callback body: it re-fetches the invoice from Bitcart, maps its status onto the central state machine and, once the invoice is complete, credits the received amount to your custodial balance.
  4. Webhooks notify your endpoint; you fulfil only when the intent is fulfillable, re-checking it with a GET before any irreversible action.
  5. Reconciliation compares processor evidence, expected amounts, credits, payouts and webhook delivery, and surfaces discrepancies.

Conventions you will see everywhere

Section titled “Conventions you will see everywhere”
  • The API lives at https://api.feitpay.com/v1; the dashboard at https://app.feitpay.com; hosted checkouts at https://checkout.feitpay.com.
  • JSON with snake_case fields; timestamps are UTC ISO-8601 (2026-10-20T12:00:00Z).
  • Amounts are decimal strings ("59.90"), never floating-point numbers. Crypto amounts also have an integer *_base_units string ("99834" satoshis).
  • IDs are opaque, prefixed strings: pi_ payment intents, cs_ checkout sessions, inv_ invoices, whe_ webhook endpoints, evt_ events, req_ request ids.
  • Every response has a Request-Id header. Quote it when you contact support.
  • Every merchant object has livemode. Payments on this platform are always live (livemode: true).