GRYPHEMPay

Product

From payment intent to reconciliation.

GRYPHEM PAY is a gateway for merchants who want to accept crypto payments with the operational evidence a finance team expects. Here is every stage a payment passes through once live payments are enabled for your account.

The system

Six stages, one evidence trail.

Each stage writes what it saw and why it decided. Nothing downstream re-implements a rule upstream already owns.

  1. Your server

    Payment intent

    Amount, currency and an idempotency key, sent with your live key. Tenant comes from your API key, never the request body.

    POST /v1/payment-intents
  2. Customer

    Invoice

    The customer picks an asset. The checkout opens an invoice in GRYPHEM PAY’s Bitcart account with the exact amount and an address for this payment.

    invoice · address
  3. Bitcart

    Observation

    Bitcart tracks the payment on-chain. GRYPHEM never trusts a callback body: it re-fetches the invoice before any state change, and also polls.

    paid → confirmed → complete
  4. State machine

    Finality

    Only an invoice Bitcart reports complete makes the payment confirmed. Partial and excess payments become explicit states, and late funds go to review — nothing is credited silently.

    confirming → confirmed
  5. Dispatcher

    Webhook

    Signed, retried and replayable events for every externally visible transition, from a transactional outbox.

    payment.confirmed
  6. Finance

    Balance & reconciliation

    The amount received is credited to your custodial balance exactly once. A continuous reconciler surfaces discrepancies, and payouts need approval and an operator review.

    balance · payouts · CSV

Lifecycle

States that read the same everywhere.

Fourteen states, each with a label, an icon and a sentence of explanation — in the checkout, the dashboard, the API and every webhook.

Payment intent state machineHappy path from created to confirmed, with exception states for expiry, under- and overpayment, chain reorganisation, late payment, manual review and resolution. The full transition list follows as text.createdawaiting_paymentdetectedconfirmingconfirmedcanceledexpiredunderpaidoverpaidreorgedfailedlate_paymentmanual_reviewresolved
Every transition is applied by one state machine with database compare-and-set; workers submit evidence, they never write a status directly.
All transitions as text
  • created → awaiting_payment
  • awaiting_payment → detected
  • detected → confirming
  • confirming → confirmed
  • created → canceled
  • awaiting_payment → expired
  • expired → late_payment
  • confirming → underpaid
  • confirming → overpaid
  • confirmed → reorged
  • reorged → confirming
  • underpaid → manual_review
  • overpaid → manual_review
  • late_payment → manual_review
  • reorged → manual_review
  • manual_review → resolved
  • awaiting_payment → failed

What you get

The working parts.

  • Hosted checkout

    A fast, distraction-free payment page with the exact amount, the address for this payment, a QR code and real-time state. No WebGL, no surprises.

    Learn more

  • Merchant dashboard

    Payments, invoices, payment links, balances and payouts, webhooks, API keys, team roles, reconciliation and exports — with honest empty and error states.

    Learn more

  • API & SDKs

    Contract-first OpenAPI 3.1, idempotent writes, typed errors, cursor pagination and request IDs. A TypeScript SDK and webhook verifier.

    Learn more

  • Signed webhooks

    HMAC-SHA256 over timestamp and raw body, replay windows, secret rotation with overlap, delivery logs and manual replay.

    Learn more

  • Reconciliation & exports

    Discrepancy queues for under-, over- and late payments; CSV exports with UTC timestamps; immutable billing history.

    Learn more

  • Operator controls

    A restricted console with MFA, four-eyes approval for high-impact actions and an append-only audit trail.

    Learn more

Boundaries

What it is not — yet.

Create accountFor developers