Exact amount payment intents

Exact amount payment intents are the safest way to ask a customer for a defined checkout amount. The merchant creates the payment intent for a known fiat amount and desired crypto currency, then treats status and amount evidence as the authority for fulfillment.

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 amount -> Create intent -> Issue instructions -> Detect payment -> Confirm status -> Fulfill or recover. 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
Amount source	Use the merchant order total after discounts, tax, shipping, and expiry policy are final.	Prevents mismatches between cart and payment object.
Intent creation	Create one payment intent per payable order or billing event.	Gives every collection attempt a durable id.
Payment instructions	Show exact amount, currency, crypto currency, network, and expiry where available.	Reduces support cases around underpayment and overpayment.
Status mapping	Only terminal success should unlock fulfillment.	Detected or confirming is not enough for most merchants.
Mismatch handling	Record underpaid, overpaid, failed, expired, and cancelled outcomes.	Finance and support need evidence for recovery.

Status and state handling

State	What it means	Developer action
Created	Intent exists but customer has not paid.	Show instructions.
Requires payment	Customer action is still needed.	Keep payable.
Payment detected	Something arrived or was observed.	Do not fulfill yet.
Succeeded/failed/cancelled	Terminal state.	Fulfill, recover, or close.

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 exact amount payment intents. 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.

{
  "payment_intent_id": "pi_live_456",
  "merchant_order_id": "ord_555",
  "amount": "79.99",
  "currency": "EUR",
  "crypto_currency": "USDT",
  "client_reference": "ord_555",
  "status": "requires_payment",
  "amount_policy": "exact"
}

Operational scenario

A store selling digital goods should create the payment intent after the final total is known and before showing payment instructions. If the customer changes the cart, the old intent should not silently change under them; create a new lifecycle and keep the old one recoverable.

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
A wallet address was shown before final total.	The exact amount intent is created after final total.
Partial payment created ambiguous fulfillment.	Underpaid and overpaid states are recorded and handled explicitly.
Cart edits reused the same payment instruction.	New amount means new payment object or reviewed update path.
Duplicate browser submits created duplicate intents.	Server idempotency ties the intent to the merchant order.

Evidence to keep

Evidence	What to store
Intent row	Intent id, order id, amount, currency, crypto currency, status.
Instruction snapshot	Exact amount displayed, network, address/reference, expiry.
Mismatch evidence	Amount received, payment hash if available, detected timestamp.
Idempotency record	Key, request body hash, returned intent id.
Fulfillment decision	Who or what changed order state and which raw status triggered it.

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
Customer sends less	Keep pending or failed according to policy and preserve received amount evidence.
Customer sends more	Do not auto-adjust order; route to support/refund policy where enabled.
Intent cancellation races payment detection	Read current status and preserve both timestamps.
Duplicate create retry	Return same intent for same idempotency key/body.

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 /payment_intents`	Create exact amount object.
`POST /payment_intents/{intentId}/confirm`	Move intent forward where enabled.
`POST /payment_intents/{intentId}/cancel`	Cancel when the merchant order is no longer payable.
`POST /payment_intents/{intentId}/deposit_address`	Create deposit instructions where enabled.

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

Exact amount payment intents turn a payment request into a precise contract: amount, currency, crypto currency, status, and expiry. That protects customers from ambiguous instructions and merchants from fulfillment mistakes.

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/payment_intents \
  -H "Authorization: Bearer $OBIT_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ord_100045:base:v1" \
  -d '
{
    "amount": "89.00",
    "currency": "EUR",
    "cryptoCurrency": "USDT",
    "clientReference": "ord_100045",
    "settlementCurrency": "USDC",
    "settlementRail": "onchain"
}'

Example response shape:

{
  "intentId": "pi_test_456",
  "status": "requires_payment",
  "amount": "89.00",
  "currency": "EUR",
  "cryptoCurrency": "USDT",
  "clientReference": "ord_100045",
  "settlementCurrency": "USDC",
  "settlementRail": "onchain"
}

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 intents after final amount calculation.
Store raw amount strings exactly.
Show exact instructions from the current object.
Do not fulfill from detected payment alone.
Record under/overpayment evidence.
Use idempotency for create and confirm calls.