/
45 minute read
June 2, 2023

Event Types

The Marqeta platform sends event notifications to your webhook endpoint.

The types of events that the Marqeta platform supports are categorized on this page. The type field further categorizes an event notification.

See Webhooks for the complete endpoint reference.

See About Webhooks for information on notifications and a tutorial that walks you through the configuration of your webhook endpoint.

3D Secure transition events

3D Secure (3DS) transition events include activities for when a merchant requests 3D Secure authentication for a transaction (i.e., the threedstransitions.initialization event), as well as when the Marqeta platform sends the merchant the outcome of the authentication request (i.e., the threedstransitions.completion event).

The Marqeta platform supports 3D Secure versions 1.x and 2.x. The webhook notifications will differ slightly, depending on the version of 3D Secure you are using.

The following example shows a 3D Secure 1.x initialization notification message:

JSON
Copied

Is this helpful?

Yes
No

The following example shows a 3D Secure 1.x completion notification message:

JSON
Copied

Is this helpful?

Yes
No

The following example shows a 3D Secure 2.x initialization notification message:

JSON
Copied

Is this helpful?

Yes
No

The following example shows a 3D Secure 2.x completion notification message:

JSON
Copied

Is this helpful?

Yes
No

For more information about 3D Secure, see 3D Secure Overview.

Account holder transition events

Account holder transition events include activities such as a user or business being created, suspended, or closed. These activities transition a user’s or business' status.

Account holder transition notifications contain detailed information about the events, along with any metadata associated with the user or business account holder. They are sent as account holder transition events occur.

Each notification contains a status field that categorizes the account holder transition event. The following table describes each account holder status. Values in the Status column are the literal values of the notification’s status field. When configuring a webhook to capture these events, you must prefix this with usertransition or businesstransition (for example, usertransition.active).

Status Description

unverified

User or business was created in an unverified status due to KYC.

limited

User or business was created in a limited status due to KYC.

active

User or business was created in an active status due to KYC, or passed KYC after being unverified or limited.

suspended

User or business was suspended.

closed

User or business was closed.

Account holder transition notifications are structured as an array within a usertransitions or businesstransitions element. Multiple notifications can be included in a single notification message. The structure of each individual notification is identical to that of a usertransition or businesstransition object returned by the /usertransitions and /businesstransitions endpoints, respectively.

The following example shows a notification message containing a business transition notification, indicating the business was closed.

JSON
Copied

Is this helpful?

Yes
No

For more information about the usertransitions object, see Users. For more information about the businesstransitions object, see Businesses.

ACH origination transition events

ACH Origination transition events include activities such as bank transfer being transitioned to a pending, processing, submitted, completed, returned, or cancelled state. ACH transfer transition notifications are sent when status transition events occur and contain detailed information about the events.

Transition events will be sent with the EventType banktransfertransition.

Type Status Description

status.pending

PENDING

The ACH transfer is transitioned to the PENDING state.

status.processing

PROCESSING

The ACH transfer has been picked to process and is transitioned to the PROCESSING state.

status.submitted

SUBMITTED

The ACH transfer has been submitted to the bank and is transitioned to the SUBMITTED state.

status.completed

COMPLETED

The ACH transfer is transitioned to the COMPLETED state.

status.returned

RETURNED

The ACH transfer has been returned by the receiving financial institution and transitioned to the RETURNED state.

status.cancelled

CANCELLED

The ACH transfer has been canceled by the program and transitioned to the CANCELLED state.

status.error

ERROR

The ACH transfer is transitioned to the ERROR state.

Bank transfer transition notifications are structured as an array within a banktransfertransitions element. Multiple notifications can be included in a single notification message. The structure of each individual notification is identical to that of a banktransfertransition object returned by the /banktransfertransitions endpoint.

The following example shows a notification message containing a notification that a bank transfer transition has been submitted.

JSON
Copied

Is this helpful?

Yes
No

For more information about the banktransfers object, see Funding via ACH.

Card transition events

Card transition events 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.

Card transition notifications are sent as card transition events occur and contain detailed information about the events, along with any metadata associated with the card.

Each notification contains a type field that categorizes the card transition event. The following table describes each card transition event type. The values in the Type column are the literal values of the notification’s type field. When configuring a webhook to capture card events, you must prefix this type with cardtransition (for example, cardtransition.fulfillment.issued).

Type Description

fulfillment.delivered

Card was delivered by the card fulfillment provider.

fulfillment.digitally_presented

Card was digitally presented using the /cards/{token}/showpan endpoint.

fulfillment.issued

Card was created/issued.

fulfillment.ordered

Card was ordered from card fulfillment provider.

fulfillment.rejected

Card was rejected by card fulfillment provider.

fulfillment.shipped

Card was shipped by card fulfillment provider. This field appears only if it is provided by the card fulfillment provider.

state.activated

Card was activated.

state.limited

Card was limited.

state.reinstated

Card was reinstated from a suspended state.

state.suspended

Card was suspended.

state.terminated

Card was terminated.

Card transition notifications are structured as an array within a cards element. Multiple notifications can be included in a single notification message. The structure of each individual notification is identical to that of a cardtransition object returned by the /cardtransitions endpoint.

The following example shows a notification message containing two card transition notifications: one for the issuance of a card, and one for the activation of that card.

JSON
Copied

Is this helpful?

Yes
No

For more information about the cardtransitions object, see Cards.

Card action events

Card action events include PIN set, PIN change, and PIN reveal actions. Card action notifications are sent as card action events occur and contain detailed information about the events.

Each notification contains a type field that categorizes the card action event. The following table describes each card action event type. The values in the Type column are the literal values of the notification’s type field. When configuring a webhook to capture these events, you must prefix this type with cardaction (for example, cardaction.pin.set).

Type Description

pin.changed

Card PIN was changed.

pin.reveal

Card PIN was revealed.

pin.set

Card PIN was set.

The following example shows a notification message containing a notification that a PIN was set for a card.

JSON
Copied

Is this helpful?

Yes
No

Chargeback transition events

Chargeback transition events mark the progress of disputes through the arbitration process. From a technical point of view, chargeback transition events cause the transition of a chargeback object’s state field.

The chargeback object represents a completed transaction that has been disputed by the issuer. In order for the dispute to be resolved, the chargeback must pass through an arbitration process consisting of multiple phases. Each phase of the arbitration process is represented by a chargebacktransition object of a particular type. For example, the creation of a new chargeback incidentally creates a chargebacktransition of type initiated. After creating a chargeback, you can explicitly move it from one arbitration phase to another by creating a chargebacktransition of the appropriate type. Chargebacks do not follow a prescribed path through the arbitration process.

