> ## Documentation Index > Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Release Notes > Release notes are a convenient, central location to learn about the new features, improvements, and documentation changes in each of Marqeta's products. Updated 2-4 times a month.

Marqeta platform holiday code freeze

The end-of-year holiday season represents a peak traffic period for the majority of Marqeta’s card programs and customers. In addition, Marqeta is expecting increased transaction volume during this time, based on initial feedback we received. To ensure an optimal cardholder experience during the 2025 holiday season, Marqeta is instituting two code freezes for the Marqeta platform over the holiday period. Biweekly platform updates will not be deployed from 14 November 2025 until 2 December 2025 and from 16 December 2025 until 5 January 2026. For more information, contact your Marqeta representative.

New features

New transaction response codes for JIT timeouts

Marqeta launched two new [transaction response codes](/developer-guides/about-transactions/#_transaction_response_codes) for JIT timeouts or errors. These response codes do not apply to `200` or `402` responses. Previously, Marqeta used the same response code (`1016`) in response to a JIT gateway timeout or error and transaction decline without a given reason. For example, when a JIT gateway timeout or error occurred for an authorization, Marqeta sent the following response code and memo:
Field Code Memo
`response` `1016` `"Not sufficient funds"`
Similarly, when a Marqeta customer declined a transaction and did not provide a value for the `decline_reason` field, Marqeta sent the following response code and memo:
Field Code Memo
`response` `1016` `"Not sufficient funds"`
Marqeta added two new response codes and memos to the list of [transaction response codes](/developer-guides/about-transactions/#_transaction_response_codes) to address the cases described above. Marqeta now sends the following response code and memo when a JIT gateway timeout or error occurs for an authorization:
Field Code Memo
`response` `1033` `"JIT Response Timeout or Error"`
Marqeta sends the following response code and memo when a Marqeta customer declines a transaction and does not provide a value for the `decline_reason` field:
Field Code Memo
`response` `1034` `"JIT Response No Decline Reason"`

Platform release 2025.10.27.0

New features

##### New Transactions and Webhooks object for fleet customers Marqeta has included a new object (`fleet_data`) to provide prompt data specific to fleet transactions entered at the point of sale. To enable this feature for your card program, contact your Marqeta representative. To learn more about the new `fleet_data` object, see the [Transaction object](/core-api/transactions/#transaction_model).

Changed functionality

##### Fixed: Incorrect fee calculations An issue that prevented the `IS_CROSS_BORDER_TRANSACTION` flag from being passed to Marqeta’s fee calculator, which led to incorrect fee calculations, has been fixed in this release. ##### Fixed: Phone number character limit An issue that limited phone numbers to 15 characters, which prevented some Marqeta customers from entering phone numbers with country codes, has been fixed in this release.

Platform release 2025.10.13.0

New features

##### New transaction response codes for fleet customers Marqeta added two new [transaction response codes](/developer-guides/about-transactions/#_transaction_response_codes) for fleet customers who wish to decline a JIT transaction due to an invalid driver number or invalid vehicle number.
Code JIT Decline Reason Memo
`1943` `INVALID_DRIVER_NUMBER` `"JIT Response Invalid Driver Number"`
`1944` `INVALID_VEHICLE_NUMBER` `"JIT Response Invalid Vehicle Number"`
##### Processing flow enhancement for approved STIP transactions at automated fuel dispensers Marqeta enhanced the processing flow for approved Stand-In Processing (STIP) transactions at automated fuel dispensers (AFDs) to provide Marqeta customers with valid authorization webhooks and prevent unexpected balance impacts. This change ensures AFD transactions follow the standard authorization-clearing flow when approved by card networks during system outages or processing delays. ##### HMAC-SHA256 algorithm now supported for webhooks Marqeta now supports the use of the HMAC-SHA256 algorithm for webhook subscriptions. Marqeta currently allows customers to specify a `secret` in their webhook subscription. When a customer sets a `secret`, Marqeta returns a value under the `X-Marqeta-Signature` header in webhook responses, which is created using the HMAC-SHA1 algorithm. For added security, Marqeta now allows customers to verify signatures using the HMAC-SHA256 algorithm by setting `signature_algorithm` to `HMAC_SHA_256`. This setting can be updated for existing webhooks subscriptions or set when creating a new webhook subscription. For more information, see [Signature Verification](/developer-guides/signature-verification/).

Platform release 2025.9.29.0

New features

##### New digital wallets endpoint to support MDES Mastercard is introducing a requirement for issuers participating in the Mastercard Digital Enablement Service (MDES) in the United States and Canada to support cardholder post-tokenization authentication. This applies to Secure Card on File (SCOF) and Click to Pay transactions. To support this functionality, Marqeta has created a new endpoint: `/digitalwallets/postTokenizationAuthenticationDecision`. This endpoint allows you to submit a post-tokenization authentication decision to Marqeta for SCOF transactions. Marqeta then validates the request, stores it, and forwards the authentication decision to MDES. When Marqeta receives the MDES response from Mastercard, Marqeta synchronously returns the response back to you, ensuring that you receive timely and accurate decisioning. To learn more about this API implementation, contact your Marqeta sales representative. ##### New sub-processor notifications Marqeta has a new process for keeping you informed about updates to our sub-processor list. You can now [sign up here](https://www.marqeta.com/subprocessor-updates) to receive an email notification whenever changes are made to Marqeta and its affiliates' sub-processor list. For more about the sub-processor list, see [Third Party Sub-Processors](https://www.marqeta.com/sub-processors).

Changed functionality

##### Fixed: JIT ANI override responses dropped An issue that caused Marqeta to drop responses for Just-in-Time (JIT) account name inquiry (ANI) overrides has been addressed in this release. As part of the changes made to address this issue, Marqeta has replaced the `account_name_verification_result_code` field in the JIT ANI response with a field called `code`. For more information, see [JIT ANI overwrite response](/developer-guides/using-ani-with-jit-funding/#_jit_ani_overwrite_response). ##### Fixed: Token type mapping in authorization transactions An issue that caused Marqeta to store raw token type values received from the card networks rather than mapping those values to Marqeta’s standardized token type enums has been addressed in this release.

Notable documentation changes

##### Documentation updated to accurately reflect value from JIT payloads, transactions payloads, and webhooks Previously, Marqeta’s documentation included an enum called `pindebit.quasicash`. However, JIT payloads, `GET /transactions` payloads, and webhooks send this enum with the format `pindebit.quasi.cash`. Marqeta has updated its documentation to accurately reflect the value passed in payloads and webhooks. ##### Transaction events now include open banking event types Marqeta has added four new event types related to open banking to [Transaction events](/core-api/event-types/#_transaction_events): * `open.banking.fps.debit.hold` * `open.banking.fps.debit.clear` * `open.banking.fps.debit.hold.reverse` * `open.banking.fps.debit.clear.reverse` To learn more about these new event types, see [Transaction events](/core-api/event-types/#_transaction_events).

Platform release 2025.9.15.0

New features

##### Enhancement to automated fuel dispenser (AFD) transactions Marqeta currently enables you to partially authorize transactions using the `config.transaction_controls.enable_partial_auth_approval` field. When this field is set to `true` and the requested authorization amount exceeds available funds, the transaction is only authorized for the amount of available funds. Otherwise, the transaction is declined. Now, AFD transactions ignore the `config.transaction_controls.enable_partial_auth_approval` field. Marqeta will always partially approve AFD pre-authorizations if the transaction payload field `partial_approval_capable` is enabled. For more information, see [Card Products](/core-api/card-products/). ##### Currency type for transactions Marqeta now provides the `contactless_exemption_transaction_currency` field to define the currency used in a transaction. Now the card program will consistently use the currency type for the amount in the transaction. For more information about this new field, see the [Cards](/core-api/cards/) and [Transactions](/core-api/transactions/).

Platform release 2025.9.1.0

New features

##### New risk score field for card-not-present Visa transactions To support the Visa Deep Authorization risk score, Marqeta added a new optional field called `card_not_present_transaction_risk_score` to the `fraud.network` object in Gateway JIT payloads, webhooks, and `GET /transactions` payloads. The Visa Deep Authorization risk score ranks the risk of fraud for a card-not-present Visa transaction. The score ranges from 01 to 99, with a higher score indicating higher risk. For more information about this new field, see the [Transaction object](/core-api/transactions/#transaction_model). ##### Funding source token values in the transaction body can now be unmasked Marqeta now enables customers to unmask the values of the `gpa_order.funding.source.token` and `funding_source_token` fields. Currently, these two fields contain masked values. They will continue to contain masked values by default, but you can now choose to unmask them. If you would like to unmask either of these fields, contact your Marqeta customer service representative. ##### New logic for verifying digital wallet tokens in e-commerce transactions Marqeta has completed an enhancement to improve tokenization authorization rates on the Visa platform. Previously, certain edge cases led Marqeta to decline valid e-commerce token transactions. Marqeta has implemented logic to bypass these edge cases and consequently improve the approval rates for e-commerce transactions. ##### Mastercard \$0 pre-authorization amounts no longer declined Marqeta will no longer decline \$0 pre-authorization amounts from Mastercard. Previously, when Marqeta received a \$0 pre-authorization request from Mastercard, Marqeta would decline the request with the reason `"Invalid Amount"`. Now, Marqeta will treat \$0 pre-authorization amounts from Mastercard in the same manner as account verification transactions.

Card network articles in development

Marqeta has concluded its review of the articles and announcements received for the October 2025 card network releases from Mastercard, Visa, Discover, and Pulse, and has begun development for all relevant articles. To keep you informed and help you prepare for these upcoming releases, see this list of all the articles under consideration: [October 2025 card network articles in development (PDF)](/developer-guides/october-2025-card-network-articles-in-development.pdf)

New features

New field in the GPA Orders API

For programs utilizing specific sponsor banks, Marqeta’s `POST /gpaorders` endpoint now expects the source of the funds to be stated in the `source_load_type` field. You can use this field to specify how the funding source was loaded from the following options: * `ach` * `otc` * `debitcard` * `promotion` * `earnedwageaccess` For more information, speak to your Marqeta representative.

New field added to two credit objects

Marqeta has added the `waive_returned_payment_fee` field to the Payment Transition Request and Payment Details Response objects. This field enables credit programs to waive fees for refunded payments. If the payment transition status is `REFUNDED` and the `waive_returned_payment_fee` is set to `true`, the return payment fee is waived. For general information about payments, see [Payments](/core-api/credit-account-payments/).

Platform release 2025.8.18.0

New features

##### Matching chargeback tokens to case tokens for disputes Marqeta will now match disputes chargeback tokens and case tokens to simplify the association. Previously, chargeback objects and case objects each had their own distinct token with different formats, making it difficult to connect chargebacks to their related cases. Now, the first chargeback created for a case will have an identical token associated with its case (for example, `prg-1234`). All subsequent chargebacks will have the same base token with an incrementing number appended after a pipe character (for example, `prg-1234|1` and `prg-1234|2`). As part of this change: * Chargeback transitions webhooks will contain values in the `chargeback_token` field that directly match or clearly reference their associated case token. * Transactions webhooks will display token mapping between the chargeback and case in the `chargeback.token` field when the chargeback object is included. * Reports in the Marqeta Dashboard will display token mapping between the chargeback and case in the **Chargeback Token String** field.

Changed functionality

##### Fixed: User metadata for Original Credit Transactions Marqeta has fixed an issue that prevented user metadata from being passed in JIT and webhook payloads for Original Credit Transactions (OCT). ##### Fixed: Secrets, usernames, and passwords now always masked in webhook API responses Marqeta now always masks secrets, usernames, and passwords in webhook API responses. To ensure you can access these values after making them, store them securely before making a request to the `/webhooks` endpoint. For more information, see [Webhooks](/core-api/webhooks/). ##### Fixed: Inconsistencies in multi-clearing sequence numbers Marqeta has fixed an issue that can cause inconsistencies between multi-clearing sequence numbers on the Marqeta platform and the Visa card network in this release.

Platform release 2025.8.4.0

New features

##### Chip validation for Tap to Add Card feature now supported Marqeta now supports chip validation for Visa’s Tap to Add Card feature. Tap to Add Card enables provisioning for contactless-enabled mobile devices. It also enhances security by ensuring that a genuine card is present during provisioning, which increases approval rates compared to methods relying on key entry. ##### Updates to the config.transaction\_controls.allow\_mcc\_group\_authorization\_controls field Marqeta now enables you to exempt cards only from increasing authorization holds by setting the `config.transaction_controls.allow_mcc_group_authorization_controls` field in the `/cardproduct` endpoint to `false`. The MCC group `authorization_controls` object allows you to automatically increase authorization holds and to specify authorization expiration times based on merchant type. The `config.transaction_controls.allow_mcc_group_authorization_controls` field enables you to exempt cards associated with a particular card product from automatically increasing authorization holds. Exempting cards from increasing authorization holds does not impact authorization expiration times. Automated fuel dispenser (AFD) transactions ignore this field, as Marqeta will always increase authorization holds for AFDs if configured to do so. For more information, see [Card Products](/core-api/card-products/).

Changed functionality

##### New validation for the Users API Marqeta added a validation to the `country` field in the `/users` endpoint. This validation ensures that the inputted country code follows the [ISO 3166 country code](https://www.iso.org/iso-3166-country-codes.html) format. If the inputted country code does not adhere to the correct format, the `PUT` or `POST` request fails. For more information on the `country` field, see [Create user](/core-api/users/#post_users).

New features

New BIN attack mitigation feature to enhance issuer fraud controls

As part of the continued evolution of our services and our efforts to minimize cardholder fraud, Marqeta is planning to roll out a BIN attack mitigation feature within our [Real-Time Decisioning platform](/developer-guides/real-time-decisioning-landing-page/) in the near future. Our new BIN attack detection capability will leverage real-time transaction data across our issuer network to detect patterns consistent with enumeration or brute-force behavior. Key capabilities include: * Velocity-based triggers, for example, an unusual surge in authorization attempts by BIN * Automated decline or soft-block logic on merchants experiencing high-risk attempts * Program-configurable controls to tailor protection thresholds * Proactive alerts to fraud teams upon detection of BIN attack attempts By leveraging these capabilities, Marqeta’s Real-Time Decisioning customers will be able to proactively block transactions occurring on merchants who may be experiencing a BIN attack. This enhanced functionality will help protect your cardholders from possible financial losses. To enable this feature, contact your Marqeta representative.

Platform release 2025.7.21.0

New features

##### Expanded SCA support for transactions identified by a TR-TSP ID Marqeta is expanding its strong customer authentication (SCA) compliance logic to include Visa tokenized transactions identified by a Token Requestor–Token Service Provider (TR-TSP) ID. While standard Apple Pay transactions are already treated as SCA compliant, this enhancement ensures that Visa transactions using TR-TSP ID 40010030273 (Apple Inc.) will also be recognized as SCA compliant. ##### New cardholder authentication data in transaction payload to support missing Mastercard fields Marqeta has added new supported values to the Mastercard field data for cardholder authentication table. For the updated list of values, see the [Mastercard field data for cardholder authentication table](/core-api/transaction-data-for-jit-funding-decisions/#_mastercard_field_data).

Platform release 2025.7.7.0

New features

##### Additional transaction response codes Marqeta now supports the following transaction response codes, which can provide insight as to why a transaction was declined and can be used to inform cardholder notifications:
Response Code Description
`1030` JIT response blocked by issuer.
`1031` JIT response blocked by cardholder.
`1032` JIT response indicating that the cardholder had previously blocked the merchant submitting the request, causing the transaction to be automatically declined.
For the full list of available response codes, see the [Transactions response codes table](/developer-guides/about-transactions/#_response_codes_table). ##### Clearing transactions payloads now include new flexible credentials fields Marqeta has updated clearing transactions payloads to include the following fields related to flexible credentials: * `selected_product` * `secondary_credential_identifier` For flexible credential transactions, the clearing transaction payload will now show the `selected_product` and the `secondary_credential_identifier` included in the original purchase. For more information, see the [Transaction object](/core-api/transactions/#transaction_model). ##### Additional 3D Secure data in digital wallet token transaction payloads for Mastercard To better identify potentially fraudulent transactions from Mastercard, digital wallet token transactions now include these additional 3D Secure fields in the `cardholder_authentication_data` object: * `verification_value_created_by` * `three_ds_message_version` * `authentication_method` * `authentication_status` For detailed information about these fields, see [Transactions](/core-api/transactions/).

Changed functionality

##### Fixed: GET /business API response returning identifications field An issue that caused the `GET /businesses` endpoint to return the `beneficial_owner1.identifications` field in the paginated response has been fixed in this release.

Notable documentation changes

New dispute reason codes page for Visa

Learn about Visa’s dispute reason codes and see examples of JSON payloads for Visa disputes in the new [Dispute Reason Codes (Visa)](/core-api/dispute-reason-codes-visa/) page.

New features

New Mastercard chargeback reject code

Marqeta now displays Mastercard’s new chargeback reject code, `5002`, in the Marqeta Dashboard when a merchant provides compelling evidence that the cardholder had authorized the disputed transaction. For more information on Mastercard disputes, see [Managing Mastercard Disputes](/developer-guides/managing-mastercard-disputes/).

New document retrieval button in the Marqeta Dashboard

Marqeta’s disputes system automatically downloads all merchant documents provided in Mastercard’s representments. However, the disputes system does not automatically check for documents that were submitted after the initial representment was filed. To ensure all representments include the required merchant documents, the Marqeta Dashboard now provides a self-serve **Retrieve Network Documents** button if no documents were submitted in the initial representment. When an agent clicks the button, the disputes system will search Mastercard for any newly added documents, then download them to the Marqeta Dashboard. To get started with the Marqeta Dashboard and explore this new feature, see [Dashboard Overview and Quick Start](/developer-guides/dashboard-overview-and-quick-start/). For more information on representments, see the [Representment](/developer-guides/about-disputes/#_representment) section of the [About Disputes](/developer-guides/about-disputes/) guide.

Viewable case notes in the Marqeta Dashboard

Marqeta now allows agents to compose multiple notes that pertain to a specific dispute case. These notes are now viewable in the Marqeta Dashboard. This enhancement is designed to provide you with a comprehensive context of what is happening on a dispute case, allowing you to easily track its progress and submit it accordingly, all without leaving the Marqeta Dashboard. To get started with the Marqeta Dashboard and explore this new feature, see [Dashboard Overview and Quick Start](/developer-guides/dashboard-overview-and-quick-start/).

New intake questions for disputed transactions

In accordance with Visa’s network changes, Marqeta has added new disputes questions to the Disputes API and the Marqeta Dashboard: * API users must update their case creation API contracts in order to support these new questions in the intake process. * Marqeta Dashboard users must collect additional information from cardholders during the intake process. The Marqeta Dashboard has already been updated with the necessary changes.

New field in 3DS SCA challenge result request object

Effective 30 June 2025, Marqeta will add a new optional field called `card_token` to the `ThreeDSChallengeResultRequest` object. In this field, you can input the Marqeta-assigned unique card token that identifies the card being used. For more information, see the [ThreeDSChallengeResultRequest object](/core-api/3ds/#_the_threedschallengeresultrequest_object).

Improved Visa Check Eligibility process

To improve provisioning rates for customers, Marqeta’s Visa Check Eligibility flow logic has been enhanced, ensuring that only valid and correctly configured requests are processed. Provisioning requests will be declined under specific conditions, such as when the card is invalid or the card product is not properly configured for the specified PAN source. These enhancements to the flow logic reduce failed provisioning attempts, and therefore increase provisioning rates for card programs. For more information about this enhancement, contact your Marqeta representative.

Mastercard Digital Enablement Service update

Mastercard is expanding support for Companion Cloud Tokens and Recurring Payment Cloud Tokens through Mastercard Digital Enablement Service (MDES) to enhance merchant payment capabilities and resolve consumer challenges to transactions made via digital wallets. As part of this update, Marqeta will include the Digital Service Provider (DSP) identifier in the JIT payload for customers. If your program recently opted out of MDES, you may opt back in by registering with Mastercard. For more information about this update, contact your Marqeta representative.

Platform release 2025.6.23.0

Changed functionality

##### Advice reason code and details now apply to both Visa and Mastercard The `advice_reason_code` and `advice_reason_details` fields of the Transactions object now apply to both Visa and Mastercard. For more information, see the [Transactions object](/core-api/transactions/#transaction_model).

Platform release 2025.6.9.0

New features

##### TR-TSP ID now passed in tokenization webhooks and JIT payloads Marqeta will now pass the Token Requestor — Token Service Provider ID (TR-TSP ID) in tokenization webhooks and JIT payloads. Visa has enabled device wallets to function as digital wallet facilitators, which allows them to receive a history of transactions from Visa and act as third-party aggregators. These capabilities enable digital wallet consumers to perform in-app lifecycle management actions, such as updating and deleting tokens. These digital wallet facilitators will be identified by the TR-TSP ID. Marqeta customers can now opt back in to this enablement with Visa directly. ##### Add and retrieve BIN issuer country from card products You can now add and retrieve the issuer country, expressed as an [alpha-3 ISO 3166 country code](https://www.iso.org/iso-3166-country-codes.html), from the Card Products API via the `bin_issuer_country` field. For more information, see the [Card Products API](/core-api/card-products/).

New features

Support for Account Level Management

Marqeta enables the issuance of premium credit products by supporting Account Level Management (ALM), a service often required by Visa and Mastercard for affluent card programs. ALM allows card networks to aggregate spend at the account or business level to help optimize interchange rates, and Marqeta provides the necessary authorization and reporting capabilities to support this functionality. To enable ALM for your card program, contact your Marqeta representative. For more information on ALM, see [About Account Level Management](/developer-guides/about-account-level-management/).

Alias Directory Service now available for Visa

Marqeta now offers Visa Alias Directory Service (ADS), also known as Visa+, support for Visa-issued cards. Visa ADS offers capabilities for customers and their cardholders to link Visa Aliases, such as mobile numbers or email addresses, to payment credentials such as cards. For more information about Visa ADS, see the [Digital Wallets Management](/core-api/digital-wallets-management/) API reference.

Improved dispute creation experience for Pulse transactions

Marqeta has implemented changes to the Marqeta Dashboard to enhance the dispute creation experience for Pulse transactions. Previously, to create a dispute for a Pulse transaction within the Marqeta Dashboard, users had to select "Other" and input all the relevant information in the "memo" field. Now, users can select the applicable reason codes and input information into the appropriate fields. This change streamlines the dispute creation process and makes it more efficient. To get started with the Marqeta Dashboard and explore these new features, see [Dashboard Overview and Quick Start](/developer-guides/dashboard-overview-and-quick-start/).

Dispute reason codes can be modified in some states

Dispute risk analysts can now modify the [dispute reason code](/developer-guides/disputes-dashboard/#_dispute_reasons_and_codes) when a case is in one of the following states: * `Open` * `Open with action required` * `Ready` (if the case is in the `Ready` state, move it to `Open`, make the change, then move it back to `Ready`) This enhancement increases efficiency, because agents no longer need to close the current dispute, then open a new one and re-enter the case details. It can also lead to a reduction in duplicate cases. **Note**\ This update applies to the following dispute types: * **Integrated:** Disputes for which the process is automated and managed through the card network’s system. * **Non-integrated:** Disputes for which the process is manually managed by Marqeta. The table below summarizes the supported reason changes from a regulatory perspective. Attempting to make an unsupported reason change will raise an error if made by API, and will be unavailable in the Marqeta Dashboard.
Previous Reg Type Current Reg Type Requirements and Guidelines
Regulation Regulation Change is allowed; add an entry in the case transition to capture the change.

**Example:**
Updating the dispute reason code from `10.3` to `10.4`.

**NOTE:** This change applies to both Reg E → Reg E and Reg Z → Reg Z.
No Regulation No Regulation Change is allowed; add an entry in the case transition to capture the change.

**Example:**
Updating the dispute reason code from `13.1` to `13.7`.
Regulation (with provisional credit) No Regulation Change is allowed, but must be treated as a Regulation case, following the milestones for the Regulation-to-Regulation change. Add an entry in the case transition to capture the reason change.

**Example:**
Updating the dispute reason code from `10.4` to `13.1`.

**NOTE:** The provisional credit must remain unchanged.
No Regulation Regulation Change is allowed, but must be treated as a Regulation case, following the milestones for the Regulation-to-Regulation change. Add an entry in the case transition to capture the reason change. Follow the regulatory clock, based on the cardholder contact date.

**Example:**
Updating the dispute reason code from `13.7` to `10.4`.

**NOTE:** Milestones for Regulation disputes are set during case creation only. Because this change occurs after case creation, the Regulation flow must be modified.
Regulation (no provisional credit) No Regulation Treat changing these disputes like you would a type non-Reg E dispute.

A provisional credit has not been granted in this scenario, and you are therefore not restricted to issuing a provisional credit based on the original reason code. You should issue a provisional credit based on the cardholder’s statement and the facts of the case.

Milestones for Regulation disputes are set during case creation only. A pre-initiation state change and `auth.clearing.chargeback` webhooks are sent during case creation.

To accommodate the change, you will need to "delete" milestones and "withdraw" the case to reverse the `auth.clearing.chargeback` webhook that was originally sent.
Reg E Reg Z Change is allowed, but you must replace the configured milestones. Add an entry in the case transition to capture the reason change.

**Example:**
Buy Now, Pay Later (BNPL) transactions.

**NOTE:** Configuration milestones are set during case creation.

Dispute intake integration available for additional Visa reason codes

Dispute intake integration is now available for the following Visa reason codes that were previously non-integrated: * `11.2` Declined authorization * `12.7` Invalid data * `13.4` Counterfeit merchandise * `13.5` Misrepresentation * `13.7` Cancelled merchandise/services * `13.8` Original credit not accepted You can now use an API call or the Marqeta Dashboard and select the reason code to file a dispute instead of changing the dispute type to `LEGACY_DISPUTE` or `OTHER` in the Marqeta Dashboard.

Automatic provisional credit for Reg Z credit disputes

Marqeta will now automatically grant provisional credit to Reg Z credit disputes within one day of case creation in the event that an agent fails to grant provisional credit. Card programs are required to stop calculating interest immediately. For more information, see [Disputes in the Marqeta Dashboard](/developer-guides/disputes-dashboard/) .

Fraud mitigation for token provisioning

To help mitigate account takeover (ATO) fraud, Marqeta is offering a new enhancement in the identification and verification (IDNV) process during token provisioning. This feature focuses on compliance and security and is available globally. You can now tailor your designated identity verification methods, by disabling specific methods per token provisioning type, to meet your organization’s policies. For example, you can exclude the SMS One-Time Password (OTP) method for manual token provisioning, but keep it active for other provisioning types. Contact your Marqeta representative if you would like to update your IDNV settings for token provisioning. See [Provisioning Digital Wallet Tokens](/developer-guides/provisioning-digital-wallet-tokens/) for more information about token provisioning.

Platform release 2025.5.26.0

New features

##### More granularity when describing platform users The Marqeta platform’s `/users` endpoints now include the following new fields that enable you to characterize users with greater detail: * `birth_place` — Country where the cardholder was born, expressed as an [alpha-2 ISO 3166 country code](https://www.iso.org/iso-3166-country-codes.html). * `title` — Professional title of the cardholder, such as Chief Comptroller. **NOTE:** Do not use this field for honorific titles such as Mr., Mrs., Miss, Ms., Mx., Sir, or Dame. Instead, add these to the `honorific` field. Impacted endpoints include `/users`, `/users/lookup`, `/users/{parent_token}/children`, and `/users/{token}`. For more information about these new fields, see the [Users](/core-api/users/) API reference. ##### User transition webhooks now include metadata information Webhooks sent for user transitions now include metadata information when provided in the user creation request to help minimize duplicate entries. This update will be reflected in the applicable API reference documentation soon. For more information, see the [Webhooks](/core-api/webhooks/) API reference. ##### Clearing data enrichment Marqeta will now populate the following fields in clearing transactions: * `ACQUIRER_COUNTRY_CODE` * `ACQUIRER_INSTITUTION_ID_CODE` * `RETRIEVAL_REF_NUMBER` * `CARD_PRESENCE` The data for these fields will be sourced from the original authorization message. For more information on these fields, see the [Transaction object](/core-api/transactions/#transaction_model).

Changed functionality

##### Businesses API validations for email, phone number, postal code, and ZIP code fields Marqeta has added validations to prevent invalid data from being added to the `phone`, `email`, `postal_code`, and `zip` fields of the Businesses API. As part of these validations, Marqeta has reduced the maximum accepted length for postal codes and ZIP codes from 20 characters to 10 characters. This update will be reflected in the applicable API reference documentation soon. For more information, see the [Businesses](/core-api/businesses/) API reference.

Platform release 2025.5.12.0

New features

##### More granularity when describing business stakeholders The Marqeta platform has added 23 new fields to the businesses API related to describing the business, as well as its control officer, beneficial owners, and directors. Impacted endpoints include `/businesses`, `/businesses/lookup`, `/businesses/{parent_token}/children`, and `/businesses/{token}`. Additionally, several new allowable values have been added to the `incorporation.incorporation_type` field, enabling you to more specifically characterize how a business is incorporated: `FINANCIAL_OR_CREDIT_INSTITUTION`, `FOUNDATION`, `ASSOCIATION`, `CHARITY`, and `TRUST`. For more information about these new fields and values, see the [Businesses](/core-api/businesses/) API reference. ##### Additional data for declined Mastercard transactions in Europe Marqeta will now include additional data in its responses to Mastercard when declining certain contactless, low-value transactions (LVT) in Europe. Impacted transactions will not have undergone a Strong Customer Authentication (SCA) challenge and will have reached the limit of their Article 11 exemption counter or accumulator. This additional data will trigger the use of a Single Tap and PIN Request mechanism, also known as single-tap processing. This mechanism allows the cardholder to enter an online PIN at a terminal PIN pad without needing to tap again or perform an additional "chip and PIN" transaction. For more information on SCA, see [About 3D Secure](/developer-guides/about-3d-secure/).

Changed functionality

##### Hold amount for AFD pre-authorizations Marqeta is changing how Automated Fuel Dispenser (AFD) transactions are padded when MCC 5542 is included in an MCC group with the `UP_TO_LIMIT` field configured. Previously, if an AFD transaction came in with an amount of exactly \$1 USD, Marqeta would pad the authorization amount up to the value of the MCC group’s `UP_TO_LIMIT` field (e.g., \$150). For any other amount, including \$0, 1 unit of local currency, or low amounts that did not reach \$1, no padding was applied. Marqeta will now apply padding up to the value of the `UP_TO_LIMIT` field (e.g., \$150) if the transaction amount is: * \$0 USD * \$1 USD * Exactly 0 units or 1 unit in the local transaction currency For more information on AFDs, see [Automated fuel dispenser (AFD) transactions](/developer-guides/money-movement-overview/#_automated_fuel_dispenser_afd_transactions). ##### Populate pan\_entry\_mode for clearing messages Marqeta will now populate the `pan_entry_mode` field for clearing transactions. This field indicates the method used to capture the card primary account number (PAN) during the transaction, such as `MAG_STRIPE`, `CHIP`, or `CARD_ON_FILE`. For more information on the `pan_entry_mode` field, see the [Transaction object](/core-api/transactions/#transaction_model).

Platform release 2025.4.28.0

New features

##### Revised standards for gaming and gambling payments program in Europe In support of a new gaming and gambling payments program for Mastercard customers in Europe, the Marqeta platform will indicate to Just-In-Time (JIT) card programs in the Gateway JIT request payload whether the transaction is Fast Funds Enabled by setting the `original_credit.fast_funds_enabled` field to `true`. If the value of this field is `true`, you must make the funds available to your cardholder within 30 minutes of the transaction. For details, see [About Just-in-Time Funding](/developer-guides/about-jit-funding/). ##### New lastUpdatedTime field in balances response Calls to the `GET /balances` endpoint will now include the `lastUpdatedTime` field in the response as a way to indicate how recent that balance is. For details, see the [Balances](/core-api/balances/) API reference.

Changed functionality

##### Fixed: Card acceptor state not mapped to two-character code in clearing transactions An issue that caused the mapping between numeric and alphabetic state codes in clearing transactions to fail has been fixed in this release.

Notable documentation changes

New guide about Account Level Management

This new guide covers what you need to know related to Account Level Management (ALM), the service offered by Mastercard and Visa to support premium credit products. In addition to explaining how ALM works for both small business and consumer cards, this guide also includes instructions on how to enable ALM for your card program. For details, see [About Account Level Management](/developer-guides/about-account-level-management/).

New Digital Wallets Management API endpoints

The Marqeta platform’s Digital Wallets Management feature now includes 17 new Alias Directory Service (ADS) endpoints. The ADS endpoints let you create, manage, and retrieve information about Visa Aliases. For details, see the [Digital Wallets Management](/core-api/digital-wallets-management/) API reference.

Web push provisioning GA launch

Marqeta is excited to announce the General Availability (GA) launch of web push provisioning for both Apple Pay and Google Wallet for Visa and Mastercard. This feature allows programs to provide their cardholders with a seamless experience for instant access to their cards and funds. Cardholders no longer need to download a mobile application to add a virtual card. Instead, they can simply use a common web browser to request a new virtual card and add it to their digital wallet. For more information about web push provisioning, see the [Provisioning Digital Wallet Tokens](/developer-guides/provisioning-digital-wallet-tokens/#_web_push_provisioning) guide.

Enhanced token requestor names

To enhance data richness for token requestor names, new token provisioning attempts will no longer include the `UNKNOWN` value but will instead have the specific token requestor name passed from the card network. For more information about token requestor names, see the [Digital Wallets Management](/core-api/digital-wallets-management/) API reference.

Visa Merchant Initiated Transaction framework

Marqeta is now compliant with the Visa Merchant Initiated Transaction (MIT) framework to ensure that merchant-initiated transactions are not declined solely based on token state. Resubmissions, no-shows, delayed charges, and reauthorizations are now permitted for deactivated and suspended tokens. If you are using Just-in-Time (JIT) decisioning, transactions will now also be passed to your JIT endpoint, enhancing transaction processing efficiency. Log in to your [Visa Access](https://www.visaonline.com/login/?realm=vol\&goto=https:%2F%2Fsecure.visaonline.com:443%2Fagent%2Fcustom-login-response%3Fstate%3D5b4GT_HcoIsrWiWy0pM5G7pnCdg%26realm%3Dvol\&original_request_url=https:%2F%2Fsecure.visaonline.com:443%2Fdownload%2Ffile%3Ffilename%3D%2Froot%2Fcontent%2Fdam%2Fgvol%2Fen%2Fproducts%255B%25E2%2580%25A6%255Dtion-service%2Fmerchant-initiated-transactions-framework.pdf) account to learn more about the Visa MIT framework.

Platform release 2025.4.14.0

New features

##### New Businesses API endpoints To support updated Know Your Business (KYB) validation requirements, Marqeta includes new `directors` endpoints in the `businesses` API. The `directors` endpoints let you create, manage, and retrieve identifying information about a director of a business. For more information about the `directors` endpoints, see the following sections on the [Businesses](/core-api/businesses/) API reference page. * [Create business director](/core-api/businesses/#post_businesses_token_directors) * [List business directors](/core-api/businesses/#get_business_directors_business_token) * [Update business director](/core-api/businesses/#put_businesses_token_business_director_token) * [Retrieve business director](/core-api/businesses/#get_business_director_token) * [Retrieve business director tax identifier](/core-api/businesses/#get_business_director_token_ssn)

Platform release 2025.3.31.0

New features

##### Dynamic fee overrides The `/fees` endpoint now supports dynamic fee overrides. Use the `overrideAmount` field to enter a fee that overrides the static `fee.amount` field. For more information about the `overrideAmount` field, see [Transaction object](/core-api/transactions#transaction_model) and [Fee Charges](/core-api/fee-charges/#_request_body).

Changed functionality

##### Fixed: Inconsistent multi-clearing sequence numbers on Visa card network An issue that caused inconsistencies between multi-clearing sequence numbers on the Marqeta platform and the Visa card network has been fixed in this release. For more information about multi-clearing sequence numbers, see [Transactions](/core-api/transactions/). ##### Reverted: Categorization of network-declined advice messages Marqeta has reverted a change from the 2025.3.17.0 release that categorized card network-declined advice messages as `authorization.advice` rather than as `authorization`. For more information about this change, contact your Marqeta representative.

New requirements for PCI Data Security Standards for Mastercard programs

On 1 April 2025, new requirements for PCI Data Security Standards (PCI-DSS) go into effect concerning the storage of primary account numbers (PANs). The hashed card number fields included in some reports customers receive from Marqeta use a deprecated algorithm that will no longer be allowed under PCI-DSS 4.0. Marqeta plans to make changes to its downstream data reports to stop including hashed primary account number fields. If your card program uses Mastercard and you rely on these fields as unique identifiers for the PAN, Marqeta recommends using the card token field in Marqeta Dashboard instead.

Click to Pay now available for Visa

Marqeta now offers Click to Pay support for Visa-issued cards. Click to Pay support for Mastercard is already available. Click to Pay enables consumers to make payments without having to enter their card details each time, enhancing both security and the overall customer experience. For more information about Click to Pay for Visa, see the [Digital Wallets Management](/core-api/digital-wallets-management/#enroll_cardholder) API reference.

Platform release 2025.3.17.0

New features

##### Currency field in network fees object The Marqeta platform now includes the `currency` field in the `fees` object for Mastercard multi-currency transactions that include the `CROSS_BORDER_ISSUER_FEE` and `INTERCHANGE_FEE` fee types. The `currency` field displays the fee in the transaction’s settlement currency. For more information about the `fees` object, see [Transactions](/core-api/transactions/). ##### Point-of-sale geographic data fields The Marqeta platform now includes the `county` and `state` fields in the `pos` object for transactions on the PULSE card network. For more information about the `pos` object, see [Transactions](/core-api/transactions/). ##### Business identification fields to support Brazilian regulations To support [Visa article 10.3.2](/developer-guides/card-network-certifications/), Marqeta includes three new fields in the `card_acceptor` object: * `business_registration_id` * `business_registration_id_type` * `legal_business_name` You will see these fields if Marqeta receives them from the Visa card network. For more information about these new fields, see [Transactions](/core-api/transactions/).

Changed functionality

Reverted: Categorization of network-declined advice messages
In platform release 2025.3.31.0, Marqeta reverts this change that categorizes card network-declined advice messages as `authorization.advice` rather than as `authorization`. ##### Correct acquirer fees for international ATM transactions on the Visa card network For international ATM transactions on the Visa card network, the Marqeta platform previously displayed the acquirer fee in the currency of the transaction, rather than in the cardholder’s billing currency. This previous behavior has been corrected to reflect the fee in the cardholder’s billing currency. Additionally, the `amount` field now correctly indicates the requested amount, minus the acquirer fee. Before this update, the amount was incorrect because it deducted the acquirer fee in a different currency. ##### Fixed: No webhooks for program reserve credit and program reserve debit transactions An issue that caused the Marqeta platform to fail to send webhooks for `programreserve.credit` or `programreserve.debit` transactions has been fixed in this release.

Platform release 2025.3.3.0

New features

##### Visa Digital Commerce Authentication Program indicator The Marqeta platform now includes the Visa Digital Commerce Authentication Program (VDCAP) indicator for U.S. domestic card-not-present transactions, which signals the presence of key data elements, along with the eligible method used to share authentication data. The VDCAP indicator appears in the `digital_commerce_authentication_indicator` field in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. For more information about the `digital_commerce_authentication_indicator` field, see [Transactions](/core-api/transactions/). ##### Mastercard Digital Identity Insight risk score The Marqeta platform now includes the Mastercard Digital Identity Insight risk score and reason code in the `dii_score` and `dii_score_reason_code` fields of the `fraud` object in transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. For more information about the `dii_score` and `dii_score_reason_code` fields, see [Transactions](/core-api/transactions/). ##### New timestamp field in card and user transitions The Marqeta platform now includes the `created_timestamp` field in card and user transition response bodies. The `created_timestamp` field indicates when the transition was created with millisecond precision, to help you determine the most recent transition when multiple transitions occur within the same second. The new timestamp format is `yyyy-MM-ddThh:mm:ss:SSSZ`. For more information about the `created_timestamp` field, see [Card Transitions](/core-api/card-transitions/) and [User Transitions](/core-api/user-transitions/). ##### New memo field in fees API The Marqeta platform now includes the `memo` field in the fees API. Use the `memo` field to record additional information about the fee. For more information about the `memo` field, see [Fees](/core-api/fees/). ##### New transaction purpose values for Mastercard Effective 11 April 2025, Mastercard is adding two new transaction purpose values applicable to MoneySend Payment Transactions. The Marqeta platform now supports these two new values in the `original_credit.transaction_purpose` and `account_funding.transaction_purpose` fields: * `recycling_deposit_return` * `value_added_tax_payment` For more information about the `transaction_purpose` field, see [Transactions](/core-api/transactions/). ##### More granular insight into cryptocurrency transactions The Marqeta platform now supports the following new values in the `card_acceptor.special_condition_indicator` field, giving you a more granular view of cryptocurrency transactions: * `CENTRAL_BANK_DIGITAL_CURRENCY_PURCHASE` * `STABLECOIN_PURCHASE` * `BLOCKCHAIN_NATIVE_TOKEN_PURCHASE` * `NON_FUNGIBLE_TOKEN_PURCHASE` For more information about the `card_acceptor.special_condition_indicator` field, see [Transactions](/core-api/transactions/).

Changed functionality

##### Changes to the currency code for Curaçao and Sint Maarten The Central Bank of Curaçao and Sint Maarten has replaced the Netherlands Antillean Guilder with the Caribbean Guilder as the official domestic currency, changing the alphabetic currency code from ANG (Netherlands Antillean Guilder) to XCG (Caribbean Guilder). The ISO numeric code 532 remains unchanged. The Marqeta platform now includes this updated currency code.

Notable documentation changes

New guide for working within Native Webviews

In this guide, you learn how to use UX Toolkit web components to configure and interact with webviews. Topics covered include sending calls to the JavaScript `postMessage()` method and capturing resize events. For more information, see [Working with UX Toolkit within Native Webviews](/developer-guides/uxt-within-native-webviews/).

Card network articles in development

Marqeta has concluded its review and is now in development for the articles and announcements received for the April 2025 card network releases from Mastercard, Visa, Discover, and Pulse. To keep you informed and help you prepare for these upcoming releases, see this list of all the articles under consideration: [April 2025 card network articles in development (PDF)](/developer-guides/april-2025-card-network-articles-in-development.pdf)

Platform release 2025.2.17.0

The 2025.2.17.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.

Platform release 2025.2.3.0

New features

##### Visa Account Attack Intelligence Score Marqeta now includes the Visa Account Attack Intelligence Score in the `fraud.network.transaction_account_attack_intelligence_score` field. This score ranks the risk of a card-not-present transaction becoming the target of an account enumeration attack. Account enumeration attacks are also known as "brute force" attacks. The Visa Account Attack Intelligence Score uses a scale of 00-99, where 99 indicates the highest risk of fraud, and 00 indicates insufficient data to assess the risk. To enable the Visa Account Attack Intelligence Score for your card program, contact your Marqeta representative. For more information about the `fraud.network.transaction_account_attack_intelligence_score` field, see [Transactions](/core-api/transactions/). ##### Visa Transaction Matching Service for Issuers Marqeta now includes the 10-character installment plan identifier from the Visa Transaction Matching Service for Issuers in the `installment_data` object in transaction payloads. For more information about the `installment_data` object, see [Transactions](/core-api/transactions/). ##### New original transaction token field Marqeta now includes the original transaction token in the payload of each webhook event in a series of related transactions. For more information about the new `original_transaction_token` field, see [Transactions](/core-api/transactions/). ##### New leading indicators for Mastercard Accountholder Authentication Values (AAV) Mastercard now applies the leading indicators `kJ` and `kU` to Accountholder Authentication Value (AAV) values for Smart Authentication Direct Services.

Changed functionality

##### Updated allowable values for to\_account and from\_account fields Marqeta has updated the allowable values for the `from_account` and `to_account` fields. For more information on these updated allowable values, see [Transactions](/core-api/transactions/). ##### Ability to transition account holders from the unverified to the terminated state Marqeta administrators and program managers can now transition user and business account holders directly from the `UNVERIFIED` state to the `TERMINATED` state. Use the `TERMINATED` state to comply with regulatory requirements, such as the requirement that an account be irreversibly closed when it does not pass Know Your Customer (KYC) or Know Your Business (KYB) verification. For more information about account holder transitions, see [User Transitions](/core-api/user-transitions/) and [Business Transitions](/core-api/business-transitions/). ##### Commando mode now declines transactions from savings accounts Marqeta now declines transactions in Commando Mode when those transactions include the value of `SAVINGS` in the `to_account` or `from_account` field. ##### Fixed: Cardholder available balance greater than ledger balance An issue that caused a cardholder’s available balance to be greater than their ledger balance has been fixed in this release of the Marqeta platform.

Marqeta platform holiday code freeze

The end-of-year holiday code freeze is finally over! We are pleased to resume regular deployments to both the sandbox and production environments, per the schedule in place.

Updated one-time passcode messages

As a way to reduce fraud, the cardholder notifications for one-time passcode (OTP) have been updated in all available [notification languages](/developer-guides/configuring-notification-languages/). The updated OTP messages highlight that the issuer will never request OTP information from the cardholder and that the cardholder should never share OTP information with anyone.

Increased business-to-business MoneySend transaction limits

Effective 30 January 2025, Mastercard will increase the limits on business-to-business MoneySend transactions in the United States: * **Single transaction limit:** 125,000 USD (*unchanged*) * **Daily transaction limit:** 250,000 USD * **Weekly transaction limit:** 600,000 USD * **Monthly transaction limit:** 1,250,000 USD

Single sign-on authentication for Marqeta Dashboard users

Marqeta now supports single sign-on (SSO) authentication for Marqeta Dashboard users. This new feature allows your users to log in to [Marqeta Dashboard](https://app.marqeta.com/) using their existing network credentials, which streamlines access and enhances security by leveraging your SAML 2.0 Identity Provider. When you enable SSO, SSO becomes the sole method for your users to log in to Marqeta Dashboard. If you are a system administrator and would prefer that your users authenticate via SSO, contact your Marqeta representative. For more information, see [Managing User Profiles in the Marqeta Dashboard](/developer-guides/user-profiles-dashboard/).

Platform release 2025.1.20.0

New features

##### New public transit benefit transaction type Marqeta now includes the `transit.offer` transaction type to support public transit benefit transactions on the Mastercard network. For more information about transaction types, see [Transactions](/core-api/transactions/). ##### Mastercard 3D Secure authentication identifier Marqeta now includes the Mastercard 3D Secure authentication identifier in the `cardholder_authentication_data.three_ds_reference_id` field in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. This identifier links the 3D Secure authentication from the Mastercard network with the authorization transaction on the Marqeta platform. For more information about the `cardholder_authentication_data.three_ds_reference_id` field, see [Transactions](/core-api/transactions/). ##### New and updated account fields in all transaction payloads Marqeta introduces the following new fields: * The `to_account` field now appears in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests for all transaction types. This field indicates the type of account receiving funds, such as a cash deposit at an automated teller machine (ATM). * The existing field `from_account` now appears in all transaction payloads. In previous releases of the Marqeta platform, this field was only included in ATM and balance inquiry transactions. For more information about the `from_account` and `to_account` fields, see [Transactions](/core-api/transactions/).

Changed functionality

##### End of Life for platform endpoints The `/offerorders` endpoint is no longer supported with this release of the Marqeta platform. Support for the `/campaigns` and `/offers` endpoints will end with the 2025.2.17.0 release of the Marqeta platform.

Platform release 2025.1.6.0

New features

##### Estimated authorizations Visa supports estimated authorizations for all merchants. An estimated authorization request allows the merchant to obtain an approval for funds before the cardholder has finalized exactly what goods or services will be purchased. Marqeta now indicates estimated authorizations in the `estimated_authorization` field in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. For more information about the `estimated_authorization` field, see [Transactions](/core-api/transactions/). ##### Network transaction lifecycle identifier Marqeta now includes the new field `network_transaction_lifecycle_id` in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. This identifier connects the original transactions to all subsequent transaction activities throughout the transaction lifecycle. For more information about the `network_transaction_lifecycle_id` field, see [Transactions](/core-api/transactions/). ##### Issuer transaction risk analysis exemption Marqeta now offers a new transaction control for your card products: `ENABLE_ISSUER_TRA_EXEMPTION`. When this control is enabled, Marqeta does not increment the low-value payment (LVP) counter for frictionless 3D Secure transactions. This field is enabled by Marqeta in your card product configuration. Contact your Marqeta representative to configure this field for your program. For detailed card product documentation, see [Card Products](/core-api/card-products/).

Changed functionality

##### Federal regulations on blocking card-not-present transactions To comply with United States regulations, Marqeta now blocks card-not-present (CNP) transactions for merchant category code (MCC) `7995: BETTING, WAGERING, LOTTERY, GAMBLING TICKETS OR CHIPS`. The Marqeta platform still allows card-present (CP) transactions for this MCC. For more information about this enhancement, contact your Marqeta representative. ##### Additional 3D Secure data in digital wallet token transaction payloads 3D Secure token transactions now include additional 3DS data. To help identify potentially fraudulent transactions, digital wallet token transactions now include these existing 3D Secure fields in the `cardholder_authentication_data` object: * `verification_value_created_by` * `three_ds_message_version` * `authentication_method` * `authentication_status` For detailed information about these fields, see [Transactions](/core-api/transactions/). ##### Fixed: Incorrect postal code parsing An issue that caused incorrect parsing of non-US postal codes has been fixed in this release. ##### Fixed: State codes not converted from numeric to alphabetic format An issue that caused the conversion between numeric and alphabetic state codes to fail has been fixed in this release.