Use this webhook reference to understand the event sent when a refund reaches its completed state so your application can finalize internal records, notify users, and reconcile the refund outcome safely.
When this webhook is useful
Use this event when your integration needs to:
- detect that a refund has completed successfully
- update internal refund records to a final completed state
- notify customers, operators, or downstream systems that the refund is finished
- reconcile the refund outcome against the original payment or wallet movement
Before you rely on this event
Complete these steps first:
- Configure a public webhook endpoint that can receive and acknowledge Verto events.
- Store the refund identifiers and internal references tied to the original payment or transaction.
- Decide which internal systems should be updated when a refund becomes final.
- Make sure your webhook handler can process duplicate deliveries safely.
What this event means
When this webhook is sent, the refund has reached its completed state in the Verto lifecycle.
Typical implications include:
| Event meaning | Why it matters |
|---|---|
| Refund completed | Your application can treat the refund as finalized according to the relevant business workflow. |
| Final-state transition occurred | Finance, operations, and customer-facing systems can stop treating the refund as in progress. |
| Reconciliation can be finalized | Internal references can be matched to the completed refund outcome. |
Event type contract in v1.1
The current documented eventType value for this webhook in v1.1 is:
refund.completed
Use this value when routing webhook events in your application.
If you have older logic looking for a different refund event name, update it to match the v1.1 payload contract before going live.
Event type contract in v1.1
The current documented eventType value for this webhook in v1.1 is:
refund.completed
Use this value when routing webhook events in your application.
If you have older logic looking for a different refund event name, update it to match the v1.1 payload contract before going live.
How to handle this webhook safely
- Acknowledge the webhook quickly with a successful response before running longer internal logic.
- Deduplicate deliveries using your event ID or internal correlation logic.
- Match the payload back to the original payment, refund record, wallet movement, and your own internal references.
- Update your internal refund record only once for the final completed state.
Common implementation notes
- Use this event as the primary asynchronous signal that a refund has finished.
- Do not rely on the refund initiation response alone for final-state confirmation.
- Keep the original payment identifier, refund identifier, wallet or payout context, and internal reference linked in your system.
- If customer notifications depend on final refund completion, trigger them from this event rather than from the initial refund request.
Related workflow
This event is typically part of the following sequence:
- A refund is initiated from the relevant payment or wallet workflow.
- The refund moves through internal processing states.
- Receive the refund completion event.
- Finalize internal reconciliation, customer notifications, and downstream updates.
Next steps
- Continue to Webhooks for the broader webhook lifecycle and delivery model.
- Continue to Webhook Event Handling for implementation examples and event-routing guidance.
- Continue to Payments for broader payment lifecycle context where refunds are part of downstream operations.
Refund webhook received