Payments API

The payments API docs cover the published server-side surfaces that create payment or ramp state. In the current public product surface, 0Gate sessions are the clearest hosted integration path: your backend creates a session with a secret key, your frontend mounts the hosted widget with browser-safe values, and your webhook endpoint receives the durable status signal.

0Base product documentation remains available under Products, but 0Base endpoint-level partner API pages are not published yet. Do not build against unpublished 0Base endpoint paths.

What this page covers

• Which payment API groups are currently published.
• How 0Gate hosted sessions create payment and ramp state.
• Required credential placement for payment flows.
• Idempotency and retry behavior for state-changing writes.
• How webhooks and settlement records should be used for final state.

Payment API map

0Gate hosted payment flow

Use POST /v1/gate_sessions when you want 0Bit to host KYC, payment, compliance, and settlement UX. The request binds amount and currency on your server. The response includes a client_secret that is safe to pass to the browser for that one session.

Create a session

curl -X POST https://gate-api-sandbox.0bit.app/v1/gate_sessions \
  -H "Authorization: Bearer sk_test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 00000000-0000-4000-8000-000000000123" \
  -d '{
    "amount": "100.00",
    "currency": "EUR",
    "return_url": "https://partner.example/complete",
    "target_token": "USDT",
    "metadata": {
      "order_id": "order_test_123"
    }
  }'

The response includes a session id and a browser-safe client_secret. Retrieval endpoints should not return the raw client secret again.

Session lifecycle

Capabilities and eligibility

Capability endpoints are read-only planning tools. They help your integration decide what to show, but they do not guarantee every market, asset, rail, or corridor is available for every partner.

Eligibility answers should be treated as decision input, not a money path. If a region is unsupported or unresolved, return a clear disabled state in your UI instead of sending the user into a session that will fail later.

Quotes and rails

Quote previews can help a user understand indicative pricing before they commit. Signed quotes and rail operations are stronger: they are entitlement-gated, rate-locking, and one-time redeemable. Keep those calls server-side.

Unpublished product APIs

0Base and 0Link are product documentation surfaces, not published partner API references today. Their product pages can explain object models, routing boundaries, reporting expectations, and launch-readiness requirements, but they should not publish endpoint paths, request schemas, or partner API examples until those products are ready for partner API access.

Idempotency and retries

Every payment write should be treated as a single logical operation. Persist your idempotency key next to the order, checkout, quote, payment intent, or rail record.

Reconciliation contract

Payment APIs create state, but signed webhooks and trusted server reads confirm durable state. Store these fields together:

Related pages