Marqeta.com
Support
/
5 minute read
December 16, 2020

About Webhooks

Use webhooks to receive information about API events as they occur. An event is an activity that happens outside of your system, such as a card transaction at a point-of-sale (POS) terminal or a card activation. For example, when a card is used, a webhook is sent with details of the attempted transaction. To receive and process webhook-enabled events, configure a webhook endpoint in your environment.

Tip
For the Webhooks API reference, see Webhooks Management.

Using webhooks

When a webhook-enabled event occurs, the Marqeta platform sends an HTTPS

POST
request containing information about the event to a preconfigured endpoint hosted on your system. You must have an environment configured to listen for and process event notifications in order to take advantage of this functionality.

Webhooks are primarily used:

  • For record maintenance, as the source of truth for transactional money movement.

  • To understand when an event occurred (for example, when a cardholder has passed KYC verification, a user transition notification is sent).

Marqeta strongly recommends that you implement webhooks.

Note
Each program can have up to 5 active webhooks.

Runtime characteristics

The Marqeta platform webhook system handles notification messages by:

  • Retrying failed notification messages.

  • Batching multiple notifications of the same event type in a single message.

  • Including a Basic Auth (base64-encoded) header in the notification message.

Below are the run-time characteristics of the Marqeta platform’s webhook system.

Name Description

Number of retry attempts

In case of a messaging failure, the Marqeta platform 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
endpoint messaging 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: 4 seconds, 16 seconds, 64 seconds, and so on, up to an interval just over 12 days.

Maximum batch size

The Marqeta platform 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, 100 card transition notifications, or 100 digital wallet token transition notifications are sent per message.

Authentication

The Marqeta platform includes a Basic Auth (base64 encoded) header in the notification message. Your environment must be configured to perform this type of authentication.

Event notification processing

Your webhook endpoint might receive notifications in a different order from which the underlying events occur. You can use the

created_time
field to determine the correct chronological order, if that is necessary for your business logic.

Idempotency

Your webhook endpoint might occasionally receive the same notification more than once, such as in the case of a messaging failure. You can handle these rare cases by making your event processing idempotent so duplicate notifications do not have any additional effects. To support idempotency, each transaction is identified by a unique transaction token, and each webhook is identified by a unique event token.

Tutorial

This tutorial walks you through how to configure your webhook endpoint to subscribe to events.

Step 1 — Configure your webhook endpoint
Note
Webhook configurations created by the
/webhooks
endpoint are functional only in a production environment. If you want to test webhooks in the sandbox environment, configure a webhook object within your simulated transaction. For more information, see Simulating Transactions.

Define the

config
object in the request body, which contains configuration information for the webhook:

  • Set the

    url
    field to the value of the URL of your webhook endpoint, the location to where event notifications are sent.

  • Set the

    basic_auth_username
    and
    basic_auth_password
    fields to the value of the username and password for accessing your webhook endpoint, respectively.

The following code block shows a sample

config
object as it would appear in a
POST
request:

Copied

Is this helpful?

Yes
No
Step 2 — Subscribe to event notifications

Specify the

events
array in the request body, which contains a comma-delimited array of strings (a single string embedded in this field is considered an array of one). Each string represents:

  • A single event type (for example,

    transaction.gpa.debit
    ).

  • A group of event types, denoted by an asterisk after the base event type (for example,

    transaction.*
    or
    cardtransition.*
    ).

  • All event types, denoted by a single asterisk in the place of the event type (for example,

    *
    ).

Marqeta strongly recommends that you subscribe to all event types initially. For a list of event types the Marqeta platform supports, see Event Types.

The following code block shows a sample subscription to both a single event type and group of event types as it would appear in a

POST
request. The single event type
cardtransition.fulfillment.issued
represents when a card is issued; the group of event types
transaction.*
represents any transaction event that occurs:

Copied

Is this helpful?

Yes
No

The following code block shows a sample subscription to all event types as it would appear in a

POST
request:

Copied

Is this helpful?

Yes
No
Step 3 — Create a webhook

Now that your webhook endpoint has been configured to subscribe to event notifications in the request body, you can create a webhook.

Send a

POST
request to the
/webhooks
endpoint. The following code block shows a sample request:

Copied

Is this helpful?

Yes
No

Feedback on this page?

If you feel we can do anything better, please let our team know.