Yuno Checkout Flow
Yuno has two checkout flows that behave differently with respect to order creation:
- One-off (OTT): the Farfalla order is created before the Yuno payment call, like every other gateway.
- Subscription (recurring): the Farfalla order is created inside the recurring payment service, after the user completes the Yuno checkout step.
This doc focuses on what makes the subscription path different. The OTT path is conventional and needs no special handling.
There is one Yuno SDK integration; the surface area below describes three distinct flow types, not three libraries.
Standard flow (Stripe, MercadoPago, Yuno OTT)
For non-Yuno gateways and for the Yuno one-off path, checkout runs synchronously before the redirect:
User clicks Pay
→ Order created (status=pending)
→ Gateway session created
→ User redirected to gateway
→ User completes payment
→ Callback/IPN arrives → Order approved
The order exists before any webhook fires. The Yuno OTT path follows this shape: the order is created first, and only then is Yuno called with the OTT token.
Yuno subscription flow
For the Yuno subscription path, the recurring service creates the order as part of the same call that submits the subscription to Yuno:
User clicks Pay (subscription)
→ Yuno recurring service: create subscription
→ Order created here
→ Yuno subscription submitted with vaulted token
→ IPN arrives
→ Payment row stored; order status updated
The IPN handler stores a payment row and updates the order's status. It does not create the order. The order already exists when the IPN arrives.
Three flow types
Yuno integration spans three distinct flow types, each handling a different payment lifecycle:
- One-off: standard OTT (one-time token) flow. Order is created before the payment call.
- Recurring (initial charge): vault-on-success. The first charge is a one-off that also captures a vaulted token for future cycles.
- Recurring (subsequent cycles): Yuno charges the subscription autonomously per its configured frequency. Farfalla does not issue charge calls for these cycles;
CheckYunoRecurringPaymentsonly reconciles state (pauses or cancels orders when expected payments are missing).
This is why the Yuno integration has more surface area than Stripe or MercadoPago integrations.
Recurring subscriptions
Yuno owns the billing cadence. Frequency and retry policy are set once when the subscription is created; from then on, Yuno issues each cycle's charge on its own schedule and notifies Farfalla via IPN. Each successful charge becomes a new payments row through the standard IPN ingestion path.
CheckYunoRecurringPayments (every 5 minutes) is a reconciler, not a charger. It compares the number of approved payments to the number expected for each active subscription and pauses or cancels the Farfalla order when the count is behind. It never calls the Yuno charge API. MercadoPago has an equivalent reconciliation job on the same cadence.
Implications
| Scenario | Stripe / MP / Yuno OTT | Yuno subscription |
|---|---|---|
| Order exists before payment call | Yes | Yes (created at the same call) |
| Order exists before IPN | Yes | Yes |
| Polling job for recurring | MP and Yuno have one (5 min); Stripe does not | Yes (5 min) |
Yuno IPN handlers store payment rows and update order status; they do not create orders. If a Yuno IPN cannot find its order, treat it as an error condition, not an expected state.