Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
A webhook is a notification system that allows you to receive alerts and notifications about important business process flows. You can register subscribe to events and choose to receive real-time event messages to your secured application endpoint. Such messages may save you time and effort to track the key activities that are crucial to your business.
Fusion Webhooks
A fintech can subscribe to a webhook to receive a payment event message during the payment lifecycle. The payment events are invoked when processing Acquirer, Issuer and Fusion Payment Engine communicate with each other internally to process online or card payments. Using webhooks, you can also register for various business process flows, for example, account holder on-boarding, account transfer, KYC status, card capabilities and status, and so on.
Fusion webhooks are designed to send notifications to your application when a fintech-defined event occurs as a result of business flow. You can subscribe to various account- and transaction-related events and take necessary actions when they occur. Fusion sends a secure message containing the webhook payload in JSON format. For example, you can notify an account holder about a payment failure (using SMS/email) when a transaction at an apparel store declines due to insufficient balance.
Webhook flow
You can get started with webhooks using the following basic steps:
- Set up a webhook endpoint and the environment to handle the webhook data on your platform.
- Share this endpoint with Zeta. Zeta will register the webhook endpoint in Fusion platform and share a secret token with you to validate the incoming webhook messages.
- Using Fusion APIs, subscribe to an event and receive the notification to your webhook endpoint.
Info |
---|
We also provide back office tool that allows fintechs to configure webhook communication and create policies related to event-based notifications. Contact Zeta Sales for more info. |
Supported events
The table below lists all payment and A2A transfer events that you can subscribe to and receive the event notification using Webhooks. the following event notification using webhooks. Fusion events are grouped under a topic identifier which will be passed in the body of the webhook. Keep watching this page for more supported events that you can add can add into your webhooks based on the business process flow.
Payment events
Event ObjectTopic | Event TypeName | Short Description | |
---|---|---|---|
PaymentResource | PAYMENT_REQUESTED | Appears when a new payment request is createdreceived. | |
PAYMENT_AUTHORIZATION_REQUESTED | Appears when a payment plan is created for the new payment request and the plan is submitted for authorization. | ||
PAYMENT_AUTHORIZATION_RECEIVED | Appears when a new payment request plan is successfully authorized and a payment plan is prepared. | ||
PAYMENT_EFFECTED | Appears when a new the payment request entries (as per payment plan) is successfully posted in the system. | ||
PAYMENT_CAPTURED | Appears when the response to a new payment request is successfully captured and acknowledged by the network or requesting entity. | ||
PAYMENT_REVERSED | Appears when a reversal payment transaction request has been reversedcaptured. | ||
PAYMENT_REQUEST_DECLINED | Appears when a payment request is declined and a failure response for an invalid payment request is returned. | Account transfer |
Resource events
Event Topic | Event Name | Short Description |
---|---|---|
Resource | RESOURCE_CREATED | Appears when a new resource is created. |
RESOURCE_UPDATED | Appears when an existing resource is updated. | |
RESOURCE_DELETED | Appears when an existing resource is marked as deleted. |
Form Factor events
Event Topic | Event Name | Short Description |
---|---|---|
Resource | FORM_FACTOR_PROVISIONED | Appears when a new form factor is provisioned. |
FORM_FACTOR_ASSOCIATED | Appears when a pre-created form factor is associated with a resource. | |
FORM_FACTOR_UPDATED | Appears when an existing form factor is updated. | |
FORM_FACTOR_DELETED | Appears when an existing form factor is marked as deleted. |
Card events
Event Topic | Event Name | Short Description |
---|---|---|
CSKU | ORDER_RECEIVED | Appears when a new card order is created. |
CARD_REQUEST_GENERATED | Appears when a new card request is generated. | |
EMBOSSING_FILE_PENDING | Appears when an active card's embossing file is yet to be prepared. | |
EMBOSSING_FILE_GENERATED | Appears when an active card's embossing file is generated. | |
ORDER_COMPLETED | Appears when an active card order is completed. | |
ORDER_CANCELLED | Appears when an existing card order is marked as cancelled. |
Account events
Event Topic | Event Name | Short Description |
---|---|---|
Account | ACCOUNT_UPDATED | Appears when an existing account status is transitioned, for example blocked or closed. |
A2ATransfer | TRANSFER_CREATED | Appears when an A2A transfer has been created. |
Standard event structure
Event attributes
A typical incoming webhook notification contains the following event attributes.
Attribute | Description |
---|---|
topic | Fintech-specific object to which the event is emitted from a business logic |
name | String identifying the specific type of this event |
eventId | Unique identifier of the event |
source | Description of the source entity emitting the event |
source.uri | URL format identifying the entity emitting the event |
source.tags | Array of fintech tag URIs that specify the fintech access to the source objects and resultant events |
source.state | State of the object when the event is emitted. |
data | JSON payload (less than 2 KB size) that gives information about the specific change that triggered this event |
origin | Description of the service instance emitting the event |
origin.instance | URL identifying the app instance emitting the event |
origin.time | Time at the origin when the event is emitted (in epoch milliseconds) |
origin.flowId | Unique identifier of flow from which the event is emitted |
Event sample
Below is an example of a standard event structure:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
{ "topic": "Fintech specific object", "name": "event name", "eventId": "event identifier", "source": { "uri": "entity source URL emitting the event", "tags": [ "tag://vbo/v0001", "Fintech tag that has access to the source objects" ], "state": "object state when an event is triggered" }, "data": {event details covering the key changes}, "origin": { "instance": "app URL emitting the event", "time": "event generation time in epoch millis", "flowId": "uuid of flow from which the event is emitted." } } |
Related articles
HTML Table | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||
|
Panel | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|