Upcoming Release Announcements

This page provides advance notice of changes to the Marqeta platform that aren’t yet in production. When a change goes live, Marqeta moves its announcement to the matching product release notes and leaves a link in the Archive section of this page.

How to read this page

Announcements use two kinds of markers: filter tags and labels.

Filter tags

Each announcement has three filter tags, shown under its date. To show only the announcements with specific filter tags, select them in the Filters panel on the right.

Lifecycle status: Where the change is in the release process, as described in the following table.

Filter tag	Description
`Planned`	Marqeta has announced the change, and it isn’t available yet.
`Beta`	The change is available to a limited set of programs.
`Effective soon`	The change takes effect within the next 30 days.
`Live`	The change is in production. Marqeta moves its description to the release notes for its product area and links to it from the Archive section of this page.

Impact category: The kind of change, as described in the following table.

Filter tag	Description
`Breaking change`	Requires code updates; changes existing API behavior or contracts.
`Deprecation`	Scheduled for removal; plan your migration.
`Network mandate`	Required by a card network, regulator, or partner deadline.
`Additive`	New fields or capabilities; non-breaking.
`Security`	Security patches and authentication enforcement updates.

Action requirement: Action required means you must update your integration or processes. No action required means the change doesn’t require any updates from you.

Labels

Labels appear under an announcement’s title to highlight what needs your attention.

Label	Description
Action required by: date (green)	You must update your integration or processes by the date shown. When there’s no deadline yet, the label shows Action required.
Breaking change (red)	The change requires code updates and changes existing API behavior or contracts.

Upcoming changes

Effective soonNetwork mandateAction required

Visa October 2026 card network changes

Announced: September 29, 2026Action required by: October 23, 2026The October 2026 VisaNet Business Enhancements take effect on October 23, 2026. To support them, Marqeta will make the following changes:

Visa article	Change	Action
1.1 - Digital Commerce Authentication Program (DCAP) expansion	Marqeta will surface the `digital_commerce_authentication_indicator` field for card-not-present transactions in Canada, Central Europe, Middle East and Africa (CEMEA), Latin America and Caribbean (LAC), and the remaining Asia Pacific (AP) countries. Qualifying transactions will also carry additional `account_owner` data.	None
2.1 - New merchant category codes (MCCs)	Marqeta will surface the new MCC values `3306`, `3884`, `3885`, and `3886` in the `card_acceptor.mcc` field in JIT Funding payloads, webhooks, and the Transactions API.	None
2.5 - Visa Resolve Online (VROL) dispute changes	Marqeta will add new fields to `POST /cases` for reason codes `13.2` and `13.3`. See New fields for Visa dispute reason codes 13.2 and 13.3.	Required if you submit these disputes
2.8 - DCAP for account funding transactions (AFTs)	Marqeta will set `vdcap_qualified` to `true` on AFTs that carry the DCAP indicator, for issuers in the AP, CEMEA, and Europe regions.	None
2.19 - Account owner date of birth format	Visa will send the account owner date of birth in `yyyymmdd` format instead of `ccyymmdd`. Marqeta will pass the value through exactly as Visa sends it.	Required if you parse this value
3.2 - AFTs with a debt repayment indicator	Marqeta will surface the `special_condition_indicator` value `DEBT_PAYMENT` for debt repayment AFTs in the AP, CEMEA, Europe, and LAC regions.	None

Production enforcement: October 23, 2026
Action required: Update any parsing of the account owner date of birth to accept the yyyymmdd format. If you submit Visa disputes for reason codes 13.2 or 13.3, also see New fields for Visa dispute reason codes 13.2 and 13.3.

Other Visa changes in this release don’t affect how you interact with the Marqeta platform. For the full list, see Card Network Certifications. For field details, see Transactions.

Effective soonNetwork mandateAction required

New fields for Visa dispute reason codes 13.2 and 13.3

Announced: August 24, 2026Action required by: October 23, 2026To support the mandatory Visa Resolve Online (VROL) changes in the October 2026 VisaNet Business Enhancements (Visa article 2.5), Marqeta will add new fields to POST /cases for cancelled recurring transaction and lodging-related disputes.Reason code 13.2 (“Cancelled recurring transaction”): For a dispute with dispute_reason set to CANCELLED_RECURRING_TRANSACTION, where the transaction card_acceptor.country_code matches one of the following countries, Marqeta will add a new merchant_facilities_withdrawn field to certify that the merchant facilities were withdrawn. When you set merchant_facilities_withdrawn to true, you must provide the date the lodging facility withdrew or cancelled its services, or made them inaccessible to the cardholder, in the new facilities_withdrawn_date field.

