Business Flows

1. JIT transaction lifecycle

Transactions can be authorized, cleared, and settled either as dual-message transactions or as single-message transactions. The processing method may vary depending upon the payment method issuer, the type of card, or the region where the transaction takes place:

  • In a single-message transaction, the merchant submits a single electronic message containing all data required for the authorization, clearing, and settlement of the transaction.

  • In a dual-message transaction, at the time of purchase, the merchant submits an electronic message containing the information required for an authorization decision. At a later point in time, the merchant submits a second message containing additional data required for clearing and settlement.

The Marqeta platform creates transaction objects from the electronic messages received from the card network. From the moment of their creation, transaction objects are immutable, with the exception of the state attribute.

How transactions transition through different states during their lifecycle depends on whether they are temporary or final transactions. Temporary and final transactions are closely related to single-message and dual-message transactions.

A dual-message transaction requires two or more transaction messages to complete, for example:

  • At the time of purchase, the merchant submits an electronic message containing the information required for an authorization decision.
  • At a later point in time, the merchant submits another electronic message containing additional data required for clearing and settlement.

In this scenario, the first message is a temporary transaction, which means it can be reversed. The last message is a final transaction. Temporary transaction messages, such as authorizations, are handled synchronously, which means a transaction message flows in real time from the merchant to the issuer processor and then back to the merchant. Final transaction messages are handled asynchronously, because capture requests can be submitted at a later time.

Marqeta events handled in the connector with respect to the categorization described above:

JIT EndpointMarqeta eventEvent stateSingle messageDual message
JIT ActionablebalanceinquiryPENDING
JIT Actionablepindebit.balanceinquiryPENDING
JIT ActionableauthorizationPENDING
JIT Actionableauthorization.incrementalPENDING
JIT Actionablerefund.authorizationPENDING
JIT Actionableoriginal.credit.authorizationPENDING
JIT Actionableauthorization.quasi.cashPENDING
JIT Actionableauthorization.atm.withdrawalPENDING
JIT Actionableauthorization.cashbackPENDING
JIT Actionablepindebit.authorizationPENDING
JIT ActionablepindebitCOMPLETION
JIT Actionablepindebit.atm.withdrawalCOMPLETION
JIT Actionablepindebit.cashbackCOMPLETION
JIT Actionableoriginal.credit.auth_plus_captureCOMPLETION
JIT Informativeauthorization.clearing.representmentCOMPLETION
JIT Informativeauthorization.clearingCOMPLETION
JIT InformativeauthorizationDECLINED
CLEARED
JIT Informativeauthorization.atm.withdrawalDECLINED
CLEARED
JIT Informativeauthorization.quasi.cashDECLINED
CLEARED
JIT Informativerefund.authorizationDECLINED
CLEARED
JIT Informativeoriginal.credit.authorizationDECLINED
CLEARED
JIT Informativeauthorization.cashbackDECLINED
CLEARED
JIT Informativeauthorization.incrementalDECLINED
JIT InformativerefundCOMPLETION
JIT Informativepindebit.refundCOMPLETION
JIT Informativeauthorization.reversalCLEARED
JIT Informativeauthorization.advicePENDING
JIT Informativerefund.authorization.clearingCOMPLETION
JIT Informativeauthorization.reversal.issuerexpirationCLEARED
JIT Informativepindebit.authorization.reversal.issuerexpirationCLEARED
JIT Informativeoriginal.credit.authorization.clearingCOMPLETION
JIT Informativeoriginal.credit.authorization.reversalCLEARED
JIT Informativeauthorization.clearing.atm.withdrawalCOMPLETION
JIT Informativeauthorization.clearing.quasi.cashCOMPLETION
JIT Informativerefund.authorization.reversalCLEARED
JIT Informativeauthorization.clearing.cashbackCOMPLETION
JIT Informativeauthorization.standinCOMPLETION
JIT Informativepindebit.authorization.clearingCOMPLETION
JIT Informativepindebit.reversalCOMPLETION
JIT Informativeauthorization.clearing.chargebackCOMPLETION
JIT Informativeauthorization.clearing.chargeback.completedCOMPLETION
JIT Informativepindebit.chargebackCOMPLETION
JIT Informativepindebit.chargeback.completedCOMPLETION

