0Base quickstart

Build the smallest production-shaped 0Base flow: create a merchant order, create a checkout or payment intent, present the customer payment surface, wait for trusted backend status, and reconcile the resulting ledger record. The browser experience is one layer; the durable backend record is what keeps retries, delayed notifications, support review, and finance closeout reliable.

0Base availability is account-gated. Build against capabilities, merchant status, environment mode, and settlement settings instead of assuming that every payment method, asset, network, cadence, or refund path is enabled for every merchant.

0Base product docs and API details

These pages are public product guidance for merchant and platform developers. 0Base endpoint-level API pages are not published for partners yet; use this product documentation to understand the workflow, records, and launch boundaries.

End-to-end picture

This flow is intentionally shown as product infrastructure: Merchant order -> Server creates 0Base object -> Customer pays -> Status or webhook arrives -> Fulfillment decision -> Ledger and export. The merchant application can make the customer experience simple, but the backend should keep each step visible enough for retries, support, and finance closeout.

Production contract

Boundary	What to build	Why it matters
Merchant order	Create the merchant-side order before creating a 0Base object.	Your order id is the durable business reference.
Server-side create	Create checkout, link, invoice, or payment intent from the backend with a secret key.	Prevents browser code from owning money state.
Idempotency	Send an `Idempotency-Key` on state-changing writes.	Makes retries safe after timeouts or double-clicks.
Status source	Read status from API responses, signed events, or reports.	Redirects and browser callbacks are not settlement proof.
Reconciliation	Store object ids, event ids, ledger ids, report filters, and timestamps.	Support and finance can reconstruct the lifecycle.

Status and state handling

State	What it means	Developer action
Created/open	Object exists and the merchant can show the customer a payment path.	Do not fulfill from creation alone.
Payment detected	A customer payment signal exists but final state is not complete.	Show pending and preserve evidence.
Processing/confirming	0Base is still moving through confirmation or settlement logic where enabled.	Keep the merchant order locked.
Succeeded/completed	Terminal success for the payment object.	Fulfill, ledger, and export.

Status handling should be strict even when the customer UI is friendly. Store raw 0Base statuses, map them to customer-safe labels at the edge, and keep the merchant order state separate from the payment object state. That separation lets you change customer copy without corrupting reconciliation.

Example implementation record

This is an application-side record shape for first checkout integration. Keep exact request and response fields aligned with your enabled account contract when 0Base API access is released for your partner account; the point of this record is to keep product, support, and finance joined in your system.

{
  "merchant_order_id": "ord_100045",
  "checkout_id": "chk_live_123",
  "payment_intent_id": "pi_live_456",
  "amount": "89.00",
  "currency": "EUR",
  "crypto_currency": "USDT",
  "status": "processing",
  "idempotency_key": "ord_100045:create:v1",
  "fulfillment_state": "waiting_for_backend_status"
}

Operational scenario

A marketplace starts with one stablecoin checkout option for approved merchants. The checkout page can redirect a customer immediately, but fulfillment stays pending until the backend sees a terminal status and the finance record has the ids required for later reconciliation.

In practice, production 0Base integrations make the happy path fast while keeping exceptions predictable: retries return the same object, delayed notifications can be repaired, expired sessions do not become mystery payments, and finance exports can be traced back to the original merchant order.

Before and after

Before 0Base	With 0Base
Checkout redirect was treated as proof of payment.	The redirect is only a user experience signal; backend status drives fulfillment.
Support searched by email and amount.	Support starts from order id, checkout id, payment intent id, and event id.
Retries could create duplicate payment objects.	Idempotency keys make create and confirm retries deterministic.
Finance closed by screenshots.	Exports and ledger rows become the closing evidence.

Evidence to keep

Evidence	What to store
Order record	Merchant order id, customer reference, amount, currency, cart hash.
Payment record	Checkout id, payment intent id, status, amount, crypto currency, idempotency key.
Notification record	Event id, signature result, received timestamp, processed timestamp.
Ledger record	Settlement id, asset, amount, status, created and updated timestamps.
Support packet	Request id, object ids, environment, current raw status, last event id.

