Webhook Events - HopNow API

Webhook endpoints can subscribe to the following event types:

Event	Entity	Description
`deposit.received`	deposit	An incoming deposit was received.
`deposit.returned`	deposit	An incoming deposit was returned.
`payment.created`	payment	A payment was created.
`payment.completed`	payment	A payment settled successfully.
`payment.failed`	payment	A payment failed before leaving the account — a processing failure or a review rejection; funds were never taken and any hold is released back to the available balance. `data.status` carries the precise state (`failed` or `rejected`).
`payment.returned`	payment	A payment was returned by the receiving bank (e.g. invalid or closed account, compliance rejection). May fire after `payment.completed` — on a post-settlement return the funds are credited back to the account balance.
`account.created`	account	An end-customer account was created. The payload is the account summary: `id`, `customer_id`, `type`, `kyc_status`, `display_name`, `contact_email`, `country_code`, `rejection_reasons` and the audit timestamps. The `onboarding`, `requirements`, `associated_persons` and `individual` blocks are always `null` on webhook payloads — call Get Account to read them.
`account.updated`	account	Hop changed the account’s verification state — KYB submission, review outcome (e.g. `under_review` → `approved`, `action_needed`, or `rejected`), a submission reopened because the verification provider rejected a document (`onboarding.submission_status` returns to `not_ready`; check `requirements.issues`), an admin action, or an associated person’s verification progress. Client-initiated writes (Update Account, uploads) do not fire it — re-fetch Get Account after your own writes to see requirements progress. The payload is the account summary (`kyc_status` and `rejection_reasons` included); the `onboarding`, `requirements`, `associated_persons` and `individual` blocks are always `null` on webhook payloads, so call Get Account on receipt to read the reopened `onboarding.submission_status` and `requirements.issues`. No identity information is ever sent in a webhook payload.
`virtual_account.created`	virtual_account	A virtual account was provisioned. It is emitted once the partner bank has issued the account, so the payload carries the full virtual-account object with `status: active` and complete bank details — this is the event to act on when you want to surface deposit instructions.
`virtual_account.updated`	virtual_account	A virtual account was disabled. The payload is the full virtual-account object — the same shape as Get Virtual Account. Activation is not signalled here: provisioning is synchronous, so use `virtual_account.created` (or the Create Virtual Account response) for the active account and its bank details.