Webhooks

You can configure your account to receive notifications via a webhook by following the steps below:

Webhook Sending / Procedures

Checkissuing does not check the reply to webhooks, we only check for general deliverability. If we receive an http status code of 200 or another indicator that it was received properly, we mark it as successful on our end and do not try to resend. If we get an error indicating that it was not received ok, we will attempt to resend the webhook in question.

We try to resend a webhook up to 10 times. How often depends on our queuing system, what we have queued, the current stuff that’s queued’s priority (in relation to it), & a variety of other factors however there is a minimum of a 5 minute delay between attmpts. On average a webhook will retry every 5-10m (usually closer to 5) but there’s no exact way to tell at any given time the exact interval.

After 10 attempts, we mark it as undeliverable and it will be stored in our queue as such for up to 2 days, so if for whatever reason we need to, we can go back up to 2 days and force it to retry those if we are notified/it is requested.

Verifying Webhook Authenticity

Checkissuing can include HMAC-SHA256 signatures when sending webhooks that allow you to validate their authenticity. In order to enable this, login to your account and go to Settings > Options. You will see an input labelled 'Webhook Signature Secret'. Enter a secure/secret string here and click the 'Save Changes' button. This sets your Webhook Secret to the string you provided, once this is set, all webhooks sent will include two additional HTTP headers, CI-Signature-Timestamp and CI-Signature.

In order to validate received webhooks, generate a HMAC-SHA256 hash by concatenating the value of CI-Signature-Timestamp, a '.', and the webhooks json data (as a string), using your Webhook secret as the key. If this hash matches the value of the CI-Signature header, the webhook is authentic/valid.

Available Webhooks

Below is a list of webhooks that get sent with an example for each.

payment_added

Sent when a payment is added

{"event_type":"payment_added","payment_id":323,"payee":"Some Payee","amount":"5.00"}
payment_flagged

Sent when a payment is flagged

{"event_type":"payment_flagged","payment_id":323}
security_alert

Sent when there is a security alert

{"event_type":"security_alert","alert_text":"Description of the alert in question"}
user_added

Sent when a user is added

{"event_type":"user_added","user_id":323,"username":"AUser"}
payment_updated

Sent when a payment is updated

{"event_type":"payment_updated","payment_id":323}
payment_status_change

Sent when a payments status changes

{"event_type":"payment_status_change","payment_id":323,"new_status_id":4}
payment_needs_repaired

Sent when a payment needs repaired

{"event_type":"payment_needs_repaired","payment_id":323,"errors":"Errors with the payment"}
payment_tracking_status

Sent when a payments tracking status updates. Includes full tracking information (See Sample Payment Tracking Response)

{"event_type":"payment_tracking_status","payment_id":323,"tracking_info":"[Tracking Info]"}