When a webhook-enabled event occurs, Marqeta issues an HTTPS POST to a pre-configured customer-hosted endpoint with information about the event. The customer must have an environment configured to listen for and process event notifications in order to take advantage of this functionality.
Marqeta pushes notifications for the following events:
- Card Transition Events: These include activities such as a card being activated/deactivated, ordered, or shipped. From a technical point of view, they are activities that cause the transition of a card's state or fulfillment_status field.
- Transaction Events: These include activities such as authorizations, authorization clearings, and refunds. Note: Although you might think of an authorization and authorization clearing as two parts of the same conceptual transaction, the Marqeta platform treats each transaction-related message exchange as a separate transaction event with a unique indentifying token.
These are the run-time characteristics of the Marqeta webhook system:
|Number of Retry Attempts||In case of a messaging failure, Marqeta attempts to resend a notification message 10 times. A messaging failure is defined as any HTTP response code other than 200.
Note: In the case of a Ping message failure, the message is not resent.
|Retry Interval||An exponential backoff increases the interval between retries by powers of 4 after each subsequent messaging failure. In other words, the retry interval follows this pattern: 41 (4) secs, 42 (16) secs, 43 (64) secs ... 410 secs (a little more than 12 days).|
|Maximum Batch Size||Marqeta reduces the number of event notification messages by batching multiple notifications of the same type and sending them together in a single message. A maximum of 20 transaction notifications or 100 card-transition notifications are sent per message.|
|Authentication||Marqeta includes a Basic Auth (base64 encoded) header in the notification message. The customer environment must be configured to perform this type of authentication.|