Offers API webhooks
Which webhooks should I listen to when using the Offers API?
The Offers API utilises certain events which fire each time a transaction qualifies for an offer created in your account. These are as follows:
transaction.auth.qualified
transaction.clearing.qualified
transaction.refund.qualified
As referred to above each event will only fire should the transaction meet an offer criteria.
Given this example: the account contains active offer contains a schedule with a 10% discount off purchases made Monday to Friday. If a transaction tracks on a Saturday then this would fall outside of the pre-determined schedule with no message being sent to you.
An added nuance can come into play where you decide to also listen to the core transaction webhooks which are:
transaction.auth
transaction.clearing
transaction.refund
These events will not listen to offers qualified within the account, therefore will always trigger should an enrolled card purchase at an onboarded location.
You may wish to listen to both sets if, for example, you are running multiple offers for each brand, such as having an always-on offer in tandem with a more defined one.
The key factor here is for the client to build additional logic on their side in terms of recognising when they should reward on a message received from Fidel API.
Offer charges
Will I still be charged for a transaction that has not qualified for an offer that I have created in the platform?
Fidel is charged for each transaction that is sent to us by the card schemes irrespective of whether that transaction has qualified or not. Therefore, the charge will still be applicable to you regardless of what your webhook setup is i.e. if you are only listening to the offers webhooks and don't receive the data to your application.
Offer data in webhook
At what point does ‘offer’ data become available in the refund processing webhook?
The presence of the “offer” data depends on the webhook being used. If the you are referring to the transaction.refund.qualified webhook, this should always include the “offer” object in the refund transaction, as this webhook is triggered by refund transactions done on locations linked to offers. However, if the webhook in question is transaction.refund, this one does not require that the refund is connected to an offer, meaning it may or may not contain the “offer” object, even if the location where the refund was done is connected to an offer. As for the “originalTransactionID”, it is included in refund notifications when we can identify the original transaction associated with the refund, we cannot guarantee the match of these transactions because most of the cases we do not receive information matching original transactions from the card networks.