Webhook attributes
The JSON attributes for Yuno webhooks are listed below. See Events and Triggers for the trigger field that selects each event.string
The unique identifier of the account in Yuno (MAX 64, MIN 36).
string
Specifies the notification type.
string
Specifies the event notification type.
string
Specifies the version of the webhook sent. Currently 2.
string
Specifies the number of retries for that notification.
object
Specifies the payment (for payment type) or payment method object (for enrollment and other objects).
string
Optional. The HMAC-SHA256 signature sent in the HTTP header for webhook verification when HMAC authentication is enabled.
Split update webhooks
These abbreviated examples show only the fields needed to interpretpayment.split_update; the normal payment fields are also included. This event requires explicit subscription and is pending production catalog availability.
In v2, the envelope identifies type_event: "payment.split_update", and the operation block is data.split_update:
split_marketplace is []. An applied replacement carries that operation’s split entries instead. transactions is a single object, not an array.
Legacy v1 sends the payment body without the v2 envelope or type_event. Identify this event by the split_update block next to payment:
If
transactions_history is enabled, its entry for the affected transaction carries the same operation split. The event does not enable history or replace the payment-level payment.split_marketplace; do not use that payment-level field as this operation’s snapshot. Other fields reflect the payment read when the notification is prepared and may include later changes. Use GET /v1/payments/{payment_id} for the latest payment state.
The operation snapshot is not guaranteed to serialize identically to a later payment read. Numeric scale can differ (for example, 5 versus 5.0), and a liability object containing only chargebacks can be represented differently by the live-payment mapping. Compare values and their meaning rather than requiring byte-for-byte JSON equality. These representation differences do not identify a new split operation.
Only this event adds split_update; purchase and refund payloads do not acquire the block. See Split update notifications for subscription, emission, ordering, and delivery behavior.
Examples
Yuno provides several webhooks related to enrollment and payment notifications. Here you will find some examples of data structures related to each event.Payment Webhook V2
Payment Webhook V1
Chargeback Webhook V2
Chargeback Webhook V1
Enrollment
Payouts
Subscriptions
Onboardings
Refunds
Marketplace Split Transfers
HMAC - Authorization
Payment
Payment Webhook V2
Example payload:Webhook payloads for events corresponding to a bank transfer payment method include
payment.payment_method.payment_method_detail.bank_transfer.bank_id. The field mirrors the bank_id sent in the original payment request and is omitted when no bank was selected.When the payment carries a shipping selection — for example, picked inside a wallet widget with Fast Checkout shipping — the payload includes a top-level
payment.shipping node (same shape as on the payment object) in both V1 and V2 versions, and payment.customer_payer.shipping_address is filled from it when the payer had none. The shipping key is omitted when the payment has no selection.Each transaction includes
connection_data, which identifies the provider connection that processed it. Use connection_data.id as the stable identifier to attribute transactions to a specific connection when you operate multiple connections for the same provider. connection_data.name is the display name configured in the Yuno dashboard and can be null on some events, such as follow-up transactions.The
transactions field carries a different meaning per surface. In webhook payloads, data.payment.transactions is a single object — the transaction that triggered the event — and transactions_history carries the full list of the payment’s transactions when it is enabled for the payment (see the note below). In the payment retrieve endpoints (GET /payments/{payment_id} and GET /payments?merchant_order_id=), transactions is an array containing every transaction of the payment.transactions_history is opt-in: it is populated only when the payment was created with response_additional_data.transactions_history: true in the Create Payment request. Otherwise webhooks deliver it as an empty array [] — the default, which keeps payload sizes small. This matters for payments your routing retries across providers: without the flag, the final webhook shows only the last transaction, and the earlier attempts are only visible via GET /payments/{payment_id}. Payments created by Yuno-managed flows that do not set the flag (for example, subscription renewals) also deliver []. Chargeback events always include the full history.Field naming: the customer geolocation is serialized as
geo_location in webhook payloads and as geolocation in the payment retrieve endpoints. Parse each surface accordingly.Payments created with an
external_subscription object (see Create payment) carry it in the webhook payload as a top-level external_subscription key with id and customer_id. The key is omitted (not sent as null) when the payment was created without it, which is why the example above does not show it. Both webhook versions carry the field.When the payment carries a Yuno promotion, the payload also has
payment.discount_amount (currency and value, the total discount), placed right after amount. The Yuno discount line comes first in payment.additional_data.order.discounts (type: YUNO_PROMOTION, quote_id, id, unit_amount, and name when Yuno has it), and your own discount lines follow it with type: MERCHANT. payment.amount.value stays the amount you sent, and payment.transactions.amount is the amount charged. Without a promotion, discount_amount is omitted and the discount lines are exactly as you sent them. Both webhook versions carry the field. The excerpt below shows only the fields that change.Payment with a Yuno promotion (excerpt)
Payment Webhook V1
Example payload:JSON
Chargeback Webhook V2
Example payload:Chargeback Webhook V1
Example payload:JSON
payment.pre_chargeback
Sent when a pre-chargeback notice or fraud alert is received for a payment, ahead of a full chargeback. Currently sent to any webhook with at least onepayment_triggers value, regardless of whether PRECHARGEBACK is selected; a dedicated trigger gate is planned for a future release.
Enrollment
The next JSON object presents an example of a data structure related to an enrollment event.When an enrollment is created with
verify.external_subscription (see Enroll payment method), the object is echoed in the enrollment response and persisted on the verification payment — it is not part of the enrollment webhook payload. To correlate later, use the verification payment: its id comes back in the enrollment response (verify.payment.id) and the object is returned by Retrieve payment and in payment webhooks.Payouts
The next JSON object presents an example of a data structure related to a payout event.JSON
Reports
report_triggers subscribes to report lifecycle events. Only report.update is currently emitted by any service; report.create can be subscribed to but has no emitter yet.
JSON
Subscriptions
The next JSON object presents an example of a data structure related to asubscription.create event.
JSON
subscription.active
Sent when a subscription transitions from any other valid status intoACTIVE. Use this event to trigger post-activation processes without polling.
JSON
subscription.trialing
Sent when a subscription enters a plan’s trial phase from another status. Entering the trial at creation time is reported assubscription.create, and leaving a pause into the trial as subscription.resume.
JSON
subscription.past_due
Sent when a recurring charge fails and the subscription entersPAST_DUE. The subscription keeps billing while the retries run and can still be canceled. When a later charge succeeds it returns to ACTIVE — or to TRIALING if the trial phase is still running — and the corresponding subscription.active or subscription.trialing event is sent.
This event is only emitted for accounts where the PAST_DUE status is enabled. Where it is not, a failed charge leaves the subscription in ACTIVE and only the payment.purchase webhook reports the decline. See Subscription Status.
JSON
subscription.pause
Sent when a subscription is paused. Use this event to update the status in your system and pause related services.A paused subscription’s window is frozen where it was, not moved forward.
current_period_start/current_period_end (and current_phase_end, if the subscription is inside a phase) keep whatever window was current at the moment of pause — Yuno does not advance them while billing is suspended. The longer a subscription stays paused, the further current_period_end falls into the past; on prod, the large majority of currently-paused subscriptions already show an elapsed window. Don’t treat current_period_end as “the next charge date” without also checking status — for a paused subscription it isn’t one.JSON
subscription.resume
Sent when a paused subscription is resumed and transitions back to theACTIVE status.
JSON
subscription.cancel
Sent when a subscription is canceled. Once canceled, the subscription is terminated and cannot be reactivated. The subscription object carries acancellation_source field describing what triggered the cancellation — MERCHANT, SYSTEM, PLAN_CHANGE, or RETRIES_EXHAUSTED. See the subscription object for what each value means.
Treat
cancellation_source as open-ended. New values can be added as Yuno introduces new cancellation behaviors, so handle an unrecognized value gracefully rather than switching exhaustively over the current list. RETRIES_EXHAUSTED is the most recent addition — it is sent when retries for a billing cycle end without a successful payment on a subscription created with retries.cancel_on_exhausted_retries set to true.JSON
CANCELED, the same way a PAUSED subscription freezes its window (see the subscription.pause note).
subscription.complete
Sent when a subscription reaches its end date or total billing cycles and transitions to theCOMPLETED status.
JSON
subscription.close_to_renewal
Sent ahead of an upcoming renewal. Timing is controlled byrenewal_notification_days on the subscription.
JSON
subscription.cycle_executed
Sent for plan-based subscriptions when a$0 cycle is executed, either a trial cycle or a fully discounted one. Those cycles produce no payment.purchase webhook, so this event is the only receipt for them. reason is TRIAL or FULL_DISCOUNT, phase is the phase the cycle belongs to, and breakdown carries the same line-item detail as a paid cycle, with a zero total.
JSON
subscription.phase_completed
Sent for plan-based subscriptions when a billing phase ends, immediately before thesubscription.phase_started of the phase that replaces it. It is not sent for the first phase, which has no predecessor. phase is the phase that just ended.
JSON
subscription.phase_started
Sent for plan-based subscriptions when a billing phase begins, including the first one.phase is the phase that is starting and previous_phase is the one it replaces, or null for the first phase.
JSON
subscription.plan_change_scheduled
Sent when a plan change is scheduled for the next billing cycle. Theplan_change block describes the pending change; applies_at is the next billing date the change will take effect on.
JSON
subscription.plan_change_canceled
Sent when a pending plan change is undone or aborted. Thereason inside plan_change is MERCHANT_UNDO when the merchant sent "plan_change": null, or TARGET_PLAN_CANCELED when the target plan was canceled before the change applied — the subscription stays on its current plan in both cases. If the subscription itself is canceled, the pending change is silently discarded and only subscription.cancel is sent.
JSON
subscription.plan_changed
Sent when a plan change takes effect.previous_plan_id identifies the plan the subscription moved away from; the embedded subscription already reflects the new plan.
A scheduled change is applied at the renewal that first bills the new plan, in place — the embedded subscription keeps the same code. POST /v1/subscriptions/{id}/plan instead replaces the subscription: the payload carries a new code with previous_subscription_id set, and a separate subscription.cancel (cancellation_source: PLAN_CHANGE) fires for the original.
JSON
subscription.cancel_scheduled
Sent when a cancellation is scheduled viaPOST /v1/subscriptions/{id}/cancel with a schedule block. cancel_scheduled describes the pending schedule — see Cancel Subscription.
JSON
subscription.cancel_schedule_canceled
Sent when a pending scheduled cancellation is undone via"schedule": null on POST /v1/subscriptions/{id}/cancel. Not sent when the schedule instead fires — subscription.cancel fires then.
JSON
Renewal charges and failures (no subscription.error)
The renewal charge itself is always signaled by a
payment.purchase webhook, never by a subscription webhook. The payments array inside the subscription object is currently always empty in webhook payloads. subscription.active is sent when the subscription first becomes active (at billing_cycles.current = 2), not on every renewal — it is sent again only when a subscription recovers from PAST_DUE.A failed renewal does produce a subscription webhook in two cases. Where the
PAST_DUE status is enabled for the account, the first failed charge of a cycle moves the subscription to PAST_DUE and emits subscription.past_due. And if the subscription has retries.cancel_on_exhausted_retries set to true, then once retries for that cycle end without a successful payment the subscription is canceled and a single subscription.cancel is emitted with cancellation_source set to RETRIES_EXHAUSTED. This is still not a subscription.error — the individual failed attempts remain payment.purchase webhooks. Only the final cancellation is signaled on the subscription.Onboardings
The next JSON object presents an example of a data structure related to an onboarding event, in this caseonboarding.error.
Example
Marketplace Split Transfers
Standalone transfer notifications include the saveddirection at the top level of the delivered JSON body. Existing transfers use PLATFORM_TO_RECIPIENT. Recipient-to-platform availability follows the create endpoint.
The examples below show selected fields from the delivered body. The headings are the subscription event types; the delivered body is the transfer object itself, without an envelope and without an event-type field. Identify a reversal notification by its status (REVERSED or REVERSED_PARTIAL) and by a transaction of type SPLIT_TRANSFER_REVERSE. provider_data describes the provider account that processed the transfer; each transaction’s raw_response carries the provider’s raw response, JSON-serialized as a string.
Per engineering, the
type_event these two events are recorded under internally is transfer.transfer — the delivered webhook body itself carries no type/type_event envelope, as noted above.split_transfer.succeeded
Sent when a marketplace split transfer completes successfully.split_transfer_reverse.succeeded
The notification identifies the original transfer, retains its direction, and includes both the original and reversal transactions. In this partial-reversal example,status is REVERSED_PARTIAL and amount is the USD 1 reversal amount. The reversal transaction points to the original transaction through parent_transaction_code. This notification is distinct from the reversal HTTP response, which does not include direction. It is delivered under the original transfer’s id; description and merchant_reference carry the values sent in the reverse request.
Refunds
The next JSON object presents an example of a data structure related to apayment.refund event.
Example
HMAC - Authorization
The next example shows a raw webhook request with thex-hmac-signature header Yuno includes when HMAC authentication is enabled.