2. Business use cases

The main business flows supported by the Mambu-Marqeta integration are the following.

A. Actionable events

The JIT Actionable Receiver process handles authorization holds and creation of financial transactions, authorization incremental and balance inquiry requests. JIT Actionable Receiver can be called synchronously using MPO Sync API. For these types of events, Marqeta requires a response from the connector. More details about this can be found in the integration setup section.

  1. JIT Authorization DEBIT events
    • authorization
    • authorization.quasi.cash
    • authorization.atm.withdrawal
    • authorization.cashback
    • pindebit.authorization
  2. JIT Authorization INCREMENTAL events
    • authorization.incremental

Technical note: For these types of authorization, Marqeta is performing a GPA load event, where funds are loaded into a General Purpose Account (GPA) translated through the presence of the gpa_order object in the payload.

  1. JIT Authorization CREDIT events
    • refund.authorization
    • original.credit.authorization

Technical note: For these types of authorization, Marqeta is performing a GPA unload event, where funds are removed from a GPA translated through the presence of the gpa_order_unload object in the payload.

  1. JIT DBIT Financial Transaction events
    • pindebit
    • pindebit.atm.withdrawal
    • pindebit.cashback
  2. JIT CRDT Financial Transaction events
    • original.credit.auth_plus_capture
  3. JIT Actionable Balance Inquiry event
    • balanceinquiry
    • pindebit.balanceinquiry

Balance inquiry

Trigger: JIT Actionable request from Marqeta
Process: Balance inquiry request
Prerequisite: None

Marqeta connector responds with the currently available balance for the account associated with the specified card for each balance inquiry request. If the request is successful the JIT Actionable Gateway responds to Marqeta with HTTP code 200 and with the jit_funding object received from the JIT Actionable Receiver Mambu Process Orchestrator (MPO) process is:

"jit_funding": {
        "token": "testToken1",
        "method": "pgfs.balanceinquiry",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "balances": {
            "EUR": {
                "currency_code": "EUR",
                "ledger_balance": 319.96,
                "available_balance": 312.96
            }
        }
    }

If the request fails, the JIT Actionable Gateway responds to Marqeta with HTTP code 402 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

 "jit_funding": {
        "token": "testToken1",
        "method": "pgfs.balanceinquiry",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "decline_reason": "SUSPECTED_FRAUD",
        "tags": "No card reference was found for the specified token: euroToken123"
    }

Based on the error reason reported by Mambu, the JIT Actionable Receiver process selects the appropriate Marqeta funding response and sends either the SUSPECTED_FRAUD or TRANSACTION_NOT_PERMITTED values to Marqeta for the decline_reason. See more details about how Mambu errors are mapped to Marqeta authorization responses here. Marqeta events that will trigger the account balance retrieval in Mambu:

  • balanceinquiry
  • pindebit.balanceinquiry

Create Authorization Hold

Trigger: JIT Actionable request from Marqeta
Mambu action: Create Authorization Hold
Prerequisite: None

The balance of the Mambu account will be verified before the authorization hold is created. The hold can be for credit or debit cards.

If the authorization hold is successful, the JIT Actionable Gateway responds to Marqeta with HTTP code 200 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

"jit_funding": {
        "token": "testToken1",
        "amount": 10,
        "method": "pgfs.authorization",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "memo": "Approved"
    }

If the authorization hold fails, the JIT Actionable Gateway responds to Marqeta with HTTP code 402 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

 "jit_funding": {
        "token": "testToken1",
        "amount": 10,
        "method": "pgfs.authorization",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "decline_reason": "INSUFFICIENT_FUNDS",
        "tags": "The account balance is insufficient for the operation. Transaction Amount: 7.5; Available Amount E-10; Exceeded Amount: 7.5;"
    }

Based on the error reason reported by Mambu, the JIT Actionable Receiver process selects the appropriate Marqeta funding response and one of the following values for the decline_reason is sent to Marqeta: INSUFFICIENT_FUNDS, DUPLICATE_TRANSACTION, SUSPECTED_FRAUD, or TRANSACTION_NOT_PERMITTED.See more details about how Mambu errors are mapped to Marqeta authorization responses here.

