0Base vs 0Gate

Choose between 0Base merchant payment objects and hosted 0Gate ramp/payment flows.

0Base and 0Gate solve different integration problems. 0Base is a merchant checkout and payment-object system. 0Gate is a ramp flow for moving users between fiat and crypto where that product is the right fit. Choosing the wrong boundary creates confusing user journeys and difficult reconciliation.

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: User need -> Merchant checkout? -> Use 0Base object model -> Ramp/on-off flow? -> Use 0Gate -> Reconcile in the right system. 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
0Base fit	Merchant sells a product, invoice, balance top-up, subscription cycle, deposit, or pre-order.	The merchant needs orders, payment intents, webhooks, settlement ledgers, and reports.
0Gate fit	User wants a ramp experience into or out of crypto.	The integration needs ramp-specific identity, funding, and delivery behavior.
Shared discipline	Both products require account access, status tracking, and reconciliation.	Do not treat either product as a browser-only widget.
Customer copy	Describe the user action in product terms.	A checkout customer and a ramp user have different expectations.
Finance model	Use the ledger/report surface that belongs to the chosen product.	Avoid mixing checkout settlement with ramp transaction records.

Status and state handling

State	What it means	Developer action
Checkout open	Merchant order awaits customer payment.	Use 0Base status.
Ramp quote accepted	User accepted ramp terms.	Use 0Gate/0Pools lifecycle.
Payment completed	Merchant can fulfill.	0Base object state controls order.
Ramp settled	User asset movement is complete.	Ramp product controls delivery.

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 0Base and 0Gate boundary. 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.

{
  "decision": "base_vs_gate",
  "merchant_order_id": "ord_merchant_001",
  "ramp_session_id": null,
  "chosen_product": "0Base",
  "reason": "customer is paying merchant invoice",
  "reconciliation_surface": "0Base settlement ledger"
}

Operational scenario

A wallet app that sells a membership should use 0Base for the membership checkout. The same app may use 0Gate elsewhere when a user wants to buy crypto for their own wallet. Keeping these flows separate protects support scripts, customer copy, and finance records.

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
One generic payment button handled checkout and ramps.	The product chooses 0Base or 0Gate before rendering.
Ramp statuses appeared in merchant order tables.	Merchant orders store 0Base statuses only.
Customers saw financial rail language at checkout.	Customers see merchant checkout language and payment state.
Finance reconciled against the wrong ledger.	Each product uses its own reports and object ids.

Evidence to keep

Evidence	What to store
Decision log	Why 0Base or 0Gate was selected for the feature.
Object ids	0Base checkout/intent ids or 0Gate session/transaction ids, not both by accident.
Customer terms	Checkout terms or ramp terms shown to the user.
Status map	Product-specific raw status and customer label.
Finance reference	Correct ledger or report endpoint for the selected product.

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
A merchant checkout uses ramp statuses	Rebuild the flow around 0Base payment intents and reports.
A ramp user is sent to merchant checkout	Move to 0Gate and use ramp-specific disclosures.
Both products create records for one user action	Cancel one path and preserve an audit note.
Support cannot identify the product	Use id prefixes, route names, and product-specific support packets.

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
0Base payment objects	Checkout, link, invoice, intent, refund.
0Gate API reference	Ramp-specific flow where applicable.
0Base reports	Merchant settlement and transaction reporting.
0Base capabilities	Payment and settlement availability.

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

Choosing 0Base or 0Gate correctly keeps customer intent clear. Merchant checkout, invoices, and payment objects belong in 0Base; ramp experiences belong in 0Gate. The distinction prevents confusing financial journeys and mismatched reconciliation records.

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/webhooks/test \
  -H "Authorization: Bearer $OBIT_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ord_100045:base:v1" \
  -d '
{
    "eventType": "payment_intent.succeeded",
    "intentId": "pi_test_456"
}'

Example response shape:

{
  "object": "webhook_delivery",
  "id": "whd_test_launch",
  "event_id": "evt_test_launch",
  "event_type": "payment_intent.succeeded",
  "intent_id": "pi_test_456",
  "status": "pending",
  "attempts": 0
}

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

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.
Launch test fails	Identify whether the failure is capability, key, webhook, status, or report related.	Block launch for that scope until the failing layer has a passing evidence record.

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

Decide the product boundary before writing UI.
Keep 0Base and 0Gate ids in different columns.
Do not reuse status copy across products without review.
Train support on the selected object model.
Confirm which API reference owns the endpoint.
Use capabilities rather than nav labels to decide availability.