What is 0Base?

0Base is the merchant checkout and payment-object foundation for businesses that need crypto or stablecoin-style payment acceptance without forcing every merchant system to build wallet instructions, payment state machines, webhook recovery, settlement ledgers, and finance exports from scratch.

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.

End-to-end picture

This flow is intentionally shown as product infrastructure: Customer checkout -> 0Base payment object -> Status and notification -> Merchant fulfillment -> Settlement ledger -> Finance report. 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

Status and state handling

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 merchant checkout foundation. 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_id": "mrc_2048",
  "merchant_order_id": "ord_global_7781",
  "base_objects": [
    "checkout",
    "payment_intent",
    "webhook_delivery",
    "settlement_ledger_entry"
  ],
  "customer_visible_state": "payment processing",
  "finance_visible_state": "open until settlement ledger row exists"
}

Operational scenario

A SaaS platform wants to let merchants accept stablecoin payments from international customers. 0Base gives the platform one object model for checkout and reconciliation while the platform keeps its own storefront, catalog, customer account, fulfillment, and tax logic.

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

Evidence to keep

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

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

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 gives merchants a common payment infrastructure layer for global crypto and stablecoin checkout. The societal value is practical: more businesses can accept digital value without rebuilding wallet instructions, status recovery, ledgers, and settlement reporting from scratch.

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/capabilities/payment_methods \
  -H "Authorization: Bearer $OBIT_SECRET_KEY"

Example response shape:

{
  "object": "list",
  "data": [
    {
      "object": "payment_method",
      "id": "crypto_wallet",
      "name": "Crypto wallet",
      "type": "crypto",
      "active": true,
      "currencies": [
        "EUR",
        "GBP",
        "USD"
      ],
      "crypto_currencies": [
        "USDT",
        "USDC"
      ],
      "networks": [
        "network_from_capabilities"
      ],
      "min_amount": "1.00",
      "max_amount": "5000.00"
    }
  ],
  "has_more": false,
  "url": "/v1/capabilities/payment_methods"
}

Implementation checkpoints:

• Read account and environment state before rendering or launching the product surface.
• 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

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

• Model every payment as an object lifecycle, not a one-off callback.
• Keep merchant order state separate from 0Base status.
• Render payment methods from capabilities.
• Use signed notifications plus polling/report reads for recovery.
• Keep finance exports tied to ledger ids.
• Write customer copy that reflects account-gated availability.

Related pages