Country	card_acceptor.country_code (numeric)	card_acceptor.country_code (alpha-3)
Austria	`040`	`AUT`
Belgium	`056`	`BEL`
Bulgaria	`100`	`BGR`
Croatia	`191`	`HRV`
Cyprus	`196`	`CYP`
Czechia	`203`	`CZE`
Denmark	`208`	`DNK`
Estonia	`233`	`EST`
Finland	`246`	`FIN`
France	`250`	`FRA`
Germany	`276`	`DEU`
Greece	`300`	`GRC`
Hungary	`348`	`HUN`
Ireland	`372`	`IRL`
Italy	`380`	`ITA`
Latvia	`428`	`LVA`
Lithuania	`440`	`LTU`
Luxembourg	`442`	`LUX`
Malta	`470`	`MLT`
Netherlands	`528`	`NLD`
Poland	`616`	`POL`
Portugal	`620`	`PRT`
Romania	`642`	`ROU`
Slovakia	`703`	`SVK`
Slovenia	`705`	`SVN`
Spain	`724`	`ESP`
Sweden	`752`	`SWE`
United Kingdom	`826`	`GBR`

Reason code 13.3 (“Not as described or defective merchandise”), all regions: For a dispute with dispute_reason set to NOT_AS_DESCRIBED_OR_DEFECTIVE_MERCHANDISE that involves lodging services (merchandise_or_services set to SERVICES and an MCC of 7011 or in the range 3501–3856), Marqeta will add a new date_cardholder_checked_out_from_hotel field to capture the date the cardholder checked out of the lodging facility.

Production enforcement: October 23, 2026
Action required: Update your dispute submission logic to populate the new fields for qualifying reason code 13.2 and 13.3 disputes.

For more information, see Disputes (Visa) and Card Network Certifications.

Effective soonNetwork mandateAction required

Mastercard October 2026 card network changes

Announced: September 29, 2026Action required by: October 25, 2026Mastercard Release 26.Q4 takes effect on October 23, 2026. To support it, Marqeta will make the following changes:

Mastercard bulletin	Change
GLB 13264.1 - Issuer-initiated person-to-person transactions	Marqeta will classify the new transaction type values `C09` and `F09` as person-to-person, in your spend control settings and in the transaction data Marqeta provides.
US 13301.1 - Single Message System Transmission File delivery	Starting October 25, 2026, Marqeta will move the first Sunday delivery of the T461 file from 10:00 CT (16:00 UTC) to 05:00 CT (11:00 UTC). Delivery on other days doesn’t change.
GLB 13368.2 - Token Assurance Method (TAM) values	Marqeta will decode and persist the new TAM values `12` (two-factor authentication) and `25` (Tenured Token), alongside the existing `10` and `11` values.
GLB 13877.1 - MDES Token Spend Controls	When Mastercard declines a tokenized transaction for violating a Token Spend Control, Marqeta will populate the `advice_reason_code` and `advice_reason_details` fields in the Transactions API and webhooks with the specific reason, such as `0069` (MCC limit) or `0072` (geographic restriction).

Production enforcement: October 23, 2026 (T461 delivery schedule: October 25, 2026)
Action required: Required for programs using Sunday delivery of the T461 file.

If you have processes scheduled around the Sunday delivery of the T461 file, you must adjust them before October 25, 2026. Starting that day, the first Sunday delivery arrives at 05:00 CT (11:00 UTC) instead of 10:00 CT (16:00 UTC). Delivery on Monday through Saturday doesn’t change.

Other Mastercard changes in this release don’t affect how you interact with the Marqeta platform. For the full list, see Card Network Certifications.

Effective soonNetwork mandateAction required

New Mastercard token assurance method values 12 and 25

Announced: September 28, 2026Action required by: October 23, 2026Marqeta now returns the Mastercard Token Assurance Method (TAM), the method used to verify the cardholder before a digital wallet token was provisioned, in the new token_assurance_method field on the transaction’s digital_wallet_token.token_service_provider object. The field is returned alongside the existing token_assurance_level field, which is unchanged.The field is available in post-transaction webhook payloads and in Gateway JIT Funding requests, including program gateway funding sources. It returns the following values:

10 – Account verification
11 – One-factor cardholder authentication
12 – Two-factor cardholder authentication
25 – Tenured token

Values 10 and 11 are returned as of release 2026.9.28.0. Effective October 23, 2026, Mastercard begins sending values 12 and 25 (Mastercard AN 13368.2).

Production enforcement: October 23, 2026
Action required: Only if you use token assurance data in your risk or authorization logic. Add handling for the two new values before the effective date.

For more information, see Transactions.

Effective soonBreaking changeAction required

Usage limit values above 100 will be capped

Announced: July 20, 2026Action required by: October 2026Breaking changeMarqeta will enforce the documented allowable range for the usage_limit field on velocity controls. The usage_limit field defines the maximum number of times a card can be used within the time period defined by the velocity_window field.When this change takes effect, Marqeta rejects usage_limit values greater than 100 on new or updated velocity controls. Marqeta also updates existing velocity controls with a usage_limit greater than 100 to -1 (unlimited), so there is no adverse change in enforcement.

Production enforcement: October 2026
Action required: Only if your program creates or updates velocity controls with a usage_limit greater than 100. Update those requests to use a value of 100 or lower, or -1 for unlimited. If you want an existing control that Marqeta updates to -1 to keep a cap, set its usage_limit to 100 or lower.