Chargeback transition notifications are sent as chargeback transition events occur and contain detailed information about the events.

Each notification contains a type field that categorizes the chargeback transition event. The following table describes each chargeback transition event type. The values in the Type column are the literal values of the notification’s type field. When configuring a webhook to capture these events, you must prefix this type with chargebacktransition (for example, chargebacktransition.representment).

Type Description

initiated

The chargeback has been created. Funds to cover the disputed charges have been credited to the cardholder’s account if the credit_user field was true or unspecified at the time of creation.

representment

The case is in representment (also known as second presentment). The gateway/acquirer has disputed the chargeback. In some cases, representment does not occur.

prearbitration

The case is in prearbitration (also known as arbitration chargeback). Upon receipt of a dispute from the gateway/acquirer (representment), the issuer can submit the chargeback a second time, possibly with more or different information. Only relevant chargebacks assume this status.

prearbitration.responded

Specific to Fraud and Authorization reason codes only. Upon responding to receipt of a dispute from the gateway/acquirer (prearbitration), the issuer can submit the response, possibly with new information. Only relevant chargebacks assume this status.

arbitration

The case is in arbitration. When a gateway/acquirer disputes a chargeback, the issuer can submit the case to the card network for arbitration after either the first or second (prearbitration) chargeback. In arbitration, the card network decides who wins the chargeback case.

case.won

The chargeback case is closed; Marqeta won.

case.lost

The chargeback case is closed; Marqeta lost.

network.rejected

The card network rejected the chargeback submission.

written.off.issuer

Can be transitioned to only from case.lost or network.rejected. The chargeback is credited to the GPA of the user or business and Marqeta absorbs the cost.

written.off.program

Can be transitioned to only from case.lost or network.rejected. The chargeback is credited to the GPA of the user or business and the Marqeta customer absorbs the cost through a debit from the program funding source.

Chargeback transition notifications are structured as an array within a chargebacktransitions element. Multiple notifications can be included in a single notification message.

The following example shows a notification message containing two chargeback transition notifications:

JSON
Copied

Is this helpful?

Yes
No

The following example shows a notification message for a prearbitration.responded event, specific to Fraud and Authorization reason codes only:

JSON
Copied

Is this helpful?

Yes
No

Commando Mode transition events

Commando Mode transition events include enabling and disabling a Commando Mode control set for the associated program gateway funding source. These activities transition the current_state.commando_enabled field of a specific Commando Mode control set.

Commando Mode transition notifications are sent as transition events occur and contain detailed information about the events. When configuring a webhook to capture these events, you must prefix the event type (such as enabled or disabled) with commandomodetransition. For example, to capture when a Commando Mode control set is enabled, you must configure a webhook for the commandomodetransition.enabled event.

The following table describes each Commando Mode transition event type.

Type Description

enabled

Indicates that a Commando Mode control set was enabled.

disabled

Indicates that a Commando Mode control set was disabled.

The following example shows a notification message containing a Commando Mode transition notification, indicating the Commando Mode control set was disabled.

JSON
Copied

Is this helpful?

Yes
No

For more information about the commandomodes object, see Commando Mode.

Credit account delinquency state transition events

Credit account delinquency state transition events occur when a credit account becomes delinquent and falls behind on its payments or becomes current and is brought up to date on its payments. These events cause the delinquency state’s is_delinquent field to toggle between true and false.

Delinquency state transition notifications are sent as delinquency state transition events occur and contain detailed information about the events.

Each notification contains a status field that indicates the account’s new delinquency status. The following table describes each delinquency status. Values in the Status column are the literal values of the notification’s status field. Values in the Type field are the literal webhook event type.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including credit account delinquency state transition events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Status Type Description

CURRENT

status.current

The account transitioned to a current status and is no longer delinquent. Transition to DELINQUENT is permitted.

DELINQUENT

status.delinquent

The account transitioned to a delinquent status and is no longer current. Transition to CURRENT is permitted.

The following example shows a credit.delinquencytransition.current event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditdelinquencytransitions object, see Retrieve delinquency state transition.

Credit account payment transition events

The following applies to ACH payments on credit accounts only.

Credit account payment transition events include activities such as a payment being initiated, submitted, or returned on a credit account. From a technical point of view, they are activities that cause the transition of a payment’s status field.

Payment transition notifications are sent as payment transition events occur and contain detailed information about the events.

Each notification contains a status field that categorizes the payment transition event. The following table describes each payment status. Values in the Status column are the literal values of the notification’s status field.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including credit account payment transition events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Status Description

initiated

Payment was initiated.

pending

Payment was successfully created.

processing

Payment is being processed by the ACH processor.

submitted

Payment was submitted to the bank.

completed

Payment is completed.

returned

Payment was returned.

refunded

Payment was refunded.

cancelled

Pending payment was canceled by transitioning the account payment status.

The following example shows a credit.paymenttransition.completed event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditpaymenttransitions object, see Transition account payment status.

Credit account statement event

The credit account statement event occurs when a statement is generated on the billing cycle day and contains detailed information about the statement, including the opening date, closing date, closing balance, and more.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including the credit account statement event. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

The following example shows a credit.accountstatement.created event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditaccountstatements object, see Retrieve account statement summary.

Credit account transition events

Credit account transition events include activities such as a credit account being activated, unactivated, suspended, or terminated. From a technical point of view, they are activities that cause the transition of a credit account’s status field.

Credit account transition notifications are sent as the credit account transition events occur and contain detailed information about the events.

Each notification contains a status field that indicates the account’s new status. The following table describes each credit account status. Values in the Status column are the literal values of the notification’s status field. Values in the Type field are the literal webhook event type.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including credit account transition events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Status Type Description

UNACTIVATED

status.unactivated

The unactivated credit account is awaiting activation by the account holder. Transition to ACTIVATED is permitted.

ACTIVE

status.activated

The activated credit account is functional and allows account activity such as credit transactions. Transitions to SUSPENDED and TERMINATED are permitted.

SUSPENDED

status.suspended

The suspended credit account is temporarily non-functional. Transitions to ACTIVATED or TERMINATED are permitted.

TERMINATED

status.terminated

The terminated credit account is permanently non-functional. Transition to CHARGE_OFF is permitted.

CHARGE_OFF

status.chargeoff

The charged off credit account is permanently non-functional and cannot transition to another status. This is a terminal status.

The following example shows a credit.accounttransition.status.activated event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditaccounttransitions object, see Retrieve account transition.

Credit application transition events

Credit application transition events include activities such as an application being created, submitted, rejected, accepted, and more. From a technical point of view, they are activities that cause the transition of an application’s state field.

