Transaction Data for JIT Funding Decisions
If you have enabled Gateway Just-in-Time (JIT) Funding for your program, the Marqeta platform sends funding requests to your system for each transaction. Some transaction types, such as authorizations, are actionable, meaning your system must respond programmatically to the request and approve or deny the funding. Other transaction types, such as refunds or reversals, are informative only, meaning your system receives a funding notification but does not need to send a response.
To aid in your system’s decisioning process, the Marqeta platform includes data in the request about the transaction being funded. This data describes aspects of the transaction that indicate to your system whether it is advisable to approve or deny the funding request.
The message sent to your JIT Funding gateway endpoint includes the following key objects for decisioning:
-
jit_funding
-
fraud
-
cardholder_authentication_data
-
card_security_code_verification
-
transaction_metadata
In addition to your system’s programmatic responses to JIT Funding requests, you can configure the following restrictions for your program on the Marqeta platform:
-
Spend controls — Limits when, where, and how much a user can spend with their card. For more information, see Controlling Spending.
-
Address Verification System (AVS) — Verifies that the address provided by the cardholder matches the address on file. For more information, see About Address Verification.
The Marqeta platform processes these restrictions before sending a JIT Funding request to your gateway endpoint.
JIT Funding
Copy section link
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
Copy section link
Your system must programmatically approve or deny JIT Funding requests for the following types of transactions:
-
pgfs.authorization
-
pgfs.authorization.incremental
-
pgfs.auth_plus_capture
-
pgfs.billpayment
-
pgfs.billpayment.capture
-
pgfs.original.credit.authorization
-
pgfs.original.credit.auth_plus_capture
For more information about the jit_funding
object, as well as the differences between actionable and informative transaction types, see Gateway JIT Funding Messages.
Fraud
Copy section link
The fraud
object contains fraud-related data elements from the card network and the Marqeta platform when Real-Time Decisioning is enabled.
issuer_processor object
Copy section link
The issuer_processor
object is part of the fraud
object in the /transactions
endpoint.
Fields | Description |
---|---|
score
integer
|
The risk score generated by RiskControl.
This is either the Mastercard Decision Intelligence or Visa Advance Authorization transaction risk score, which is identical to the Allowable Values: 0 - 99 |
risk_level
string
|
The fraud rating, or level of risk for the transaction. Allowable Values:
|
rule_violations
array of strings
|
The rules violated by the transaction. Allowable Values: Valid array of one or more rule violations |
recommended_action
string
|
The action recommended based on the fraud score. Allowable Values:
|
riskcontrol_tags
array of objects
|
The RiskControl tags triggered by the transaction. Allowable Values: See the riskcontrol_tags object. |
fraud_score_reasons
array of strings
|
Reasons for the fraud score. Allowable Values: Valid array of one or more fraud score reasons |
triggered_rules
array of objects
|
Rules triggered by the event. Allowable Values: See the triggered_rules object. |
riskcontrol_tags object
Copy section link
Note
This object will be deprecated in the future. Instead, use thetriggered_rules
object.
When a rule from your own custom-defined operational models is triggered, it generates a tag for your downstream actions.
This information, including the tag, rule name, and associated multiple values, is contained in the riskcontrol_tags
object as part of the fraud
object in the /transactions
endpoint.
Fields | Description |
---|---|
values
array of strings
|
Values associated with the tag. Allowable Values: Valid array of one or more tag values |
tag
string
|
Tag name defined in the rule definition in the Real-Time Decisioning dashboard. Allowable Values: 255 char max |
rule_name
array of strings
|
Name of the rule as defined in the Real-Time Decisioning dashboard that was triggered. Allowable Values: 255 char max |
triggered_rules object
Copy section link
This object provides a list of rules triggered by a fraud event along with the information on tags and rule characteristics.
Fields | Description |
---|---|
rule_name
string
|
Name of the rule as defined in the Real-Time Decisioning dashboard that was triggered. Allowable Values: 255 char max |
tags
array of objects
|
All the tags defined in the triggered rule. Allowable Values: See the tags object. |
alert
boolean
|
Indicates if the rule triggered an alert. Allowable Values:
|
entity_type
string
|
The entity type where the triggered rule was defined. Allowable Values: Valid entity type |
suppress_alert
boolean
|
Indicates if the triggered rule has Allowable Values:
|
tags object
Copy section link
This object provides a list of tags along with the names and values defined in the triggered rules.
Fields | Description |
---|---|
name
string
|
Name of the tag. Allowable Values: 255 char max |
value
string
|
Value of the tag. Allowable Values: 255 char max |
The following code block shows a sample fraud
object as it would appear in a JIT Funding request:
Cardholder authentication data
Copy section link
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 cardholder’s name or date of birth.
Fields | Description |
---|---|
acquirer_exemption
array of strings
|
Indicates 3D Secure authentication exemptions from the acquirer. This array is returned if it is included in the transaction data from the card network. Allowable Values:
|
authentication_method
string
|
Specifies the 3D Secure authentication method. Allowable Values: null,
|
authentication_status
string
|
Specifies the status of the 3D Secure authentication.
Allowable Values:
|
electronic_commerce_indicator
string
|
Status of the 3D Secure authentication attempt, as provided by a transaction participant.
Allowable Values:
|
three_ds_message_version
string
|
Specifies the 3D Secure message version used for authentication. Allowable Values:
|
verification_result
string
|
Result of the cardholder authentication verification value (CAVV) or accountholder authentication value (AAV) verification performed by the card network.
Allowable Values:
|
verification_value_created_by
string
|
Transaction participant who determined the verification result. This field is only available for Visa transactions. Allowable Values:
|
The following code block shows a sample cardholder_authentication_data
object as it would appear in a JIT Funding request:
Card network field data for cardholder authentication
Copy section link
We include these tables of cardholder authentication field data for the Mastercard and Visa card networks to help clarify the cardholder authentication data results you may see in JIT Funding transactions.
Mastercard field data
Copy section link
This table shows cardholder authentication field data from the Mastercard network.
Security Level Indicator (SLI) | Secure Payment Application Version 2 (SPA2) | Electronic Commerce Indicator | Verification Method | Verification Status | Verification Value Created By |
---|---|---|---|---|---|
210 |
N/A |
|
N/A |
|
N/A |
211 |
kE |
|
N/A |
|
|
211 |
kF |
|
N/A |
|
|
212 |
kA |
|
|
|
|
212 |
kC |
|
|
|
|
212 |
kB |
|
|
|
|
212 |
kR |
|
|
|
|
212 |
kS |
|
|
|
|
212 |
kD |
|
|
|
|
212 |
kQ |
|
|
|
|
214 |
N/A |
|
N/A |
|
N/A |
216 |
kN |
|
N/A |
|
|
217 |
kO |
|
|
|
|
217 |
kP |
|
|
|
|
Visa field data
Copy section link
This table shows cardholder authentication field data from the Visa network.
CAVV | Description | Consideration | Verification Result | Verification Value Created By |
---|---|---|---|---|
Blank |
CAVV not present in authorization message |
Field 126.9 is empty |
|
N/A |
Blank |
CAVV not verified, issuer has not selected CAVV verification option |
Field 126.9 is not empty |
|
N/A |
0 |
CAVV could not be verified |
Field 126.9 is not empty |
|
N/A |
0 |
CAVV data was not provided when expected |
Field 126.9 is empty |
|
N/A |
1 |
CAVV failed verification – cardholder authentication |
CAVV was created by the issuer’s Attempts Server |
|
|
2 |
CAVV passed verification – cardholder authentication |
CAVV was created by the issuer’s Attempts Server |
|
|
3 |
CAVV passed verification – attempted authentication |
CAVV was created by the issuer’s Attempts Server |
|
|
4 |
CAVV failed verification – attempted authentication |
CAVV was created by the issuer’s Attempts Server |
|
|
5 |
Reserved – not in use |
N/A |
N/A |
N/A |
6 |
CAVV not verified, issuer not participating in CAVV verification |
CAVV can be created by the issuer’s ACS, issuer’s Attempts Server, or Visa Attempts Service |
|
|
7 |
CAVV failed verification – attempted authentication |
CAVV was created by Visa’s Attempts Service |
|
|
8 |
CAVV passed verification – attempted authentication |
CAVV was created by Visa’s Attempts Service—Non-participating issuer or cardholder |
|
|
9 |
CAVV failed verification – attempted authentication |
CAVV was created by Visa’s Attempts Service—Issuer ACS was not available |
|
|
A |
CAVV passed verification – attempted authentication |
CAVV was created by Visa’s Attempts Service—Issuer ACS was not available |
|
|
B |
CAVV passed verification – no liability shift |
CAVV was processed but the transaction does not qualify for Visa’s 3-D Secure program |
|
|
C |
CAVV was not verified - attempted authentication |
CAVV was created by the issuer’s Attempts Server |
|
|
D |
CAVV was not verified – cardholder authentication |
CAVV was created by the issuer’s ACS |
|
|
Card security code verification
Copy section link
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
Fields | Description |
---|---|
type
string
|
Type of security code verified. Allowable Values:
|
response.code
string
|
Indicates whether the verification check passed. Allowable Values: 0000, 0001 |
response.memo
string
|
Free-form description of the verification result, as provided by a transaction participant. Allowable Values: 99 char max |
The following code block shows a sample card_security_code_verification
object as it would appear in a JIT Funding request:
Transaction metadata
Copy section link
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.Fields | Description |
---|---|
transaction_category
string
|
Type of product or service being purchased, if provided by the merchant. Allowable Values:
|
authorization_life_cycle
integer
|
Number of days until pre-authorization expires, if provided by the merchant. Allowable Values: |
lodging_auto_rental_start_date
date
|
Pick-up date for an auto rental, or check-in date for lodging, if provided by the merchant. Allowable Values: |
The transaction_metadata.transit
sub-object can contain the following fields related to transportation other than air travel:
Fields | Description |
---|---|
transaction_type
string
|
Type of transit transaction performed, if provided by the merchant. Allowable Values:
|
transportation_mode
string
|
Mode of transportation purchased, if provided by the merchant. Allowable Values:
|
The transaction_metadata.airline
sub-object can contain the following fields related to air travel:
Fields | Description |
---|---|
passenger_name
string
|
Name of passenger for air travel, if provided by the merchant. Allowable Values: Format: forename surname |
depart_date
date
|
Date of departure for air travel, if provided by the merchant. Allowable Values: Format: dd/mm/yyyy |
origination_city
string
|
Three-letter airport code for the city of departure, if provided by the merchant. Allowable Values: Format: SFO |
The following code block shows a sample of the transaction_metadata
object as it would appear in a JIT Funding request: