Cresora Commerce Documentation

🔬Planned operations — published for review, not callable

This reference includes operations marked x-cresora-status: planned in the canonical contract: they have no route on any host and return 404 (or 501 for reserved discriminator variants) until released. There is no separate preview stream, no feature flag to enable one, and no enrollment — the badge on each operation tells you whether it is served. See the stable /api/v1 reference for what you can call today. Like the stable API, these operations are server-to-server: there is no interactive console here. Download the preview spec (YAML).

Generating a client? Download the OpenAPI spec (YAML) — the same document these pages are generated from.

Api KeysAPI key management — list active keys, rotate, revoke.
CapabilitiesQuery what your partner can do today — enabled features, certification status, MCC scope.
CertificationRequest and track partner certification checks. Certification is the gate a partner clears before onboarding real merchants.
ConfigPartner configuration — webhook URL, IP allowlist, HPP defaults, rate-limit tier, AVS decline policy. Read your own config; write via `PUT /config/partners/{partnerId}`. Rate-limit tier and AVS decline policy are Cresora-managed (admin-only); webhook URL, HPP settings, and IP allowlist are partner self-service.
Custom FieldsPer-merchant custom-field definitions — up to 10 fields per merchant (a Cresora product cap; the gateway documents none). Definitions are delivered onto the merchant's gateway record and the field VALUES ride transaction creates (Sale / Authorization / ACH debit + recurring contract create) and hosted-page checkouts. Partner self-service (`custom_fields:config:read` / `custom_fields:config:write`); the merchant is scoped from your API key, never a path/body param.
CustomersPayer customers under a merchant. A customer owns the merchant's stored payment methods (the tokenization vault). Partner self-service (`customer:read` / `customer:write`); the merchant is the path scope and the partner is scoped from your API key.
HealthService health and liveness probes — for partner integration monitoring and uptime dashboards. Unauthenticated endpoint.
H P PHosted Payment Pages — Cresora-hosted checkout. PCI scope stays with Cresora + the gateway. The partner only handles the session redirect and the callback on completion.
MerchantsMerchant lifecycle — create, submit for underwriting review, update, and close merchant accounts. Merchants progress through a state machine owned by Cresora Operations.
NotificationsPartner-portal notification feed — the bell dropdown and `/notifications` page. Read state is tracked per portal user: one teammate marking a notification as read does not clear it for the rest of the team. Primarily a portal-session surface; API keys can read it with the `notification:read` / `notification:update` scopes.
PartnersPartner self-service reads. The `/partner/me` endpoint returns the partner record bound to the authenticated caller's API key — useful for portal "who am I" displays and federated-identity contracts. The cross-tenant listing (`GET /iam/partners`) lives in the admin-only surface. `GET /iam/partners/{id}` and `/{id}/transitions` are partner-callable under `partner:read`, but row-level security scopes them to the caller's own tenant — a foreign id resolves to `404`, never to another partner's record.
RecurringManage recurring billing plans. First payment captures a gateway token via HPP; subsequent charges use the stored token. Retries are configurable per plan (soft decline + ACH R01).
SettlementSettlement batches and reconciliation exceptions — the read surface of the two-state settlement contract. A batch is `gateway_reported` while Cresora holds only the gateway's per-transaction settled webhooks, and `report_verified` once the processor's settlement report has been ingested and its control totals verified. Exceptions are the mismatches that verification (or the settlement-window sweep) raised. Read-only for partners; resolution is a Cresora Operations action.
Stored credentialsThe tokenization vault — cards a merchant has stored for reuse. Entries are minted at a hosted-page (HPP) establishing completion, not created directly; ISVs list, inspect, and revoke them, and charge a stored card by passing its opaque vault token as the payment instrument on `POST /transactions` (`stored_credential:read` / `:revoke`). The stored-credential (MIT/COF) reuse program has been always-on since its 2026-07-18 de-gate — there is no dedicated charge endpoint and no feature gate on this surface.
TerminalsRegister, provision, suspend and reactivate POS terminals. Terminal runtime communication uses WebSocket — see the separate AsyncAPI spec for the terminal protocol.
TransactionsProcess card sales, refunds, voids, authorizations and captures. Batch close operations for settlement timing.
WebhooksManage webhook subscriptions — event types, delivery URLs, HMAC secret rotation. See `webhooks:` section for event schemas.

Cresora Commerce API — planned operations