For more information, see Velocity Controls.

PlannedNetwork mandateNo action required

Mastercard authorizations continue on cardholder-deactivated digital wallet tokens

Announced: September 28, 2026Mastercard is requiring issuer processors to keep authorizing certain transactions against a digital wallet token that the cardholder has deactivated in the wallet (Mastercard AN 13503.1). Marqeta currently terminates the digital wallet token as soon as the cardholder deactivates it, and declines every later authorization on that token.From the effective date, when a cardholder deactivates a Mastercard digital wallet token, Marqeta evaluates the following authorizations on that token normally. Marqeta evaluates these authorizations against your authorization controls, available funds, and Just-in-Time (JIT) Funding decision, if configured.

Merchant-initiated transactions, such as recurring payments, installments, standing orders, unscheduled credential-on-file transactions, and industry-practice transactions, for the remainder of the 540-day token lifetime.
Cardholder-initiated transactions, within 48 hours of the deactivation. After 48 hours, Marqeta declines them, as it does today.

Marqeta continues to decline authorizations on digital wallet tokens terminated for any other reason, and this change doesn’t apply to remote commerce programs.

Production enforcement: November 10, 2026
Action required: None. Marqeta applies this update automatically to keep your program compliant with the Mastercard standard. However, if your program treats a TERMINATED digital wallet token as permanently unusable, review any risk, reconciliation, or JIT Funding logic that depends on those authorizations being declined.

For more information, see Managing the Digital Wallet Token Lifecycle.

PlannedNetwork mandateAction required

Mastercard technical fallback declined outside the US region

Announced: September 28, 2026Action requiredMastercard is phasing out technical fallback outside the United States region (Mastercard AN 13700), with an earliest effective date of January 1, 2027. Technical fallback occurs when a chip-capable terminal can’t read the chip on a card and the transaction falls back to a less secure entry method, such as a magnetic stripe swipe or a manually keyed card number.From the effective date, Marqeta declines a Mastercard technical fallback authorization unless the card issuer or the card acceptor (the merchant or terminal) is in the United States region, which includes Puerto Rico, the US Virgin Islands, Guam, American Samoa, and the Northern Mariana Islands.

Production enforcement: January 1, 2027 (earliest)
Action required: Only if your program issues Mastercard cards outside the United States region. Review any logic that depends on technical fallback authorizations succeeding.

For the full list of allowable values for the pos.pan_entry_mode field, see the Transaction object.

PlannedDeprecationAction required

Widgets retirement and migration to the UX Toolkit

Announced: September 4, 2026Action requiredMarqeta is retiring Widgets and replacing them with the UX Toolkit. The UX Toolkit will offer full feature parity with Widgets, including card activation, PIN set and reveal, and card display. It also adds capabilities that Widgets don’t offer, such as freezing and unfreezing cards, card replacement, transaction history, account balances, dispute filing, account funding, statements, and user onboarding.

Action required: To start migrating from Widgets to the UX Toolkit, contact your Account Manager.

For more information, see FAQ: Widgets to UX Toolkit Migration and UX Toolkit Getting Started.

PlannedAdditiveNo action required

New field to connect recurring Visa transactions

Announced: November 20, 2025Marqeta will add a field called original_network_transaction_lifecycle_id to the Transaction object for Visa transactions. This field connects an original transaction to all subsequent activities throughout the transaction lifecycle. For example, recurring transactions for a subscription service all connect to the same original_network_transaction_lifecycle_id.

Action required: None. The new field is optional.

PlannedAdditiveNo action required

New object for Strong Customer Authentication (SCA) framework

Announced: October 3, 2025Marqeta will add the strong_customer_authentication object to classify both issuer and acquirer exemptions for contactless transactions. This object will categorize the different types of exemptions within the SCA framework. To enable the strong_customer_authentication object for your card product, set the ENABLE_STRONG_CUSTOMER_AUTHENTICATION field to true.This object only applies to contactless transactions. For card-not-present e-commerce transactions, use the existing issuer and acquirer exemption fields in the cardholder_authentication_data object.

Action required: None. The object is opt-in at the card product level.

​How to read this page

​Filter tags

​Labels

​Upcoming changes

Visa October 2026 card network changes

New fields for Visa dispute reason codes 13.2 and 13.3

Mastercard October 2026 card network changes

​New Mastercard token assurance method values 12 and 25

Usage limit values above 100 will be capped

​Mastercard authorizations continue on cardholder-deactivated digital wallet tokens

​Mastercard technical fallback declined outside the US region

Widgets retirement and migration to the UX Toolkit

New field to connect recurring Visa transactions

New object for Strong Customer Authentication (SCA) framework

​Archive

How to read this page

Filter tags

Labels

Upcoming changes

New Mastercard token assurance method values 12 and 25

Mastercard authorizations continue on cardholder-deactivated digital wallet tokens

Mastercard technical fallback declined outside the US region

Archive