Application transition notifications are sent as application transition events occur and contain detailed information about the events.

Each notification contains a status field that categorizes the application transition event. The following table describes each application status. Values in the Status column are the literal values of the notification’s status field.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including application events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Status Description

CREATED

Application was created.

DECISIONING

Application was submitted for decisioning.

MANUAL_REVIEW

Application was moved to a manual review.

APPROVED

A decision on the application has been made and the application was approved.

REJECTED

The user rejected their approved application.

ACCEPTED

The user accepted their approved application.

DECLINED

A decision on the application has been made and the application was denied.

The following example shows a credit.applicationtransitions.status.decisioning event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the applicationtransitions object, see Transition application state.

Credit journal entry events

The following applies to credit journal entry events only. For debit transactions, see Transaction events.

Journal entry events include activities on a credit account such as purchase authorizations, purchase authorization clearings, refunds, credit balance refunds, adjustments, fees, interest, rewards, and payments. Although you might think of a purchase authorization and purchase authorization clearing as two parts of the same conceptual journal entry, the Marqeta platform treats each journal entry-related message exchange as a separate journal entry event with a unique identifying token.

Journal entry notifications are sent in real time as journal entry events occur and contain detailed information about the events.

All journal entry notifications contain a type field that categorizes the journal entry event. The following table lists all possible values for the type field. The values in the Type column are the literal values of the notification’s type field.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including journal entry events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Type Description

account.adjustment

General credit adjustment applied to the credit account. An account.adjustment does not relate to an existing journal entry. Final transaction type.

account.adjustment.fee

Adjustment to a prior fee journal entry. Can adjust account.fee.payment.late, account.fee.payment.returned, or account.fee.interest.minimum. Final transaction type.

account.adjustment.interest

Adjustment to a prior account.interest journal entry. Final transaction type.

account.adjustment.purchase

Adjustment to a prior authorization.clearing journal entry. Final transaction type.

account.adjustment.reward

Adjustment to a prior account.reward.cashback journal entry. Final transaction type.

account.balancerefund

Credit balance refund applied to the credit account, increasing the account’s current balance to 0.00. Final transaction type.

account.dispute

Dispute was initiated and a provisional credit was applied.

Possibly completed by:

account.dispute.won, account.dispute.lost, account.dispute.reversal, account.dispute.lost.graceperiod

account.dispute.lost

Dispute lost in the merchant’s favor. Reverses the financial impact of account.dispute. Final transaction type.

account.dispute.lost.graceperiod

Dispute initiated in an active grace period and lost in the merchant’s favor. Reverses the financial impact of account.dispute. Final transaction type.

account.dispute.reversal

Dispute withdrawn or reversed. Reverses the financial impact of account.dispute. Final transaction type.

account.dispute.won

Dispute won in the account holder’s favor. No impact to account balance. Final transaction type.

account.fee.annual

Annual periodic fee was applied. Final transaction type.

account.fee.interest.minimum

Minimum interest amount applied as a fee if the calculated interest is below a certain threshold. Final transaction type.

account.fee.monthly

Monthly periodic fee was applied. Final transaction type.

account.fee.payment.late

Penalty fee for late payments. Final transaction type.

account.fee.payment.returned

Penalty fee for returned payments. Final transaction type.

account.interest

Accrued interest applied to the credit account. Final transaction type

account.payment

Payment initiated.

Possibly completed by:

account.payment.completed, account.payment.canceled

account.payment.canceled

Payment canceled. Reverses the financial impact of an account.payment journal entry.

Final transaction type.

account.payment.completed

Payment completed. Releases the available credit for the payment, pending any available credit holds on the account. No impact to account balance.

Possibly completed by:

account.payment.returned, account.payment.refunded

account.payment.completed.hold

A hold on available credit applied for an account.payment.completed journal entry.

Possibly completed by:

account.payment.completed.hold.released

account.payment.completed.hold.
released

Indicates that a hold on available credit applied for an account.payment.completed journal entry was released.

account.payment.refunded

Payment refunded. Reverses the financial impact of an account.payment.completed journal entry.

account.payment.returned

Payment returned. Reverses the financial impact of an account.payment.completed journal entry.

Final transaction type.

account.reward.auto.cashback

Rewards redeemed to the credit account through the cashback method, as calculated and applied by Marqeta. Final transaction type.

account.reward.cashback

Rewards redeemed to the credit account through the cashback method. Final transaction type

authorization

Funds hold due to card usage. Temporary transaction type. Requires settlement.

Possibly completed by:

authorization.advice, authorization.reversal, authorization.reversal.issuerexpiration, authorization.clearing

authorization.advice

Decreases the amount of an existing authorization journal entry.

Temporary transaction type. Requires settlement. Must be honored.

Possibly completed by:

authorization.reversal, authorization.reversal.issuerexpiration, authorization.clearing

authorization.clearing

Completes an authorization journal entry. Final transaction type.

authorization.incremental

Increases the amount of a prior authorization journal entry by adding to it without replacing it.

Temporary transaction type. Requires settlement.

Possibly completed by:

authorization.reversal, authorization.clearing

authorization.reversal

Reverses or drops an authorization journal entry due to elapsed time.

authorization.reversal.issuerexpiration

Reverses or drops an authorization journal entry due to elapsed time. Initiated by Marqeta.

originalcredit.authorization

Original credit transaction (OCT) authorization for crediting funds to a credit account. Temporary transaction type.

Possibly completed by:

original.credit.authorization.reversal, original.credit.authorization.clearing

originalcredit.authorization.clearing

Completes an originalcredit.authorization journal entry.

originalcredit.authorization.reversal

Reverses the financial impact of an originalcredit.authorization journal entry.

originalcredit.authorization.reversal.
issuerexpiration

Reverses the financial impact of an originalcredit.authorization journal entry due to elapsed time. Initiated by Marqeta.

originalcredit.authpluscapture

Single-message OCT for crediting funds to a credit card.

originalcredit.authpluscapture.
reversal

Reverses the financial impact of an originalcredit.authpluscapture journal entry. Final transaction type.

pindebit

PIN-debit transaction.

pindebit.authorization.clearing

Force-capture completed PIN-debit authorization.

pindebit.refund

Refunds a PIN-debit transaction.

refund

Refunds a cardholder’s transaction. Final transaction type.

refund.authorization

Authorization for a purchase return. Temporary transaction type.

Possibly completed by:

refund.authorization.reversal, refund.authorization.clearing

refund.authorization.clearing

Completes a refund.authorization purchase return authorization journal entry.

refund.authorization.reversal

Reverses a refund.authorization purchase return authorization journal entry.