If the JIT Actionable Gateway does not respond to Marqeta within three seconds, the process will time out. Two possible cases can occur:

  • The authorization hold posting fails.
  • The authorization hold is performed even though Marqeta received a timeout error.

For either case, Marqeta sends two notifications to the JIT Informative Receiver with the status = “DECLINED”.

For the first case, where authorization hold posting fails, a reversal of the Authorization Hold is triggered in MPO. If the Authorization Hold reference is not found this is without any business implications.

For the second case, if the Authorization Hold has been successfully posted through the JIT Actionable process, it will be reversed.

The Marqeta events that trigger posting authorization holds in Mambu are:

  • authorization
  • authorization.quasi.cash
  • authorization.atm.withdrawal
  • authorization.cashback
  • refund.authorization
  • original.credit.authorization
  • pindebit.authorization

Technical note: The pindebit.authorization event is a temporary event type and represents the authorization initiated at an automated fuel dispenser (AFD).

Increase Authorization Hold

Trigger: JIT Actionable request from Marqeta
Mambu action: Increase Authorization Hold
Prerequisite: Authorization Hold exists

Only debit type authorization holds can be increased.

If the increase of the authorization hold is successful, the JIT Actionable Gateway responds to Marqeta with HTTP code 200 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

"jit_funding": {
        "token": "testToken1",
        "amount": 10,
        "method": "pgfs.authorization",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "memo": "Approved"
    }

If the increase of the authorization hold fails, the JIT Actionable Gateway responds to Marqeta with HTTP code 402 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

 "jit_funding": {
        "token": "testToken1",
        "amount": 10,
        "method": "pgfs.authorization",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "decline_reason": "TRANSACTION_NOT_PERMITTED",
        "tags": "No authorization hold was found with the following identifier: cardReferenceToken=**REMOVED**, externalReferenceID='**REMOVED**'"
    }

The JIT Actionable Receiver process will send one of the following values for decline_reason based on the error reported by Mambu: INSUFFICIENT_FUNDS, DUPLICATE_TRANSACTION, SUSPECTED_FRAUD, or TRANSACTION_NOT_PERMITTED. See more details about mapping decline_reason to Mambu error codes here.

The failed Authorization Increase requests are stored in MPO, in the Failed Incremental Authorizations state diagram. This avoids the erroneous reversal of an incremental authorization that has not been performed in Mambu.

The process will time out if the JIT Actionable Gateway does not respond to Marqeta within three seconds. Two possible cases can occur:

  • The authorization increase posting fails.
  • The authorization increase is performed even though Marqeta received a timeout error.

For either case, Marqeta sends two notifications to the JIT Informative Receiver with the status = “DECLINED”. A reversal of the Authorization Increase operation is triggered in MPO. If the Authorization Increase task is not found in the Failed Incremental Authorizations state diagram, then the process continues with decreasing the authorization by the provided amount.

Technical note: Failed Incremental requests can be stored in the Failed Incremental Authorizations state diagram for a configurable number of days.

The authorization.incremental event in Marqeta triggers the increment authorization hold action in Mambu.

Pindebit Financial Transactions

Trigger: JIT Actionable request from Marqeta
Process: Create DBIT Financial Transaction request
Prerequisite: None

These transactions occur when a cardholder attempts to make a payment using their PIN. Such a transaction typically contains all information required for authorization and clearing in a single electronic message. The balance of the Mambu account will be verified before the financial transaction is created.

If the financial transaction is successful, the JIT Actionable Gateway responds to Marqeta with HTTP code 200 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

"jit_funding": {
        "amount": 1.23,
        "memo": "Approved",
        "method": "pgfs.auth_plus_capture",
        "token": "testToken1",
        "user_token": "<removed>",
        "acting_user_token": "<removed>"
    }

