API overview

The EXZIX merchant integration API creates and observes merchant-owned Payment Intents and delivers server-generated webhook events. The documented routes are the routes present in the application.

Request conventions

JSON mutations require Content-Type: application/json. API authentication uses Authorization: Bearer <api-key>. Successful responses use a data envelope; failures use the documented error envelope. No public API hostname is assumed here, so examples use YOUR_API_HOST.

Public merchant integration routes

The merchant path segment is the public merchant identifier and must match the merchant associated with the API key. The API key environment supplies Test or Live; callers cannot override it in a body, query, or path.

GET /api/v1/merchants/{merchant}/payment-intents — payment_intents:read
POST /api/v1/merchants/{merchant}/payment-intents — payment_intents:write
GET /api/v1/merchants/{merchant}/payment-intents/{payment_intent} — payment_intents:read
POST /api/v1/merchants/{merchant}/payment-intents/{payment_intent}/cancel — payment_intents:write
GET /api/v1/merchants/{merchant}/go-live/readiness — merchant:readiness

Payment Intent relationship

Creation records a merchant-owned request. Blockchain observation, verification, confirmation, and reorganization handling are server-side authority. Webhooks notify the merchant of server-recorded events; they do not create blockchain truth.

Pagination and filters

Payment Intent listing accepts limit (1–200, default 50), cursor, status, created_after, created_before, public_id, and merchant_reference. The cursor is opaque and must not be constructed or parsed by clients.

Idempotency

Payment Intent creation requires Idempotency-Key. It is trimmed and must contain 8–128 characters matching [A-Za-z0-9._:-]. The key is scoped by merchant and environment. Repeating the same request returns the original result; a different request with the key returns 409 idempotency_conflict.