refund.authorization.reversal.
issuerexpiration

Reverses or drops a purchase return authorization due to elapsed time. Initiated by Marqeta

Journal entry notifications are structured as an array within a creditjournalentries element.

The following is a sample purchase journal entry notification. The detail_object contains the purchase details, in this case. However, fields in the detail_object vary based on the group value. For example, purchases return purchase details; adjustments return adjustment details; interest returns interest details.

The following example shows a credit.journalentry.authorization event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditjournalentries object, see Retrieve account journal entry.

Credit ledger entry events

Important
This feature is being deprecated and replaced by journal entries. For journal entry events, see Credit journal entry events. For more on journal entries, see About Credit Account Journal Entries.

Ledger entry events include activities on a credit account such as purchase authorizations, purchase authorization clearings, refunds, credit balance refunds, adjustments, fees, interest, rewards, and payments. Although you might think of a purchase authorization and purchase authorization clearing as two parts of the same conceptual ledger entry, the Marqeta platform treats each ledger entry-related message exchange as a separate ledger entry event with a unique identifying token.

Ledger entry notifications are sent in real time as ledger entry events occur and contain detailed information about the events.

All ledger entry notifications contain a type field that categorizes the ledger entry event. The following table lists all possible values for the type field. The values in the Type column are the literal values of the notification’s type field.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including ledger entry events. For more on webhooks, see Webhooks

Type Description

authorization

Funds hold due to card usage. Temporary transaction type. Requires settlement.

authorization.incremental

Increases the amount of a previous authorization by adding to it without replacing it.

refund.authorization

Authorization for a purchase return. Temporary transaction type.

authorization.clearing

Completes an authorization.

authorization.reversal

Reverses or drops an authorization not due to elapsed time.

authorization.advice

Replaces the amount of an existing authorization. Temporary transaction type. Requires settlement.

account.adjustment

Ghost adjustment was applied.

account.adjustment.fee

Fee adjustment was applied.

account.adjustment.interest

Interest adjustment was applied.

account.adjustment.purchase

Provisional credit was applied or reversed, either because a dispute was initiated, or because a dispute was resolved in the merchant’s favor.

NOTE: If the amount is negative, the provisional credit was applied; if positive, it was reversed.

account.adjustment.purchase.
graceperiod

A previously applied provisional credit on a disputed transaction in an active grace period was reversed because the dispute was resolved in the merchant’s favor.

account.adjustment.reward

Reward adjustment was applied.

account.balance.refund

Credit balance refund was applied.

account.fee.annual

Annual periodic fee was applied. Final transaction type.

account.fee.latepayment

Late payment fee was applied.

account.fee.minimum.interest

Minimum interest fee was applied.

account.fee.monthly

Monthly periodic fee was applied. Final transaction type.

account.fee.returnpayment

Returned payment fee was applied.

account.interest

Interest charges were applied.

account.payment.canceled

Payment was canceled.

account.payment.completed

Payment was completed.

account.payment.pending

Payment is pending.

account.payment.refunded

Payment was refunded.

account.payment.returned

Payment was returned.

account.reward.cashback

Rewards were posted.

authorization

Funds hold due to card usage. Temporary transaction type. Requires settlement.

authorization.advice

Replaces the amount of an existing authorization. Temporary transaction type. Requires settlement.

authorization.clearing

Completes an authorization.

authorization.incremental

Increases the amount of a previous authorization by adding to it without replacing it.

authorization.reversal

Reverses or drops an authorization not due to elapsed time.

authorization.reversal.issuerexpiration

Reverses or drops an authorization due to elapsed time; initiated by Marqeta.

original.credit.authorization

Original credit transaction (OCT) authorization for disbursing funds to a credit card.

original.credit.authorization.reversal

Reverses the financial impact of an OCT authorization.

original.credit.authorization.clearing

Completes an OCT authorization.

original.credit.auth_plus_capture

Single-message OCT for disbursing funds to a credit card.

original.credit.auth_plus_capture.
reversal

Reverses the financial impact of a single-message OCT.

pindebit

PIN-debit transaction.

pindebit.authorization.clearing

Force-capture completed PIN-debit authorization.

pindebit.refund

Refunds a PIN-debit transaction.

refund

Refunds a cardholder’s transaction.

refund.authorization

Authorization for a purchase return. Temporary transaction type.

refund.authorization.clearing

Completes a purchase return authorization.

refund.authorization.reversal

Reverses a purchase return authorization.

Ledger entry notifications are structured as an array within a creditledgerentries element.

The following is a sample purchase ledger entry notification. The detail_object contains the purchase details, in this case. However, fields in the detail_object vary based on the group value. For example, purchases return purchase details; adjustments return adjustment details; interest returns interest details.

The following example shows a credit.ledgerentry.authorization event.

JSON
Copied

Is this helpful?

Yes
No

For more on the creditledgerentries object, see Retrieve account ledger entry.

Credit product transition events

Important
This feature is being deprecated and replaced by credit product policies, which is part of the bundles feature. For more on policies and bundles in a credit program, see Managing Credit Programs in the Marqeta Dashboard (Beta).

Credit product transition events include activities such as a credit product being activated, pending approval, sent for revision, or rejected. These activities transition a credit product’s status.

Credit product transition notifications contain detailed information about the events. They are sent as credit product transition events occur.

Each notification contains a status field that categorizes the credit product transition event. The following table describes each credit product status. Values in the Status column are the literal values of the notification’s status field. Values in the Type field are the literal webhook event type.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including credit product transition events. For more on webhooks, see Webhooks

Status Type Description

ACTIVE

status.activated

Credit product was activated.

PENDING APPROVAL

status.pendingapproval

Credit product was created and is now pending approval.

SENT FOR REVISION

status.sentforrevision

Credit product was sent for revision.

REJECTED

status.rejected

Credit product was rejected.

The following example shows a credit.producttransition.state.activated event.

JSON
Copied

Is this helpful?

Yes
No

For more on the creditproducttransitions object, see Retrieve credit product.

Credit reward entry events

Credit reward entry events include activities such as a reward entry being created or posted to a credit account. From a technical point of view, they are activities that cause the transition of a reward entry’s status field.

Reward entry notifications are sent as reward entry events occur and contain detailed information about the events.

Each notification contains a status field that categorizes the reward entry event. The following table describes each reward entry status. Values in the Status column are the literal values of the notification’s status field.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including reward entry events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Status Description

PENDING

Reward entry is currently pending.

POSTED

Reward entry has been posted to the credit account.

The following example shows a creditrewardentries.pending event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditrewardentries object, see Retrieve reward entry.

Credit reward redemption transition events