If the financial transaction fails, the JIT Actionable Gateway responds to Marqeta with HTTP code 402 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

 "jit_funding": {
        "token": "testToken1",
        "amount": 10,
        "method": "pgfs.auth_plus_capture",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "decline_reason": "INSUFFICIENT_FUNDS",
        "tags": "The account balance is insufficient for the operation. Transaction Amount: 7.5; Available Amount E-10; Exceeded Amount: 7.5;"
    }

Based on the error reason reported by Mambu, the JIT Actionable Receiver process selects the appropriate Marqeta funding response and one of the following values for the decline_reason is sent to Marqeta: INSUFFICIENT_FUNDS, DUPLICATE_TRANSACTION, SUSPECTED_FRAUD, or TRANSACTION_NOT_PERMITTED. See more details about how Mambu errors are mapped to Marqeta authorization responses here.

If JIT Actionable Gateway does not respond to Marqeta within three seconds the process will time out. Two possible cases can occur:

  • The financial transaction posting fails.
  • The financial transaction is performed even though Marqeta received a timeout error.

For either case, Marqeta initiates the reversal of the Finacial Transaction in MPO. For the first case, without any business implication if the Financial Transaction reference is not found. For the second case, it will be reversed if the Financial Transaction has been successfully posted through the JIT Actionable process.

Marqeta events that trigger posting financial transactions in Mambu:

  • pindebit
  • pindebit.atm.withdrawal
  • pindebit.cashback.

The Marqeta Connector supports custom fields logic for pindebit financial transactions.

Original Credit Authorization plus Capture

Trigger: JIT Actionable request from Marqeta
Process: Create CRDT Financial Transaction request
Prerequisite: None

If the financial transaction is successful, the JIT Actionable Gateway responds to Marqeta with HTTP code 200 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

"jit_funding": {
        "amount": 1.23,
        "memo": "Approved",
        "method": "pgfs.auth_plus_capture",
        "token": "testToken1",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
    }

If the financial transaction fails, the JIT Actionable Gateway responds to Marqeta with HTTP code 402 and with the jit_funding object received from the JIT Actionable Receiver MPO process is:

 "jit_funding": {
        "token": "testToken1",
        "amount": 10,
        "method": "pgfs.auth_plus_capture",
        "user_token": "<removed>",
        "acting_user_token": "<removed>",
        "decline_reason": "SUSPECTED_FRAUD",
        "tags": "No card reference was found for the specified token: testCardToken"
    }

Based on the error reason reported by Mambu, the JIT Actionable Receiver process selects the appropriate Marqeta funding response and one of the following values for the decline_reason is sent to Marqeta: DUPLICATE_TRANSACTION, SUSPECTED_FRAUD, or TRANSACTION_NOT_PERMITTED. See more details about how Mambu errors are mapped to Marqeta authorization responses here.

If JIT Actionable Gateway does not respond to Marqeta within three seconds the process will time out. Two possible cases can occur:

  • The financial transaction posting fails.
  • The financial transaction is performed even though Marqeta received a timeout error.

For either case, Marqeta initiates the reversal of the Financial Transaction in MPO. For the first case, without any business implication if the Financial Transaction reference is not found. For the second case, it will be reversed if the Financial Transaction has been successfully posted through the JIT Actionable process.

The original.credit.auth_plus_capture event in Marqueta triggers posting credit financial transactions in Mambu.

The Marqeta Connector supports custom fields logic for original credit authorization plus capture financial transactions.

B. Informative events

The JIT Informative Notifications Receiver process handles clearing and chargeback transactions, reversals, declined authorizations, authorization decrease, and authorization stand-in requests. JIT Informative Receiver can be called via MPO sync API functionality.

This process has two main responsibilities, listed below.

1. Validations

Events format validation

Validates the incoming events for mandatory parameters and responds to Marqeta if the batch is valid or not. See below the events in scope for the batch validation:

[
"authorization.clearing",
"authorization.clearing.atm.withdrawal",
"authorization.clearing.cashback",
"authorization.clearing.quasi.cash",
"original.credit.authorization.clearing",
"refund.authorization.clearing",
"pindebit.refund",
"refund",
"authorization.clearing.representment",
"pindebit.authorization.clearing",
"authorization.clearing.chargeback",
"authorization.clearing.chargeback.completed",
"pindebit.chargeback",
"pindebit.chargeback.completed"
]

