How 0Base works

See how merchant apps, 0Base payment objects, reports, and webhook delivery fit together.

0Base architecture is a layered merchant payments system. The merchant application owns product and fulfillment, 0Base owns payment objects and notifications, settlement/reporting owns operational closeout, and external liquidity or rails remain behind stable public objects.

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 app -> 0Base API -> Payment object store -> Webhook outbox -> Settlement ledger -> Reports and exports. 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 boundary	Catalog, order, customer, fulfillment, tax, and refund policy remain in the merchant system.	Keeps 0Base focused on payment infrastructure.
API boundary	Server-side calls create and mutate payment objects.	Protects secrets and idempotency.
Event boundary	Webhook deliveries are asynchronous and recoverable.	The merchant can survive downtime without losing state.
Settlement boundary	Ledger rows and reports describe finance state.	Finance can close without reading product logs.
Provider boundary	Implementation details stay behind checkout, intent, status, ledger, and report objects.	The public contract can improve without breaking merchant code.

Status and state handling

State	What it means	Developer action
API create	Synchronous acknowledgement that an object exists.	Store ids immediately.
Async event	Notification that status changed.	Verify signature and dedupe event id.
Read repair	Polling or report read used when events are delayed.	Compare to existing order state.
Ledger close	Finance record reaches terminal payout state.	Close period or investigate.

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 system architecture. 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_app": "storefront",
  "base_api": "server-side only",
  "payment_store": "checkout + payment_intent + refund",
  "outbox": "webhook_delivery",
  "finance": "settlement_ledger + reports",
  "public_contract": "objects, statuses, events, ledgers"
}

Operational scenario

A mature platform may have many customer-facing payment experiences, but they should all converge into the same 0Base object graph. That is what allows one notification handler, one support packet, and one finance export process to cover storefront checkouts, invoices, links, and deposits.

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
Each product team integrated a different wallet or processor path.	Every team integrates the same object and event model.
Provider-specific fields leaked into product logic.	Provider details stay behind public 0Base objects.
Finance waited for engineering log pulls.	Reports and ledger rows are first-class surfaces.
Webhook failure required manual status guessing.	Delivery logs and read repair define recovery.

Evidence to keep

Evidence	What to store
Architecture decision	Which 0Base objects each product flow uses.
Trust boundary	Where secret keys, client secrets, and public callbacks may appear.
Event policy	Signature verification, dedupe, retry, replay, and dead-letter behavior.
Ledger policy	Which status creates a finance row and which report closes it.
Data retention	How long support can inspect ids, statuses, and event attempts.

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
Client directly calls secret endpoints	Move creation and confirmation to the backend.
Multiple handlers mutate one order	Use idempotent event processing and current-state reads.
Provider migration affects product UI	Depend on public object fields only.
Report totals drift from orders	Compare by intent id and settlement id, not date/amount alone.

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
`GET /webhooks/deliveries`	Observe event delivery.
`POST /webhooks/deliveries/{id}/replay`	Recover failed delivery.
`GET /merchants/{merchantId}/settlement_ledger`	Read finance ledger rows.
`GET /reports/transactions`	Cross-check payment objects.

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

A stable architecture lets 0Base improve payment infrastructure behind the scenes while merchant code depends on durable public objects. That matters for society-scale commerce because infrastructure can evolve without forcing every store, marketplace, or platform to rebuild checkout.

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 GET https://base-api-sandbox.0bit.app/v1/payment_intents/pi_test_456 \
  -H "Authorization: Bearer $OBIT_SECRET_KEY"

Example response shape:

{
  "intentId": "pi_test_456",
  "status": "processing",
  "amount": "89.00",
  "currency": "EUR",
  "cryptoCurrency": "USDT",
  "clientReference": "ord_100045",
  "conversionTxId": "conv_test_123",
  "quotedRate": "1.08450000",
  "cryptoAmount": "96.52000000"
}

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.

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

Draw the object graph before implementing UI.
Keep provider and rail names out of merchant logic unless explicitly part of the public contract.
Design webhook processing as a queue with dedupe.
Keep read repair paths for missed notifications.
Make settlement ledger ids visible to finance operations.
Review data minimization for support views.