Credit reward redemption transition events include activities such as an reward redemption being initated, completed, or returned. From a technical point of view, they are activities that cause the transition of a reward redemption’s status field.

Reward redemption transition notifications are sent as reward redemption transition events occur and contain detailed information about the events.

Each notification contains a status field that categorizes the reward redemption transition event. The following table describes each redemption status. Values in the Status column are the literal values of the notification’s status field.

When configuring a webhook to subscribe to credit events, set the type value to credit.*. This enables Marqeta to send notifications for all credit events, including reward redemption events. The ability to receive individual credit events will be available in a future release. For more on webhooks, see Webhooks

Status Description

INTIATED

Redemption has been initiated.

COMPLETED

Redemption has been paid and is completed.

PROCESSING

ACH processor is processing the ACH transfer for the redemption.

This status only applies when the redemption type is ACH.

RETURNED

Redemption could not be completed and has been returned.

SUBMITTED

ACH processor is finished processing ACH transfer for the redemption and has sent the NACHA file to the bank.

This status only applies when the redemption type is ACH.

The following example shows a creditredemptiontransitions.initiated event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the creditredemptiontransitions object, see Create reward redemption.

Digital wallet token transition events

Digital wallet token transition events include activities such as a digital wallet token being requested, activated, or terminated. From a technical point of view, they are activities that cause the transition of a token’s state or fulfillment_status field.

Digital wallet token transition notifications are sent as digital wallet token transition events occur and contain detailed information about the events.

Each notification contains a type field that categorizes the digital wallet token transition event. The following table describes each digital wallet token transition event type. The values in the Type column are the literal values of the notification’s type field. When configuring a webhook to capture digital wallet token events, you must prefix this type with digitalwallettokentransition (for example, digitalwallettokentransition.fulfillment.requested).

Type Description

fulfillment.requested

Indicates that a token was requested and provisioning is pending.

state.request_declined

Indicates that token provisioning was rejected. The state of the token cannot be further modified.

state.activated

Indicates that the token has been provisioned and is active.

state.suspended

Indicates that the token has been suspended.

state.reinstated

Indicates that the token has been reactivated from a suspended state.

state.terminated

Indicates that the token has been terminated. The state of the token cannot be further modified.

card.swap

A card was activated (the card state transitioned from UNACTIVATED to ACTIVE), and all existing digital wallet tokens owned by the user and having a state of REQUESTED, ACTIVE, or SUSPENDED were moved to the new card.

Note
The token-related event type token.activation-request is categorized as a transaction event and is documented in the Transaction events section.

Digital wallet token transition notifications are structured as an array within a digitalwallettokentransitions element. Multiple notifications can be included in a single notification message. The structure of each individual notification is identical to that of a digitalwallettokentransition object returned by the /digitalwallettokentransitions API endpoint.

The following example shows a notification message containing two digital wallet token transition notifications: one requesting a token, and one for the activation of that token.

JSON
Copied

Is this helpful?

Yes
No

For more information about the digitalwallettokentransitions object, see Digital Wallets Management.

Direct deposit transition events

Direct deposit transition events include activities such as a direct deposit being applied, reversed or rejected. Transitioning the ACH transaction’s state field triggers these event notifications.

Each notification contains a state field that indicates the ACH transaction’s new state. The following table describes the possible values of the state field within a directdeposittransition event. Values under the State column are the literal values of the notification’s state field. When configuring a webhook to capture these events, you must prefix this with directdeposittransition (for example, directdeposittransition.applied).

State Description

APPLIED

The ACH transaction has been settled and money can be posted to the account holder.

REVERSED

The ACH transaction was in a pending or settled state, but now has been reversed and the money will be returned to the ODFI.

REJECTED

The ACH transaction could not be initiated, often because an invalid account number or inactive account. The money will be returned to the ODFI.

The following example shows a directdeposittransition.applied event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the /directdeposits/transitions endpoint, see Direct Deposit.

Direct deposit account transition events

Direct deposit account transition events include activities such as a direct deposit account being activated, suspended, or terminated. Updating the account’s state field triggers these event notifications.

Direct deposit account transition notifications are sent as the corresponding transition events occur. Each notification contains a state field that indicates the account’s new state. The following table describes the possible values of the state field within a directdepositaccounttransition event. Values in the State column are the literal values of the notification’s state field. When configuring a webhook to capture these events, you must prefix this with directdepositaccounttransition (for example, directdepositaccounttransition.active).

State Description

ACTIVE

The direct deposit account is functional, and allows debit and credit transactions including ACH. Transitions to the SUSPENDED or TERMINATED states are permitted.

SUSPENDED

The direct deposit account is temporarily non-functional. When in this state, all credits and debits including ACH should be processed. Transitions to the ACTIVE or TERMINATED states are permitted.

TERMINATED

The direct deposit account is permanently non-functional and cannot transition to any other state. When in this state, all credits including ACH should be processed; all debits should be rejected.

The following example shows a directdepositaccounttransition.suspended event.

JSON
Copied

Is this helpful?

Yes
No

For more information about the /depositaccounts/transitions endpoint, see Deposit Accounts.

KYB results event

The kybresults event returns the results of a KYC verification request for a business when the BUSINESS component could not be verified in the allotted time. In such cases, the KYC request returns a status of VENDOR_PENDING, and the relevant BUSINESS component also returns an outcome of VENDOR_PENDING.

Note
The VENDOR_PENDING status only applies to the BUSINESS component, not to the PROPRIETOR or BENEFICIAL_OWNER components. Therefore, the kybresults event only returns information about the BUSINESS component.

Marqeta sends kybresults events as soon as the KYC vendor returns the final verification for the business KYC verification request.

The following example shows a kybresults event that returned a successful KYC result for a business. The token field includes the original KYC request token from the POST /kyc action. See Perform KYC for information about the POST /kyc action.

JSON
Copied

Is this helpful?

Yes
No

For more information about the business.results object, see the business result array.

Level 2 and Level 3 card data events

Level 2 (L2) and Level 3 (L3) card data go beyond standard Level 1 (L1) data such as card number and transaction amount. L2 and L3 data provide more specific data to the merchants, issuers, acquirers, and processors that transact with business, corporate, and purchasing cardholders. These services enable the processing and delivery of additional transaction data to help merchants and issuers gather important non-financial data from commercial card transactions.

L2 data include L1 data plus details such as sales tax amount and purchase order number. L3 data include L1 and L2 data plus additional details such as product quantity, line item description, and unit of measure.

When configuring a webhook to subscribe to L2 and L3 card data events, set the type value to authorization.clearing.l2l3.

The following example shows an authorization.clearing.l2l3 event.

JSON
Copied