Each event to be filtered is checked for the presence of the following parameters: state, token, card_token, currency_code, or the jit_funding object.
The chargeback events are checked for mandatory parameters listed above,chargeback object and chargeback.token only if the gpa_order_unload.jit_funding object is present in the payload. Otherwise, the validation process is skipped.

Event type validation

Each incoming event is checked for the presence of the parameter type, which is a decision related to the transaction type that needs to be posted in Mambu, and is given a dedicated name that is later used in the routing logic.

In the case of chargeback events the JIT Informative Receiver first checks for the presence of the gpa_order_unload.jit_funding object in order to decide if the event needs to be validated further.

  • if the gpa_order_unload.jit_funding object is present → batch validation continues with state, token, card_token and currency_code checks;
  • if the gpa_order_unload.jit_funding object is not present → batch validations are skipped.
    The chargeback events are sent for further processing by the JIT Informative Receiver only if the gpa_order_unload.jit_funding object is present, otherwise they are ignored.

2. Events processing

If the batch is valid, the transactions are processed one-by-one by sending them to the corresponding sub-process responsible of handling the specific event type.

The main categories of events that are processed by the JIT Informative Receiver are:

  • Debit Authorization Clearings
  • Credit Authorization Clearings
  • Declined or Expired Authorization Holds (trigger reverse authorization hold action in Mambu)
  • Authorization Reversal and Decrease (trigger decrease authorization hold action in Mambu)
  • Authorization Stand-in (creates a reservation on a card account without checking available balance)
  • Reverse Card Transactions

Informative notifications handled by the JIT Informative Notification Receiver are:

  1. JIT Declined or Cleared Authorization events
    • authorization
    • authorization.atm.withdrawal
    • authorization.quasi.cash
    • authorization.cashback
    • refund.authorization
    • original.credit.authorization
  2. JIT Clearing DEBIT events
    • authorization.clearing
    • authorization.clearing.atm.withdrawal
    • authorization.clearing.quasi.cash
    • authorization.clearing.cashback
    • authorization.clearing.representment
    • pindebit.authorization.clearing
  3. JIT Clearing CREDIT events
    • refund
    • refund.authorization.clearing
    • original.credit.authorization.clearing
    • pindebit.refund
    • authorization.clearing.chargeback
    • authorization.clearing.chargeback.completed
    • pindebit.chargeback
    • pindebit.chargeback.completed
  4. JIT Authorization reversal events
    • refund.authorization.reversal
    • original.credit.authorization.reversal
    • authorization.reversal
    • authorization.reversal.issuerexpiration
    • pindebit.authorization.reversal.issuerexpiration
    • authorization.advice
    • authorization.incremental
  5. JIT authorization.standin event
    • authorization.standin
  6. JIT Card transaction reversal event
    • pindebit.reversal

Under certain conditions, if the transaction processing fails due to technical errors that might occur in the JIT Informative Receiver, the processing of failed transactions is resumed.

More details about the events handled by the connector and the transaction types that could potentially complete them, can be found by accessing this link.

Clear Authorization Hold

Trigger: JIT Informative request from Marqeta
Mambu action: Post financial transaction by settling an authorization hold
Prerequisite: Authorization Hold (debit or credit) exists

The processing of this event consists of the following steps:

  1. The batch of transactions that includes this event is verified in MPO for the presence of mandatory parameters.
  2. If the batch is valid, the JIT Informative Notifications Gateway responds to Marqeta with HTTP code 200 and the transactions continue to be processed:
    • If the Clearing Authorization Hold request is successful, the hold is settled and the corresponding transaction is posted in Mambu:
      • For Credit Authorization clearing a deposit transaction is logged.
      • For Debit Authorization clearing a withdrawal transaction is logged.
    • If the Clearing Authorization Hold request fails, a notification is sent to the user responsible as a Mambu task and the error is saved in the Errors state diagram in MPO.
  3. If the batch is not valid, the JIT Informative Notifications Gateway responds to Marqeta with HTTP code 402 and the flow is stopped.

