Request timeouts
Public endpoints sit behind an ingress that enforces a request timeout of approximately 60 seconds. A request that runs longer is terminated with 504 Gateway Time-out. Yuno’s internal target ceiling per call is 56 seconds, leaving headroom for response handling. A small number of legacy provider integrations may exceed the gateway window. Treat 60 s as the practical upper bound for any single synchronous call, design retries to be safe (see Avoiding duplicates), and rely on webhooks for any flow that may take longer.
Async payment flows
Several payment method families return 200 OK with transaction_status: "PENDING" from POST /v1/payments and deliver the final status (SUCCEEDED, DECLINED, EXPIRED, ERROR) via webhook events once the provider settles. Do not treat the synchronous response as final for these flows. Reconcile against webhooks, or GET /v1/payments/{id} as a fallback. Methods that commonly behave this way:
| Family | Examples |
|---|
| Bank transfer / instant payment networks | Pix and Pix Automático (Brazil), PSE and BreB (Colombia), SPEI (Mexico), Khipu and Fintoc (Chile), Belvo Direct Debit (Mexico). UPI (India) when using the redirect or collect flow. |
| Direct debit | SEPA Direct Debit, ACH Direct Debit (multi day settlement). |
| Cash vouchers and tickets | Boleto Bancário (Brazil), OXXO (Mexico), PagoEfectivo and Servipag. |
| Crypto | All crypto payments. |
PENDING is also returned for synchronous flows that need a follow up action, most commonly 3DS authentication and REDIRECT_URL on card or wallet methods. In those cases inspect require_action_type and require_action.redirect_url, complete the action client side, and treat the eventual webhook as the source of truth.
See also
