The jit_funding object contains information about the funding event, including the associated user token and transaction amount. The method field indicates the type of transaction and whether the message is an actionable funding request sent to your gateway endpoint or an informative message sent to your webhook endpoint.
Actionable transaction types
Your system must programmatically approve or deny JIT Funding requests for the following types of transactions:
For more information about the jit_funding object, as well as the differences between actionable and informative transaction types, see Gateway JIT Funding Messages.
The fraud object contains one or more fraud determinations for the transaction and the card holder's account. Fraud determinations originate from the card network and/or the Marqeta platform.
A fraud determination from the card network can include the following fields:
|transaction_risk_score||int||Determination of the transaction's risk, as calculated by the card network; a higher score indicates higher risk.||1-100|
|account_risk_score||int||Determination of the account holder's risk, as calculated by the card network; a higher score indicates higher risk.||1-100|
A fraud determination from the Marqeta platform can include the following fields:
|score||int||Determination of the transaction's risk, as calculated by the Marqeta platform; a higher score indicates higher risk.||1-100|
|risk_level||string||Summary of the transaction's risk, based on score ranges specific to your program.||LOW | MEDIUM | HIGH|
|recommended_action||string||The Marqeta platform's suggested response for the JIT Funding request.||APPROVE | DECLINE | NOT_PERFORMED|
|rule_violations||array||Rules violated by the transaction that impact the Marqeta platform's risk score.|
The following code block shows a sample fraud object as it would appear in a JIT Funding request:
Cardholder authentication data
The cardholder_authentication_data object contains information about additional authentication performed for e-commerce transactions. For example, a transaction participant (such as the card network) can request additional verification during the transaction process, such as the card holder's name or date of birth.
|electronic_commerce_indicator||string||Status of verification attempt.||authentication_successful | authentication_attempted | no_authentication|
|verification_result||string||Result of the verification attempt.||verified | failed | not_verified | not_present | not_provided|
|verification_value_created_by||string||Transaction participant who determined the verification result.||issuer_acs | issuer_attempts_server | network | network_attempts_server|
The following code block shows a sample cardholder_authentication_data object as it would appear in a JIT Funding request:
Card security code verification
The card_security_code_verification object contains information about a verification check performed on the card's security code.
The type field indicates the type of security code and can have the following possible values:
- CVV1 – The security code stored in the magnetic stripe on the card.
- CVV2 – The security code printed on the card.
- ICVV – The security code stored on the chip of the card.
- DCVV – A dynamic security code used in some contactless payments when a card or device is tapped on the card reader.
The response.code field indicates whether the verification check passed and can have one of the following values:
- 0000 – Passed
- 0001 – Did not pass
|type||string||Type of security code verified.||CVV1 | CVV2 | ICVV | DCVV|
|response.code||string||Indicates whether the verification check passed.||0000 | 0001|
|response.memo||string||Free-form description of the verification result.|
The following code block shows a sample card_security_code_verification object as it would appear in a JIT Funding request:
"memo": "Card security code match"
The transaction_metadata object contains additional merchant-provided details about a transaction. It also includes sub-objects for more detailed information about transit and air travel purchases.
Note: Transaction metadata is only included when provided by the merchant.
|transaction_category||string||Type of product or service being purchased.||RETAIL_SALE | BILL_PAY | HOTEL | RESTAURANT | AUTO_RENTAL | AIRLINE | PAYMENT | HOSPITALIZATION_COLLEGE | PHONE_MAIL_ECOMMERCE | ATM | HEALTH_CARE | TRANSIT|
|authorization_life_cycle||int||Number of days until pre-authorization expires.|
|lodging_auto_rental_start_date||date||Pick-up date for an auto rental, or check-in date for lodging.|
The transaction_metadata.transit sub-object can contain the following fields related to transportation other than air travel:
|transaction_type||string||Type of transit transaction performed.||PRE_FUNDED | REAL_TIME_AUTHORIZED | POST_AUTHORIZED_AGGREGATED | AUTHORIZED_AGGREGATED_SPLIT_CLEARING | OTHER | DEBIT_RECOVERY|
|transportation_mode||string||Mode of transportation purchased.||BUS | TRAIN | WATER_BORNE_VEHICLE | TOLL | PARKING | TAXI | PARA_TRANSIT | SELF_DRIVE_VEHICLE | COACH | LOCOMOTIVE | POWERED_MOTOR_VEHICLE | TRAILER | INTER_CITY | CABLE_CAR|
The transaction_metadata.airline sub-object can contain the following fields related to air travel:
|passenger_name||string||Name of passenger for air travel.|
|depart_date||date||Date of departure for air travel.|
|origination_city||string||Three-letter airport code for the city of departure.|
The following code block shows a sample of the transaction_metadata object as it would appear in a JIT Funding request:
"passenger_name": "Madison Aguilar",