Marqeta events that trigger the authorization hold clearing action in Mambu are:

  • authorization.clearing
  • authorization.clearing.atm.withdrawal
  • authorization.clearing.quasi.cash
  • authorization.clearing.cashback
  • refund.authorization.clearing
  • original.credit.authorization.clearing

Where the state field contains the valueCOMPLETION.

The connector creates a financial transactions for the listed event types even if the referenced authorization hold is not found or its state is invalid. See Transactions without pre-authorization section below.

Transactions without pre-authorization

Trigger: JIT Informative request from Marqeta
Mambu action: Post financial transaction
Prerequisite: Authorization Hold does not exist or it is already cleared

The processing of this event consists of the following steps:

  1. The batch of transactions that includes this event is verified in MPO for the presence of mandatory parameters.
  2. If the batch is valid, the JIT Informative Notifications Gateway responds to Marqeta with HTTP code 200 and the transactions continue to be processed:
    • If the request is successful the financial transaction is posted in Mambu.
    • If the request fails, a notification is sent to the user responsible as a Mambu task and the error is saved in the Errors state diagram.
  3. If the batch is not valid, the JIT Informative Notifications Gateway responds to Marqeta with HTTP code 402 and the flow is stopped.

Marqeta events that trigger the posting of financial transaction in Mambu are:

  • refund
  • pindebit.refund
  • authorization.clearing.representment

Where the state field contains the valueCOMPLETION.

At times, refund and pindebit.refund events can reference a credit authorization hold. In which case, the reference authorization will be settled if found in Mambu.

Decrease Authorization Hold

Trigger: JIT Informative request from Marqeta
Mambu action: Decrease Authorization Hold
Prerequisite: Authorization Hold exists

The processing of this event consists of the following steps:

  • Event is processed and routed through the decrease authorization hold sub-process and:
    • If the request to decrease an Authorization Hold is successful, then the hold is decreased.
    • If the request to decrease an Authorization Hold fails, the error is saved in the Errors state diagram and the flow is stopped.

The authorization.advice event in Marqeta triggers the decrease authorization hold action in Mambu.

Reverse Authorization Hold

Trigger: JIT Informative request from Marqeta
Process: Decrease Authorization Hold
Prerequisite: Debit or credit Authorization Hold exists

The processing of this event consists of the following steps:

  • Event is processed and routed through the reversal sub-process
    • If the Reverse Authorization Hold request is successful, then the hold is reversed.
    • If the Reverse Authorization Hold request fails, the error is saved in the Errors state diagram and the flow is stopped.

Through this process, the authorization hold can be:

  • Reversed if the reversal amount is equal to or grater than the authorization hold amount.
  • Decreased if the reversal amount is less than the authorization hold amount.

Marqeta events that trigger the reverse authorization hold action in Mambu:

  • authorization
  • authorization.atm.withdrawal
  • authorization.quasi.cash
  • authorization.cashback
  • refund.authorization
  • original.credit.authorization
  • authorization.reversal
  • authorization.reversal.issuerexpiration
  • original.credit.authorization.reversal
  • refund.authorization.reversal
  • pindebit.authorization.reversal.issuerexpiration

Where the state field contains the value CLEARED.

Create Stand-in Authorization Hold

Trigger: JIT Informative request from Marqeta
Process: Create Stand-in Authorization Hold (debit)
Prerequisites: None

The processing of this event consists of the following steps:

  • Event is processed and routed through the stand-in authorization hold creation sub-process and:
    • If Authorization Stand-in request is successful, then the hold is created without checking the Mambu account available balance.
    • If Authorization Stand-in request fails, the error is saved in the Errors state diagram and the flow is stopped.

The authorization.standin event in Marqeta triggers the stand-in authorization hold creation in Mambu.

Pindebit Financial Transaction Reversals

Trigger: JIT Infomative request from Marqeta
Process: Reverse Card Transaction request
Prerequisites: None

The processing of this event consists of the following steps:

  • Event is processed and routed through the Card Transaction Reversal sub-process and:
    • If the Reverse Card Transaction request is successful, then a CARD_TRANSACTION_REVERSAL is posted on the deposit account.
    • If the Reverse Card Transaction request fails, the error is saved in the Errors state diagram and the flow is stopped.

