Skip to main content
BETA — access is granted per account. This API is in closed beta and is enabled per account. Your account must be explicitly allowlisted; requests from a non-allowlisted account are rejected with 401. Endpoints are stable in shape but subject to additive changes during the BETA window.
Configure a merchant’s Yuno checkout server-to-server — the same configuration surface that powers the Yuno Dashboard’s Checkout Builder — so a partner can manage its merchants’ checkouts programmatically, without using the Yuno UI:
  • Payment methods — which methods are shown and in what display order
  • Conditions — per-method rules (currency, country, amount, metadata) that gate when a method appears
  • Required fields — per-method form field configuration (CVV, installments, billing address, etc.) for both the enrolled (saved-card) and non-enrolled (first-time) flows
  • General settings — accepted document types per country
  • Styling & SDK settings — colors, fonts, button shapes, logos, and Payment Link branding

​
Base URL

All examples in this reference use the production base URL. The sandbox host accepts the same endpoints and payload shapes.

​
Authentication

Every request is authenticated with your merchant API credentials and scoped to a single account.
The organization is resolved by Yuno from your credentials — do not send an organization header. Missing/invalid credentials, or a non-allowlisted account, return 401.

​
Endpoints

A custom checkout is identified by a checkout_code (a UUID). Its configuration and styling are read and written through the same resource — two operations: {checkout_code} must be a valid UUID; other values are rejected with 400 before any processing.
You obtain a checkout_code when the custom checkout is created in the Yuno dashboard / embedded Checkout Builder; Yuno delivers the generated UUID to your integration. Creating and listing checkouts via the public API is planned for a later phase — today the API reads and writes an existing checkout.

​
Key behaviors

PUT is a sparse upsert for configuration, not a full replace. Payment methods omitted from the payment_methods array retain their previous state — they are not removed or disabled. To disable a method, include it with is_active: false.
  • Configuration — sparse update. Only the payment methods you include are updated; omitted methods keep their previous state. Publishing updates existing methods only — new payment methods cannot be created via the API (contact your Yuno TAM to add methods).
  • Styling — partial merge. Fields you omit (or send as null) are preserved; only the fields you include change. Partial styling updates are safe — you do not need to resend the entire styles object. To reset styling to defaults, use flags.force_default_styles.
  • Order is driven by order_to_show, not by array position. Lower values are shown first.
  • At most one condition set per required field. Sending more than one condition set on a field is rejected with 400 (conditions_to_override must contain at most one condition set).
  • Enrolled and non-enrolled flows are independent. For CARD, configure the non-enrolled flow via fields and the enrolled (saved-card) flow via enrollment_fields. To leave one flow untouched, pass an empty array for that side.
  • Changes take effect immediately. Validate payloads against the sandbox base URL before applying to production.
  • Each request body is validated independently; on any rule failure the whole request is rejected with a single aggregated 400 and nothing is applied. See the Publish endpoint for the full request shape, allowed values, and error catalog.

​
Errors

Validation failures return HTTP 400 with a single aggregated body listing every problem found:
Other statuses: 401 (authentication / account not allowlisted), 404 (checkout not found for the account). The full per-rule error catalog is on the Publish page.

​
Idempotency

X-Idempotency-Key is best-effort: the header is accepted and validated (up to 64 characters), but replays of the same key are not guaranteed to be de-duplicated. Design your integration for at-least-once delivery.