Boarding Webhooks
Boarding webhooks notify you about merchant onboarding status changes and specific boarding process events.
Event Context: trigger and reason
Every merchant.* payload carries two fields describing how and why the change happened. The event type tells you the state the merchant is now in; these tell you what caused it.
Why this matters
Four different things can produce a merchant.new event:
Previously all four arrived as an indistinguishable merchant.new. If your integration takes action on merchant.new — creating a record, notifying a team — branch on reason rather than treating every occurrence as a brand-new application.
reason values
created · sent_for_signature · resent · retracted · updated · signed · in_underwriting · boarded · live · cancelled · declined · signature_expired · deleted · status_changed
Treat reason as open-ended, not a fixed enum. status_changed is a fallback for transitions with no more specific meaning, and new values may be added over time. Ignore a value you do not recognise rather than failing on it.
Resending emits a single event
Re-sending an application that is already out for signature retracts the outstanding link and issues a fresh one. That produces one event — merchant.sent_for_signature with reason: resent — not a merchant.new followed by a merchant.sent_for_signature.
A first send from new also produces one merchant.sent_for_signature, with reason: sent_for_signature. So the event type is the same either way, and reason tells you whether a previous link was replaced.
There is no way to suppress webhooks for an individual request. The event stream is the record of what happened, so silencing it for one caller would leave other subscribers out of sync. Use trigger and reason to decide which events your integration should act on.
Merchant Status Events
The following webhooks are triggered when a merchant’s status changes during the boarding process. Each payload also carries trigger and reason — see Event Context above.
merchant.new
Triggered when merchant status changes to “New”.
merchant.sent_for_signature
Triggered when merchant status changes to “Sent For Signature”.
merchant.signed
Triggered when merchant status changes to “Signed”.
merchant.in_underwriting
Triggered when merchant status changes to “In Underwriting”.
merchant.boarded
Triggered when merchant status changes to “Boarded”.
merchant.live
Triggered when merchant status changes to “Live”.
merchant.cancelled
Triggered when merchant status changes to “Cancelled”.
merchant.declined
Triggered when merchant status changes to “Declined”.
merchant.unknown
Triggered when merchant status changes to “Unknown”.
merchant.deleted
Triggered when merchant record is deleted from Partner.
VAR Complete Event
boarding.varcomplete
Triggered when the TSYS VAR Only process is complete.
Integration Tips
- Status Tracking: Maintain merchant status in your system based on webhook events
- Automated Communications: Send status updates and next steps to merchants automatically
- Team Notifications: Alert sales and support teams about status changes
Error Handling
Handle potential issues in boarding webhooks:
- Missing Data: Some optional fields may be null depending on application completeness
- Status Transitions: Ensure your system can handle status changes in any order
- Duplicate Events: Use idempotency keys to prevent duplicate processing