type field further categorizes an event notification by specifying the attempted transaction type, and the transaction response code describes the outcome of that attempt. For example:
-
A combination of the
authorizationtransaction type and1001response code indicates a card authorization attempt that failed because the card was expired. -
A combination of the
authorizationorpindebittransaction type with a0000,0002, or1830response code indicates a successful transaction. All other response codes indicate failed transactions.
3D Secure transition events
3D Secure (3DS) transition events include activities for when a merchant requests 3D Secure authentication for a transaction (i.e., thethreedstransition.initialization event), as well as when the Marqeta platform sends the merchant the outcome of the authentication request (i.e., the threedstransition.completion event).
The Marqeta platform supports 3D Secure version 2.x.
The following example shows a 3D Secure 2.x initialization notification message:
JSON
JSON
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. |
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
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 a 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 EventTypebanktransfertransition.
| 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. |
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
banktransfers object, see Funding via ACH.
Bill payment transition events
Bill payment transition events include activities such as a bill payment being transitioned to a pending, completed, failed, returned, or canceled state. Bill payment transition notifications are sent when status transition events occur and contain detailed information about the events. Transition events will be sent with thebillpayment event type.
| Type | Status | Description |
|---|---|---|
status.pending | PENDING | The bill payment is transitioned to the PENDING state. |
status.completed | COMPLETED | The bill payment is transitioned to the COMPLETED state. |
status.failed | FAILED | The bill payment is transitioned to the FAILED state. |
status.returned | RETURNED | The bill payment has been returned by the payment processor and transitioned to the RETURNED state. |
status.cancelled | CANCELLED | The bill payment has been canceled by the program and transitioned to the CANCELLED state. |
billpayment element. Multiple notifications can be included in a single notification message. The structure of each individual notification is identical to that of a billpayment object returned by the /billpay/payments endpoint.
The following example shows a notification message containing a notification that a bill payment has been submitted and is in the COMPLETED state.
JSON
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’sstate 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.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. |
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
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 atype 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. |
JSON
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’sstate 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. |
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
prearbitration.responded event, specific to Fraud and Authorization reason codes only:
JSON
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 thecurrent_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. |
JSON
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’sis_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. |
credit.delinquencytransition.current event.
JSON
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’sstatus 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. |
credit.paymenttransition.completed event.
JSON
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 thetype 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
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’sstatus 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. |
credit.accounttransition.status.activated event.
JSON
creditaccounttransitions object, see Retrieve account transition.
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 atype 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 |
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
creditjournalentries object, see Retrieve account journal entry.
Credit ledger entry events
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 atype 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. |
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
creditledgerentries object, see Retrieve account ledger entry.
Credit product transition events
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 astatus 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. |
credit.producttransition.state.activated event.
JSON
creditproducttransitions object, see Retrieve credit product.
Credit reward entry events
Credit reward entry events include information about credit reward activity, such as creating a credit reward entry or posting a credit reward entry to a credit account. Credit reward entry notifications are sent when credit reward entry events occur. These notifications contain detailed information about credit reward entry events, such as the transaction amount, the value of the credit reward entry, and any related tokens. For more on webhooks, see Webhooks. The following example shows a notification for acreditrewardentry event.
JSON
Credit reward accounts events
Credit reward account events include information related to a reward account: for example, whether the credit reward account is active or not, and any credit rewards rules associated with it. For more on webhooks, see Webhooks. The following example shows a notification for acreditrewardaccounts event.
JSON
Credit reward redemptions events
Credit reward redemption events include information about the credit reward redemption type, destination, amount, and currency. Credit reward redemption events can also include information about the conversion rate between credit rewards points and dollar amounts to be credited to the corresponding credit account, if the redemption type is set toSTATEMENT_CREDIT.
For more on webhooks, see Webhooks.
The following example shows a notification for a creditredemptions event.
JSON
Credit substatus events
Credit substatus events occur when a substatus is applied or removed from a resource. When configuring a webhook to subscribe to credit events, set thetype value to credit.*. This enables Marqeta to send notifications for all credit events, including credit substatus events. For more information, see Webhooks.
| Event Type | Description |
|---|---|
substatus | A substatus was created or updated. |
credit.substatus event in which a substatus is added to a resource.
JSON
credit.substatus event for updating a substatus.
JSON
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’sstate 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. |
| update | Indicates that the token expiry date has been updated. |
Note
The token-related event type
The token-related event type
token.activation-request is categorized as a transaction event and is documented in the Transaction events section.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
digitalwallettokentransitions object, see Digital Wallets Management.
Direct deposit transition events
Direct deposit transition events include activities such as a direct deposit being applied, reversed, rejected, or set to pending. Transitioning the ACH transaction’sstate 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 funds can be posted to the account holder. These webhooks are sent as part of the Settlement job. |
REVERSED | The ACH transaction was in a pending or settled state, but now has been reversed and the funds will be returned to the ODFI. These webhooks are sent as part of the Return job. |
REJECTED | The ACH transaction could not be initiated, often because an invalid account number or inactive account. The funds will be returned to the ODFI. These webhooks are sent as part of the Return job. NOTE: Transactions webhooks will no longer be sent for REJECTED transactions since there are no associated ledger entries. |
PENDING | The ACH transaction was processed and is in the PENDING state awaiting settlement. These webhooks are sent as part of the File Processing job. |
directdeposittransition.applied event.
JSON
directdeposittransition.reversed event, when the available balance is insufficient to cover the dollar value of the debit entry.
JSON
directdeposittransition.rejected event, when the account could not be located.
JSON
directdeposittransition.rejected event, when the originator’s identity is unknown or the originator is not authorized to debit.
JSON
directdeposittransition.pending event.
JSON
/directdeposits/transitions endpoint, see ACH Receiving.
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’sstate 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 should be held. ACH credits and debits will be REJECTED or REVERSED. 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 and debits—including ACH—will be rejected. |
directdepositaccounttransition.suspended event.
JSON
/depositaccounts/transitions endpoint, see Deposit Accounts.
KYB results event
Thekybresults 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
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.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
outcome_reasons in the kybresults array, see Business KYC outcome reasons.
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 thetype value to authorization.clearing.l2l3.
The following example shows an authorization.clearing.l2l3 event.
JSON
JSON
Smart rejects
When a user submits a dispute that would eventually be rejected by the network, smart reject rules allow those disputes to be rejected earlier in the dispute lifecycle, minimizing the operational cost. Smart rejects are implemented through webhooks. Thecases 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 are disputes with smart reject rules:
- Fraud dispute on a 3DS transaction
- Incorrect Transaction Amount without supporting document
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 thetype value in the subscription request to caseevent.*.
The following example shows the cases.smart.reject event.
JSON
Smart reject for Incorrect Transaction Amount without supporting document
If you initiate a dispute with the network using the/cases endpoint without a copy of the transaction receipt or other record with the correct transaction amount, the dispute will be smart rejected and the moved to Open with Action Required.
The following example shows the cases.smart.reject event.
JSON
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 atype 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.returnedPossibly included objects: transaction_attributes, gpaPossibly 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: COMPLETEDPossibly followed by: ach.pull.returnedPossibly included objects: transaction_attributes, gpaPossibly 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: PENDINGPossibly completed by: ach.push, ach.cancel, ach.push.returnedPossibly included objects: transaction_attributes, gpaPossibly 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: COMPLETEDPossibly followed by: ach.push.returnedPossibly included objects: transaction_attributes, gpaPossibly 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: CANCELLEDPossibly included objects: transaction_attributes, gpaPossibly 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: RETURNEDPossibly included objects: transaction_attributes, gpaPossibly 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: RETURNEDPossibly included objects: transaction_attributes, gpaPossibly 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.clearingPossibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token |
authorization.account_verification | Authorization request for account verification. Also known as a zero-dollar authorization. An account verification request allows acquirers to verify a card without putting a hold on funds. |
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.clearingPossibly 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.completedPossibly included objects: gpa, chargeback, user.metadataPossible 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.metadataPossible states: CASE_WONLedger 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.metadataPossible states: CASE_LOST, NETWORK_REJECTEDLedger 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.metadataPossible states: WRITTEN_OFF_PROGRAM, WRITTEN_OFF_ISSUERLedger 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: REPRESENTMENTLedger 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.reversalPossibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token |
authorization.pin.change | ATM transaction that changes the card’s online PIN and offline PIN. NOTE: PIN change transactions are currently in beta and are subject to change without notice. |
authorization.pin.unblock | ATM transaction that: - Reactivates the card if it was suspended due to a PIN_RETRY_EXCEEDED error.- Resets the online PIN retry attempt counter to zero. - Resets the offline PIN retry attempt counter on the EMV chip to zero. NOTE: PIN change transactions are currently in beta and are subject to change without notice. |
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_tokenFinal transaction type. Possibly included objects: card_acceptor, gpa, user.metadata, digital_wallet_token |
balanceinquiry | Returns account balance information. Possibly included objects: balances |
billpay.pending | Creates a pending bill payment. Temporary transaction type. State of the associated bill payment record: PENDINGPossibly included objects: gpa, billpay |
billpay.complete | Completes a bill payment. Final transaction type. State of the associated bill payment record: COMPLETEPossibly included objects: gpa, billpay |
billpay.cancelled | Cancels a pending bill payment. Final transaction type. State of the associated bill payment record: CANCELLEDPossibly included objects: gpa, billpay |
billpay.returned | Returns a pending bill payment. Final transaction type. State of the associated bill payment record: RETURNEDPossibly included objects: gpa, billpay |
billpay.failed | Indicates a failed bill payment. Final transaction type. State of the associated bill payment record: FAILEDPossibly included objects: gpa, billpay |
directdeposit.credit | Credits funds to a deposit account. Final transaction type. State of associated direct deposit record: APPLIEDPossibly 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: PENDINGPossibly completed by directdeposit.credit, directdeposit.credit.reversal, directdeposit.credit.rejectPossibly 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: REJECTEDPossibly 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: REVERSEDPossibly 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: REVERSEDPossibly 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: PENDINGPossibly completed by: directdeposit.debit, directdeposit.debit.reversal, directdeposit.debit.rejectPossibly 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: REJECTEDPossibly 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: REVERSEDPossibly 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: REVERSEDPossibly included objects: gpa, direct_deposit, user.metadata |
fee.charge | Fee assessed to a user. Final transaction type. Possibly completed by: fee.charge.reversalPossibly 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.chargePossibly 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 | A transfer of funds 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.creditPossibly 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.creditPossibly 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.authorization | Just-in-Time (JIT) Funding authorization for debiting funds from a user’s GPA (gpa.debit).Temporary transaction type. Possibly completed by: gpa.debit.reversal, gpa.debitPossibly included objects: gpa, gpa_order |
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 |
open.banking.fps.debit.hold | A pending Faster Payment Service (FPS) open banking transaction initiated by an external beneficiary that debits the cardholder and credits the external beneficiary. |
open.banking.fps.debit.clear | A cleared FPS open banking transaction initiated by an external beneficiary that debits the cardholder and credits the external beneficiary. |
open.banking.fps.debit.hold.reverse | Reverses a pending FPS open banking transaction. |
open.banking.fps.debit.clear.reverse | Reverses a cleared FPS open banking transaction. |
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. |
pin.change.reversal | Reversal transaction that typically follows a PIN change transaction (pindebit.pin.change or authorization.pin.change) when the PIN change transaction updated the online PIN successfully, but failed to update the offline PIN. Restores the previous online PIN to keep it synchronized with the offline PIN.NOTE: PIN change transactions are currently in beta and are subject to change without notice. |
pin.change.reversal.advice | Reversal advice transaction that typically follows a PIN change transaction (pindebit.pin.change or authorization.pin.change) when the PIN change transaction updated the online PIN successfully, but failed to update the offline PIN. Restores the previous online PIN to keep it synchronized with the offline PIN.NOTE: PIN change transactions are currently in beta and are subject to change without notice. |
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.reversalPossibly 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).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, ARBITRATIONLedger impact: Positive if credit_user is true; none if credit_user is false.Possibly completed by: pindebit.chargeback.reversal, pindebit.chargeback.completedPossibly included objects: gpa, chargeback, user.metadata |
pindebit.chargeback.completed | Completes a PIN-debit chargeback initiated by Marqeta (pindebit.chargeback).Possible states: CASE_WONLedger 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_REJECTEDLedger 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_ISSUERLedger 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.pin.change | PIN-debit transaction at an ATM that changes the card’s online PIN and offline PIN. NOTE: PIN change transactions are currently in beta and are subject to change without notice. |
pindebit.pin.unblock | PIN-debit transaction at the ATM that: - Reactivates the card if it was suspended due to a PIN_RETRY_EXCEEDED error.- Resets the online PIN retry attempt counter to zero. - Resets the offline PIN retry attempt counter on the EMV chip to zero. |
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: REPRESENTMENTLedger 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).Possibly included objects: card_acceptor, gpa, user.metadata |
pindebit.transfer | ATM transfer between a checking and a savings account. |
product.inquiry | A zero-dollar authorization request to determine Visa Flexible Credential eligibility. |
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. |
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
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 |
transactions object, see Transactions.