Is this helpful?

Yes
No

This is the model for L2/L3 card transaction data.

JSON
Copied

Is this helpful?

Yes
No
Important
Customer’s use of Enhanced Data must comply with the Network Rules, specifically including Visa Rule 4.13.2, and:

Customer may only utilize the Enhanced Data for the administration and management of their commercial card program, including but not limited to accounting, tax management, policy compliance, and other business management functions.

Customer may not utilize the data for any other purpose, including marketing.

Customer must treat the information as confidential and may not further disclose the data without Marqeta’s consent.

Smart reject for 3DS case events

When a user attempts to submit a fraud dispute on a 3DS transaction, the case management system smart-rejects the dispute. 3DS rejections apply to fraud disputes (10.1, 10.2, 10.3, 10.4). When configuring a webhook to subscribe to smart reject events, set the type value in the subscription request to caseevent.*.

The cases object represents a smart rejection that has been submitted. Notifications that are sent contain detailed information about the case event. Each notification contains a type field that categorizes the case event. When configuring a webhook to capture case events, you must prefix this type with cases (for example, cases.smart.reject).

The following example shows a cases.smart.reject event.

JSON
Copied

Is this helpful?

Yes
No

Transaction events

The following applies to debit transaction events only. For credit journal entries, see Credit journal entry events.

Transaction events include activities such as authorizations, authorization clearings, and refunds. 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 identifying token.

Transaction notifications are sent in real time as transaction events occur; they contain detailed information about the events.

All transaction notifications contain a type field that categorizes the transaction event. The following table lists all possible values for the type field. The table describes each type, indicates the objects potentially included in that transaction type, and lists the transaction types that could potentially complete it. The values in the Type column are the literal values of the notification’s type field. When configuring a webhook to capture these events, you must prefix this type with transaction (for example, transaction.authorization).

The response.code field describes the outcome of the attempted transaction. For more information on transaction outcomes, see the transaction response codes table.

See all transaction response fields in Transactions.

Type Description

account.funding.authorization

Funds hold for an account funding transaction (AFT).

Temporary transaction type.

Possibly completed by: account.funding.authorization.clearing

account.funding.authorization.clearing

Completes an AFT authorization (account.funding.authorization).

Final transaction type.

account.funding.auth_plus_capture

Funds hold for a single-message AFT.

Final transaction type.

account.funding.authorization.reversal

Cancels and reverses an AFT authorization (account.funding.authorization).

Final transaction type.

account.funding.auth_plus_capture.reversal

Reverses and cancels a single-message AFT (account.funding.auth_plus_capture).

Final transaction type.

accountfunding.pull

Pulls from an external card to fund a Marqeta cardholder account.

Final transaction type.

ach.pull.pending

Pending credit of funds to a direct deposit, general purpose, or program funding account.

Temporary transaction type.

State of associated ACH bank transfer record: PENDING.

Possibly completed by: ach.pull, ach.cancel, ach.pull.returned

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

ach.pull

Credit of funds to a direct deposit, general purpose, or program funding account.

Final transaction type unless the transaction is reversed.

State of associated ACH record: COMPLETED

Possibly followed by: ach.pull.returned

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

ach.push.pending

Pending debit of funds to a direct deposit, general purpose, or program funding account.

Temporary transaction type.

State of associated ACH bank transfer record: PENDING

Possibly completed by: ach.push, ach.cancel, ach.push.returned

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

ach.push

Debit of funds to a direct deposit, general purpose, or program funding account.

Final transaction type unless the transaction is reversed.

State of associated ACH record: COMPLETED

Possibly followed by: ach.push.returned

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

ach.cancel

Reverses a pending credit (ach.pull.pending) or debit (ach.push.pending) of funds to a direct deposit, general purpose, or program funding account.

Final transaction type.

State of associated ACH record: CANCELLED

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

ach.pull.returned

Reverses a pending or completed credit (ach.pull.pending or ach.pull) of funds to a direct deposit, general purpose, or program funding account.

Final transaction type.

State of associated ACH record: RETURNED

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

ach.push.returned

Reverses a pending or completed debit (ach.push.pending or ach.push) of funds to a direct deposit, general purpose, or program funding account.

Final transaction type.

State of associated ACH record: RETURNED

Possibly included objects: transaction_attributes, gpa

Possibly included fields: transaction.bank_transfer_token, transaction.state

authorization

Funds hold due to card usage.

Temporary transaction type. Requires settlement.

Possibly completed by: authorization.advice, authorization.reversal, authorization.reversal.issuerexpiration, authorization.clearing

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

authorization.advice

Decreases the amount of an existing authorization (authorization).

Temporary transaction type. Requires settlement. Must be honored.

Possibly completed by: authorization.reversal, authorization.reversal.issuerexpiration, authorization.clearing

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

authorization.atm.withdrawal

In the EU, authorization for withdrawing cash at an ATM. In the US, this event indicates that the cardholder got cash from a bank teller rather than an ATM.

Temporary transaction type.

Possibly completed by: authorization.clearing.atm.withdrawal

authorization.cashback

Authorization for cash back requested at a point-of-sale terminal.

Temporary transaction type.

Possibly completed by: authorization.clearing.cashback

authorization.clearing

Completes an authorization (authorization).

Final transaction type.

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

authorization.clearing.atm.withdrawal

Completes an authorization for withdrawing cash at an ATM (authorization.atm.withdrawal).

Final transaction type.

authorization.clearing.cashback

Completes an authorization for cash back requested at a point-of-sale terminal (authorization.cashback).

Final transaction type.

authorization.clearing.chargeback

Marqeta-initiated chargeback.

Possibly completed by: authorization.clearing.chargeback.reversal, authorization.clearing.chargeback.completed

Possibly included objects: gpa, chargeback, user.metadata

Possible states: INITIATED, PREARBITRATION, ARBITRATION,

Ledger impact: Positive if credit_user is true; none if credit_user is false.

authorization.clearing.chargeback.completed

Completes a Marqeta-initiated chargeback (authorization.clearing.chargeback).

Possibly included objects: gpa, chargeback, user.metadata

Possible states: CASE_WON

Ledger impact: Positive.

authorization.clearing.chargeback.provisional.credit

Provides a credit by moving a chargeback (authorization.clearing.chargeback) from the workflow for non-provisional credit to provisional credit.

Final transaction type. Requires settlement.

Possibly included objects: gpa, chargeback, user.metadata

authorization.clearing.chargeback.provisional.debit

Removes the initial credit by moving a chargeback (authorization.clearing.chargeback) from the workflow for provisional credit to non-provisional credit.

Final transaction type. Requires settlement.