Through this process, the card transaction reversal can be:

  • Fully reversed if the reversal amount is equal to the initial card transaction amount.
  • Partially reversed if the reversal amount is less than the initial card transaction amount.

Marqeta event that triggers the card transaction reversal in Mambu: pindebit.reversal where the state field contains the value COMPLETION.

Chargeback Transactions

Trigger: JIT Infomative request from Marqeta
Process: Post Credit financial transaction
Prerequisites: None

The processing of this event consists of the following steps:

  1. The batch of transactions that includes this event is verified in MPO for the presence of mandatory parameters.
    This validation is performed for chargeback events only if the gpa_order_unload.jit_funding object is present in the payload. Otherwise, validations are skipped.
    An additional validation is to check if the chargeback object and chargeback.token parameter are also present.

  2. If the batch is valid, the JIT Informative Notifications Gateway responds to Marqeta with HTTP code 200 and the transactions continue to be processed:

    • If the gpa_order_unload.jit_funding object is present in the payload, the transaction is routed through the sub-process responsible with posting the credit financial transaction;
         - If the request is successful the financial transaction is posted in Mambu;
         - If the request fails, a notification is sent to the user responsible as a Mambu task and the error is saved in the Errors state diagram;
    • If the gpa_order_unload.jit_funding object is not present in the payload, the process ignores the event.
  3. If the batch is not valid, the JIT Informative Notifications Gateway responds to Marqeta with HTTP code 402 and the flow is stopped.

Marqeta events that trigger the posting of chargeback financial transaction in Mambu are:

  • authorization.clearing.chargeback
  • authorization.clearing.chargeback.completed
  • pindebit.chargeback
  • pindebit.chargeback.completed

Where the state field contains the value COMPLETION.

3. Decline reasons mapping

As stated above, the JIT Actionable Receiver computes a decline reason for Marqeta based on the errors returned by MPO or Mambu. See below the mapping of the decline reasons.

Marqeta decline_reasonsISO8583 Response codesMambu API error codes
INVALID_AMOUNT13
110
INSUFFICIENT_FUNDS51
116
2706 AVAILABLE_BALANCE_BELOW_ZERO
2422 INSUFFICIENT_ACCOUNT_BALANCE
SUSPECTED_FRAUD34
129
2700 CARD_REFERENCE_TOKEN_FORMAT_INVALID
2703 CARD_REFERENCE_NOT_FOUND
AMOUNT_LIMIT_EXCEEDED61
121
TRANSACTION_COUNT_LIMIT_EXCEEDED65
123
DUPLICATE_TRANSACTION94
913
2704 DUPLICATE_AUTHORIZATION_HOLD
2705 DUPLICATE_CARD_TRANSACTION
TRANSACTION_NOT_PERMITTED57
119
2707 AUTHORIZATION_HOLD_NOT_FOUND (authorization.incremental)
Default decline reason for all other error codes.

4. Notifications logic

The Marqeta connector offers support for sending notifications in cases of business or technical failure in the process.

A “Notifications Module” can be found in the connector’s root structure and is configurable via the Setup Process:

  1. Go to the Setup & config folder.
  2. Click on Connector setup process (Mambu + notifications).

The list of events that generate notifications is configurable. In the current version of the connector, notifications are created in Mambu for all the failing events that involve money movement (clearing and settlement events):

  • authorization.clearing,
  • authorization.clearing.atm.withdrawal,
  • authorization.clearing.cashback,
  • authorization.clearing.quasi.cash,
  • original.credit.authorization.clearing,
  • refund,
  • refund.authorization.clearing,
  • authorization.clearing.representment,
  • pindebit.authorization.clearing,
  • pindebit.refund,
  • authorization.clearing.chargeback
  • authorization.clearing.chargeback.completed
  • pindebit.chargeback
  • pindebit.chargeback.completed

The notification contains detailed information related to the failed transaction, including the custom information stored in the custom fields (if enabled by the connector configuration - enableCustomInformation : “true”).

notification