Webhook body examples

Every webhook from the simplified process (see Registering webhooks) includes a body with minimal information. For a tutorial about how to get these webhooks, see Receiving webhooks.

This section contains examples of the content returned in the body of a webhook response.

Account events

The webhook body is shaped the same for all account events in the simplified webhook workflow.

Processor onboarding eventType

Each webhook contains the following parameters:

  • eventType
  • credsReady
  • pendingItemsUpdatedAt
  • applicationStatus
  • onboardingId
  • repCode

After registering the webhook URLs for reseller accounts, a webhook gets sent every time a change is made for a merchant application associated with the reseller. For example, after the application has been signed by the underwriting team and is ready for the next step, the applicationStatus changes to Underwriting Signed. Any time a change is made, including even something like changing the merchant name, a webhook gets triggered.

📘

Note

For onboarding applications, the body of the webhook contains only a small subset of the possible parameters for an application. To view the values for all the available parameters of the application indicated in the webhook, use the onboardingId value with the View application by onboarding ID endpoint.

{
  "eventType": "PROCESSOR_ONBOARDING",
  "credsReady": false,
  "pendingItemsUpdatedAt": null,
  "applicationStatus": "App Created",
  "onboardingId": "16c3d4c3673f3b5193e56a651df0d3e4",
  "repCode": "123Z"
}

Transaction events

The webhook body is shaped the same for all transaction events in the simplified webhook workflow.

Transaction eventType

For the TRANSACTION event type, each webhook contains the following parameters:

  • eventType - Specifies the type of event returned. For example, TRANSACTION.
  • transactionStatus - For details about the possible values, see the Transaction status reference tables.
  • processMethod - For details about the possible values, see the Process method reference table.
  • transactionId

📘

Note

For transactions, the body of the webhook contains only a small subset of the possible parameters for a transaction. To view the values for all the available parameters of the transaction indicated in the webhook, use the transactionId value with the View transaction by transaction ID or the View transactions endpoint (as id or transactionId (within any query parameter object)).

{
  "eventType": "TRANSACTION",
  "transactionStatus": 10,
  "processMethod": 10,
  "transactionId": 211302211
}

Use the webhook response to determine how to react. For example, the processMethod shows whether the transaction was card-based, echeck, alternative payment method (APM), or something else. If you wanted to ignore all webhooks related to APMs, you would look for any webhook with a value of 20 and then ignore it.

Decline recovery eventType

For the DECLINE_RECOVERY event type, each webhook contains the following parameters:

  • eventType - Specifies the type of event returned. For example, DECLINE_RECOVERY.
  • retryId - Specifies the identifier for the declined transaction.
  • orderNumber - Specifies the orderNumber for the transaction.

📘

Note

For declined transactions, the body of the webhook contains only a small subset of the possible parameters for a transaction or the declined information.

In order to see more about a declined transaction, use the retryId value in the path parameter of the View a decline recovery record endpoint.

In order to find more information about the original transaction, use the orderNumber value in the View transactions endpoint by using that order number value in the plugin.orderNumber query parameter.

{
  "eventType": "DECLINE_RECOVERY",
  "retryId": 43118,
  "orderNumber": "45928c5ae6105e6a02ba"
}

Payout events

The webhook body is shaped the same for all payout events in the simplified webhook workflow.

Each webhook contains the following parameters:

  • eventType
  • payoutStatus - For details about the possible values, see the Payout status reference table.
  • transferStatus - For details about the possible values, see the Transfer status reference table.
  • payoutId
  • payoutRef

After registering the webhook URLs for payouts, a webhook gets sent every time a recipient accepts your payout to them through the Interchecks payout provider. For example, after the recipient accepts the payout, the data.transferStatus changes to 20.

For information about payout events with other payout providers, contact Integrations Support.

📘

Note

For payouts, the body of the webhook contains only a small subset of the possible parameters for a payout. To view the values for all the available parameters of the payout indicated in the webhook, use the payoutId value with the View a payout endpoint or use the payoutRef value with the View payouts endpoint.

{
  "eventType": "PAYOUT",
  "payoutStatus": 20,
  "transferStatus": 20,
  "payoutId": 2437652,
  "payoutRef": "dfbb8efc-6e85-4973-8f2e-69baf8624ae6"
}

Spendback events

The webhook body is shaped the same for all spendback events in the simplified webhook workflow.

Each webhook contains the following parameters:

  • eventType
  • spendbackStatus - For details about the possible values, see the Spendback status reference table.
  • spendbackId
  • spendbackRef

📘

Note

For spendbacks, the body of the webhook contains only a small subset of the possible parameters for a spendback. To view the values for all the available parameters of the spendback indicated in the webhook, use the spendbackId value with the View a spendback endpoint or use the spendbackRef value with the View spendbacks endpoint.

{
  "eventType": "SPENDBACK",
  "spendbackStatus": 20,
  "spendbackId": 2437652,
  "spendbackRef": "dfbb8efc-6e85-4973-8f2e-69baf8624ae6"
}

Updated 11 months ago