Possibly included objects: gpa, chargeback, user.metadata

authorization.clearing.chargeback.reversal

Reverses a rejected, Marqeta-initiated chargeback (authorization.clearing.chargeback).

Possibly included objects: gpa, chargeback, user.metadata

Possible states: CASE_LOST, NETWORK_REJECTED

Ledger impact: Negative if credit_user is true; none if credit_user is false.

authorization.clearing.chargeback.writeoff

Writes off the chargeback (authorization.clearing.chargeback) and credits the account holder while Marqeta or its customer absorbs the cost.

Final transaction type.

Possibly included objects: gpa, chargeback, user.metadata

Possible states: WRITTEN_OFF_PROGRAM, WRITTEN_OFF_ISSUER

Ledger impact: Positive.

authorization.clearing.quasi.cash

Completes an authorization at a point-of-sale terminal for items equivalent to cash (authorization.quasi.cash), such as traveler’s checks, money orders, foreign currency, or gaming chips.

Final transaction type.

authorization.clearing.representment

Merchant dispute of a Marqeta-initiated chargeback (authorization.clearing.chargeback).

Possible states: REPRESENTMENT

Ledger impact: Negative if credit_user is true; none if credit_user is false and representment amount equals original amount; positive if credit_user is false and representment amount is less than original amount.

Possibly included objects: gpa, chargeback, user.metadata

authorization.incremental

Increases the amount of a prior authorization (authorization) by adding to it without replacing it.

Temporary transaction type. Requires settlement.

Possibly completed by: authorization.reversal

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

authorization.quasi.cash

Authorization at a point-of-sale terminal for items equivalent to cash, such as traveler’s checks, money orders, foreign currency, or gaming chips.

Temporary transaction type.

Possibly completed by: authorization.clearing.quasi.cash

authorization.reversal

Reverses or drops an authorization (authorization) due to elapsed time.

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

authorization.reversal.issuerexpiration

Reverses or drops an authorization (authorization) due to elapsed time; initiated by Marqeta.

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

Final transaction type.

Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token

directdeposit.credit

Credits funds to a deposit account.

Final transaction type.

State of associated direct deposit record: APPLIED

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.credit.pending

Pending credit of funds to a deposit account.

Temporary transaction type.

State of associated direct deposit record: PENDING

Possibly completed by directdeposit.credit, directdeposit.credit.reversal, directdeposit.credit.reject

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.credit.reject

Rejects a crediting of funds to a deposit account (directdeposit.credit).

Final transaction type.

State of associated direct deposit record: REJECTED

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.credit.pending.reversal

Reverses a pending credit of funds to a deposit account (directdeposit.credit.pending).

Final transaction type.

State of associated direct deposit record: REVERSED

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.credit.reversal

Reverses a credit of funds to a deposit account (directdeposit.credit).

Final transaction type.

State of associated direct deposit record: REVERSED

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.debit

Debits funds from a deposit account.

Final transaction type.

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.debit.pending

Pending debit of funds from a deposit account.

Temporary transaction type.

State of associated direct deposit record: PENDING

Possibly completed by: directdeposit.debit, directdeposit.debit.reversal, directdeposit.debit.reject

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.debit.reject

Rejects a debit of funds from a deposit account (directdeposit.debit).

Final transaction type.

State of associated direct deposit record: REJECTED

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.debit.reversal

Reverses a debit of funds from a deposit account (directdeposit.debit).

Final transaction type.

State of associated direct deposit record: REVERSED

Possibly included objects: gpa, direct_deposit, user.metadata

directdeposit.debit.pending.reversal

Reverses a pending debit of funds from a deposit account (directdeposit.debit.pending).

Final transaction type.

State of associated direct deposit record: REVERSED

Possibly included objects: gpa, direct_deposit, user.metadata

fee.charge

Fee assessed to a user.

Final transaction type.

Possibly completed by: fee.charge.reversal

Possibly included objects: gpa, gpa_order, fee_transfer

fee.charge.pending

Authorization with an associated fee.

Temporary transaction type.

Possibly completed by: fee.charge.reversal, fee.charge

Possibly included objects: gpa, gpa_order, fee_transfer

fee.charge.reversal

Reverses a transaction and its associated fee (fee.charge).

Possibly included objects: gpa, gpa_order, fee_transfer

gpa.credit

ACH deposit into a user’s GPA.

Final transaction type.

Possibly included objects: gpa, gpa_order

gpa.credit.authorization

Just-in-Time (JIT) Funding authorization for crediting funds to a user’s GPA (gpa.credit).

Temporary transaction type.

Possibly completed by: gpa.credit.pending.reversal, gpa.credit

Possibly included objects: gpa, gpa_order

gpa.credit.authorization.reversal

Reverses a JIT Funding authorization for crediting funds to a user’s GPA (gpa.credit.authorization).

Final transaction type.

Possibly included objects: gpa, gpa_order

gpa.credit.issueroperator

Admin function for crediting funds to any GPA . Functionally the same as gpa.credit.

Possibly included objects: gpa, gpa_order

gpa.credit.networkload

Loads funds through a card network service, such as Visa ReadyLink or Mastercard RePower, at a participating merchant location.

Final transaction type.

Possibly included objects: gpa

gpa.credit.networkload.reversal

Cancels the full amount of a load performed through a card network service (gpa.credit.networkload), such as Visa ReadyLink or Mastercard RePower. Permitted only on the same day as the load.

Final transaction type.

Possibly included objects: gpa

gpa.credit.pending

Pending ACH deposit into a user’s GPA.

Temporary transaction type.

Possibly completed by: gpa.credit.pending.reversal, gpa.credit

Possibly included objects: gpa, gpa_order

gpa.credit.pending.reversal

Reverses a pending ACH deposit into a user’s GPA (gpa.credit.pending).

Final transaction type.

Possibly included objects: gpa, gpa_order

gpa.credit.reversal

Reverses an ACH deposit into a user’s GPA (gpa.credit).

Final transaction type.

Possibly included objects: gpa, gpa_order

gpa.debit

Debits funds from a user’s GPA back into a funding source.

Possibly included objects: gpa

gpa.debit.issueroperator

Admin function to debit funds from any GPA. Functionally the same as gpa.debit.

Possibly included objects: gpa, gpa_order

gpa.debit.reversal

Reverses a debiting of funds from a user’s GPA back into a funding source (gpa.debit), thereby moving funds from the funding source back into the GPA.

Final transaction type.

Possibly included objects: gpa_order

original.credit.authorization

OCT authorization for crediting funds to a GPA.

Temporary transaction type.

Ledger impact: Positive.

Possibly included objects: original.credit.authorization.reversal, original.credit.authorization.clearing

