Developers1 min read
Webhooks are the reliable way to follow a transaction. This guide explains how to treat them; the event catalogue itself lives in the webhook documentation.
Consuming events safely
- Verify the signature on every request before you read the body.
- Acknowledge quickly and process asynchronously — slow handlers cause redelivery.
- Treat delivery as at-least-once and key your processing on the event identifier.
- Treat the event as a state signal and read the transaction if you need the full record.
Mapping events to your model
Map incoming state changes to the same lifecycle your operations team reads — payment safeguarded, ready for fulfillment, awaiting buyer confirmation, release pending, settlement released, plus the exception states. See Understanding transaction states.
Catalogue and security
The event catalogue and delivery behaviour are in the webhook documentation; signature verification is documented in webhook security.
Go deeper
Related guides
DevelopersRetries and idempotencyHow to make transaction creation and webhook handling safe under retries and redelivery.DevelopersAPI overviewWhat the ArosaPay API covers, how it is authenticated, and where the full reference lives.Start hereUnderstanding transaction statesA plain-language map of every state a transaction can show, and what each one means for you.
Last updated