Webhooks Overview

What is a webhook

Webhooks enable apps to provide real-time information whenever an event happens without needing constant requests. They are a passive method to receive data between two systems through an HTTP POST. After configuring the Yuno webhooks, you will receive event notifications every time an activity or a function is generated within the Yuno flow.

Why do we recommend you use webhooks?

Webhooks are the best way to ensure your system is up-to-date with payment progress and status. Since the event notifications trigger automatically, your system won't need to perform recurrent requests to Yuno. You will process the payment information on demand.

What do you need to know before start using webhooks?

To start using Yuno’s webhooks, you need to build a public REST API to receive event notifications (POST request). That means the REST API you will build should not require any authentication or access restriction through a header. Despite using a public API, the communication system is very safe since Yuno event notifications will not be available to the public and will use a unique URL to communicate only to your REST API.

Webhooks delivery and response requirements

Yuno webhooks expects to receive an HTTP 200 OK status as a response to confirm the webhook was successfully received. The merchant system does not need to include any information in the response's body. Only the HTTP 200 status is required.

If no response is received within the specified time, Yuno will retry sending the event notification up to seven times to ensure no information is lost. Refer to the Receipt Confirmation Process section for details on the notification schedule and confirmation waiting times for each retry.

Banking Connectivity webhook events

Banking Connectivity (Banking as a Service) webhook notifications follow the same delivery and retry behavior described above. Yuno sends these events to your configured webhook endpoint when the status of a Banking Connectivity resource changes.

For incoming transfer payload structure, see Webhook Notifications (Banking Connectivity). Incoming transfer notifications are sent to your endpoint at {merchant_base_URL}/v1/banking/transfers.

Entity events

Event	Description
`banking.entity.created`	Entity created
`banking.entity.updated`	Entity updated
`banking.entity.deleted`	Entity deleted

Onboarding events

Event	Description
`banking.onboarding.created`	Onboarding created
`banking.onboarding.pending`	Submitted, awaiting review
`banking.onboarding.pending_additional_documentation`	More documents required
`banking.onboarding.succeeded`	Onboarding approved
`banking.onboarding.failed`	Onboarding failed
`banking.onboarding.declined`	Provider declined
`banking.onboarding.cancelled`	Merchant cancelled
`banking.onboarding.expired`	Onboarding expired

Account events

Event	Description
`banking.account.created`	Account created
`banking.account.updated`	Account updated
`banking.account.activated`	Account activated
`banking.account.closed`	Account closed

Transfer events (outgoing)

Event	Description
`banking.transfer.pending`	Transfer pending
`banking.transfer.processing`	Transfer processing
`banking.transfer.completed`	Transfer completed
`banking.transfer.failed`	Transfer failed
`banking.transfer.cancelled`	Transfer cancelled
`banking.transfer.reversed`	Transfer reversed

Transfer events (incoming)

Event	Description
`banking.transfer.incoming.pending`	Incoming transfer pending settlement
`banking.transfer.incoming.completed`	Incoming transfer settled

Marketplace Split Transfer events

Event	Description
`split_transfer.created`	Split transfer created
`split_transfer.succeeded`	Split transfer succeeded
`split_transfer.failed`	Split transfer failed
`split_transfer_reverse.created`	Split transfer reversal created
`split_transfer_reverse.succeeded`	Split transfer reversal succeeded
`split_transfer_reverse.failed`	Split transfer reversal failed