original.credit.authorization.reversal

Reverses the financial impact of an OCT authorization (original.credit.authorization).

Final transaction type.

Ledger impact: Negative.

original.credit.authorization.clearing

Completes an OCT authorization (original.credit.authorization).

Final transaction type.

Ledger impact: Positive.

original.credit.auth_plus_capture

Single-message OCT for crediting funds to a GPA.

Ledger impact: Positive.

original.credit.auth_plus_capture.reversal

Reverses the financial impact of a single-message OCT (original.credit.auth_plus_capture).

Ledger impact: Negative.

pindebit

PIN-debit transaction at a point-of-sale terminal.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.atm.withdrawal

Withdraws cash at an ATM.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.authorization

PIN-debit authorization at an automated fuel dispenser (AFD).

Temporary transaction type.

Possibly completed by: pindebit.authorization.clearing, pindebit.authorization.reversal

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.authorization.clearing

Completes a PIN-debit authorization at an AFD (pindebit.authorization), or a PIN-debit authorization of pindebit.cashback where is_preauthorization = true.

Final transaction type.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.authorization.reversal

Reverses the financial impact of a PIN-debit authorization at an AFD (pindebit.authorization) when zero dollar PIN debit reversal is enabled.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.authorization.reversal.issuerexpiration

Authorization drop initiated by Marqeta due to elapsed time. Most transactions of this type originate from authorizations at AFDs.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.balanceinquiry

Balance inquiry via the card network e.g., at an ATM.

Non-financial transaction.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.cashback

PIN-debit transaction for cash back requested at a point-of-sale terminal.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.chargeback

Marqeta-initiated PIN-debit chargeback.

Possible states: INITIATED, PREARBITRATION, ARBITRATION

Ledger impact: Positive if credit_user is true; none if credit_user is false.

Possibly completed by: pindebit.chargeback.reversal, pindebit.chargeback.completed

Possibly included objects: gpa, chargeback, user.metadata

pindebit.chargeback.completed

Completes a PIN-debit chargeback initiated by Marqeta (pindebit.chargeback).

Possible states: CASE_WON

Ledger impact: Positive.

Possibly included objects: gpa, chargeback, user.metadata

pindebit.chargeback.provisional.credit

Provides a credit by moving a PIN-debit chargeback (pindebit.chargeback) from the workflow for non-provisional credit to provisional credit.

Final transaction type. Requires settlement.

Possibly included objects: gpa, chargeback, user.metadata

pindebit.chargeback.provisional.debit

Removes the initial credit by moving a PIN-debit chargeback (pindebit.chargeback) from the workflow for provisional credit to non-provisional credit.

Final transaction type. Requires settlement.

Possibly included objects: gpa, chargeback, user.metadata

pindebit.chargeback.reversal

Reverses a rejected, Marqeta-initiated, PIN-debit chargeback (pindebit.chargeback).

Possible states: CASE_LOST, NETWORK_REJECTED

Ledger impact: Negative if credit_user is true; none if credit_user is false.

Possibly included objects: gpa, chargeback, user.metadata

pindebit.chargeback.writeoff

Writes off the PIN-debit chargeback (pindebit.chargeback) and credits the account holder while Marqeta or its customer absorbs the cost.

Final transaction type.

Possible states: WRITTEN_OFF_PROGRAM, WRITTEN_OFF_ISSUER

Ledger impact: Positive.

Possibly included objects: gpa, chargeback, user.metadata

pindebit.credit.adjustment

Offsets the amount of non-AFD transactions (PIN-debit cashback [pindebit.cashback] or PIN-debit withdrawal [pindebit.atm.withdrawal]) as needed.

Final transaction type.

Possibly included objects: card_acceptor, gpa, gpa_order

pindebit.quasi.cash

PIN-debit transaction at a point-of-sale terminal for items equivalent to cash, such as traveler’s checks, money orders, foreign currency, or gaming chips.

pindebit.refund

Refunds a PIN-debit transaction (pindebit).

Possibly included objects: card_acceptor, gpa

pindebit.refund.reversal

Reverses a PIN-debit refund (pindebit.refund).

Possibly included objects: card_acceptor, gpa, merchant, gpa_order_unload, user, card

pindebit.representment

Merchant dispute of a Marqeta-initiated chargeback (authorization.clearing.chargeback).

Possible states: REPRESENTMENT

Ledger impact: Negative if credit_user is true; none if credit_user is false and representment amount equals original amount; positive if credit_user is false and representment amount is less than original amount.

Possibly included objects: gpa, chargeback, user.metadata

pindebit.reversal

Reverses the financial impact of a PIN-debit transaction (pindebit) or PIN-debit authorization (pindebit.authorization) when zero dollar PIN debit reversal is not enabled.

Possibly included objects: card_acceptor, gpa, user.metadata

pindebit.transfer

ATM transfer between a checking and a savings account.

programreserve.credit

Credits funds from a program funding account (sometimes referred to as a program reserve account).

programreserve.debit

Debits funds from a program funding account (sometimes referred to as a program reserve account).

pushtocard.pending

The state of a Push-to-Card transaction until a response (success or failure) has been received and the state changes to pushtocard.debit.

pushtocard.debit

Debits funds from a Push-to-Card payment card.

pushtocard.reversal

Reverses a debit of funds from a Push-to-Card payment card (pushtocard.debit).

refund

Refunds a cardholder’s transaction.

Possibly included objects: card_acceptor, gpa

refund.authorization

Authorization for a purchase return.

Temporary transaction type.

Possibly completed by: refund.authorization.reversal, refund.authorization.clearing

refund.authorization.clearing

Completes a purchase return authorization (refund.authorization).

refund.authorization.reversal

Reverses a purchase return authorization (refund.authorization).

token.activation-request

Request to activate a digital wallet token.

transfer.peer

Moves money between GPAs. Results from sending a request to the /peertransfers endpoint.

Possibly included objects: gpa, peer_transfer

transfer.program

Movement of funds from the cardholder’s GPA to the program funding source. Results from using the /programtransfers endpoint.

Possibly included objects: gpa, programtransfers

unknown

Helps identify transaction errors. Unlikely to occur.

The following is a sample transaction notification. The type and amount fields are always returned. Other fields and object groups are conditionally returned. Refer to the preceding table for a list of objects possibly included for each transaction type.

JSON
Copied

Is this helpful?

Yes
No

Possible values for cardholder_presence field

Code Description

0

Cardholder not present

1

Cardholder present

Possible values for card_presence field

Code Description

0

Card not present

1

Card present

For more information about the transactions object, see Transactions.

Subscribe to our developer newsletter