This evidence is what makes the integration supportable at institutional scale. A developer should not need private operational knowledge to answer basic questions such as what the customer saw, which object owns the state, which event announced the change, and which ledger or report row closed the money movement.

Failure modes and recovery

Failure mode	Recovery
Create request times out	Retry with the same idempotency key and compare the returned object id.
Customer closes checkout	Keep order pending until status expires, fails, or succeeds.
Webhook arrives late	Read current object state before changing fulfillment.
Report has no ledger row yet	Keep finance state open and poll/read again according to your operations policy.

Recovery should be idempotent and explainable. When the system is uncertain, preserve the current raw status, read the latest object state, attach a support reference, and avoid changing fulfillment or finance state until a trusted terminal condition is present.

API adjacency

API area	Use it for
`POST /checkouts`	Create a hosted checkout object where enabled.
`POST /payment_intents`	Create the merchant payment object.
`GET /payment_intents/{intentId}`	Read trusted payment state.
`GET /reports/transactions`	Reconcile transactions for operations.

For endpoint-level implementation, use the API reference as the source of truth for fields, enums, authentication, idempotency behavior, pagination, and response examples.

Why this matters for merchants and customers

0Base matters because merchant checkout should not depend on copied wallet addresses, browser redirects, or manual finance review. A checkout can feel simple to the customer while the merchant keeps durable state for retries, delayed notifications, settlement records, and support review.

At scale, the value of 0Base is not only that a payment can be created. The value is that the payment can be explained later: what the customer saw, which account capabilities allowed it, which backend state changed, which notification delivered it, and which ledger or report row closed it.

Worked API path

The example below shows the implementation shape for this page. Use merchant-specific capabilities, account settings, and API responses in production; the ids and values here are illustrative.

curl -X POST https://base-api-sandbox.0bit.app/v1/checkouts \
  -H "Authorization: Bearer $OBIT_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ord_100045:base:v1" \
  -d '
{
    "amount": "129.00",
    "currency": "EUR",
    "cryptoCurrency": "USDT",
    "clientReference": "ord_100045"
}'

Example response shape:

{
  "checkout_id": "chk_test_123",
  "status": "open",
  "amount": "129.00",
  "currency": "EUR",
  "crypto_currency": "USDT",
  "payment_intent_id": "pi_test_456",
  "checkout_url": "https://checkout.0bit.app/c/chk_test_123",
  "expires_at": "2026-06-28T21:00:00Z"
}

Implementation checkpoints:

Store your merchant reference before calling 0Base.
Attach the returned object id to the same business record.
Record the request id, idempotency key, raw status, and environment.
Use webhook and report reads to repair delayed or missed state changes.

Data join map

This join map is the reason 0Base is infrastructure rather than a payment button. A merchant can change checkout UX, support tooling, or finance exports without losing the chain from customer action to backend state and settlement evidence.

Operator runbook

Signal	Check first	Action
Customer reports payment not updating	Look up merchant order id, 0Base object id, raw status, and latest webhook delivery.	Read current object state before changing fulfillment.
Webhook delivery failed	Check delivery id, event id, attempts, last error, and handler logs.	Fix the handler, replay once, and dedupe by event id.
Finance cannot match a row	Compare client reference, intent id, settlement id, report period, and export row.	Move the item to reconciliation queue instead of closing by amount/date.
Customer paid but order is still pending	Check raw intent status, deposit-address status, confirmations, and latest report row.	Keep fulfillment pending until terminal success or documented manual review.

The runbook should be available to support and finance teams before launch. A developer integration is not complete if only engineering can explain the state of a customer payment.

Developer checklist

Create merchant orders before 0Base payment objects.
Keep secret keys and idempotency on the server.
Map raw 0Base status to customer-safe copy without losing the raw value.
Fulfill only from trusted backend state.
Log request ids and event ids for support.
Run one full sandbox payment from create to ledger export before launch.