Skip to main content
BETA. Endpoints are stable in shape but subject to additive changes during the BETA window.
The Checkout Builder Management API lets you read and update a merchant’s checkout configuration:
  • 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, dark mode, render mode, payment-method list layout, 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 must include:
Credentials must have the v1/checkouts product permission enabled — READ for GET endpoints, WRITE for PATCH endpoints. Permissions are granted per-credential in the dashboard’s API Keys page.

​
Endpoints

​
Key behaviors

PATCH /v1/checkouts/{checkout_code}/publish is a sparse upsert, 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.
  • Order is driven by order_to_show, not by array position. Change the integer values to re-order; lower values are shown first.
  • Including conditions_to_override replaces that method’s condition sets in full. Omitting it leaves existing conditions intact. The same rule applies to required_fields_to_override and general_settings.
  • Changes take effect immediately. Validate payloads against the sandbox base URL before applying to production.
  • New payment-method rows cannot be created via the publish endpoint. Methods must already exist on the checkout. Contact your Yuno TAM to add additional methods.
  • Enrolled and non-enrolled flows are independent. When configuring required fields for CARD, send both fields (non-enrolled) and enrollment_fields (enrolled). To leave one flow untouched, pass an empty array for that side.
  • active_enrollment_type only applies to type: "PAYMENT_METHOD" entries that support enrollment (e.g. CARD). For type: "ENROLLMENT" entries (e.g. PAYPAL_ENROLLMENT, NU_PAY_ENROLLMENT), omit active_enrollment_type and toggle is_active instead.
  • Required-field conditions: only the first set is persisted. Within required_fields_to_override.fields[].conditions_to_override (and the enrolled equivalent), only the first element of the array is stored. Send a single condition set per field — additional sets are silently dropped.
  • conditions_to_override at the required-field level uses condition_value (not values) on each condition object. Same concept as payment-method conditions — different field name preserved for backward compatibility. Don’t mix them up.