Toggle navigation

Figg Developer API

Events

The Figg API also supports the ability to call back webhooks when certain events occur in the system to either:

  • Users your application has onboarded
  • Businesses your application has onboarded
The goal of this is to provide realtime feedback when certain events occur such as when a user has transacted at business.

The major notes of the events API are as follows:

  • All events are wrapped by an event object (Event).
  • Your web application can have one hook associated with it. Please email support@mogl.com to configure this.
  • The payload type will always be "application/json".
  • All requests are POST requests.
  • The system expects 200 responses. Any other responses will be considered a failure. (See below).
  • Figg will *SIGN* the payload using an hmacsha256. The key will be the private key assigned to your application. This signature is stored in an http header "NotifySignature".

Current Events

The below list summarizes the current supported events:

  • Transaction authorization (AUTHORIZED) - Sent whenever a consumer transacts.
  • Transaction clearing (CLEARED) - Sent in batches everday when the transaction settles.
  • Transaction removal (REMOVED) - If we do not receive a settlement within 7 days OR we remove a transaction for some other reason (e.g. fraud) a removal notification will be sent.
Note that all transaction events will use the same unique identifier for each individual transaction. For example, if an authorization is sent for transaction id 12345 then the clearing id will be 12345.

New events will be added to the notification API so your system should be constructed to be tolerant of new events/fields being added ot the event object.

Pro Tip: your application should be designed to be idempotent. If it receives the same authorization from our system multiple times (e.g. because of a network failure/configuration issue) your system should properly account for this.

Responses to Event Hooks

Figg expects that the response code returned to be a "200". There will be no attempt to parse the response body. If Figg receives a status code other than a 200 or there is some network/io failure in the request then Figg will queue the notification and attempt to send the notification again. The notification retry interval will increase with subsequent failures. If a request is not successfully sent within 5 attempts we will not attempt further notifications.