Skip to main content
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.
All dates on this page are estimated launch dates and might change.

​
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.
  • Impact category: The kind of change, as described in the following table.
  • 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.

​
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: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.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:
  • 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, 2026Starting October 23, 2026, Mastercard begins sending two new Token Assurance Method (TAM) values, 12 and 25 (Mastercard AN 13368.2). TAM is the method used to verify the cardholder before a digital wallet token was provisioned. Marqeta returns it in the token_assurance_method field on the transaction’s digital_wallet_token.token_service_provider object, in post-transaction webhook payloads and in Gateway JIT Funding requests, including program gateway funding sources.
  • Live now: The token_assurance_method field, released in platform release 2026.9.28.0, and the values 10 (account verification) and 11 (one-factor cardholder authentication).
  • Coming October 23, 2026: The values 12 (two-factor cardholder authentication) and 25 (tenured token).
The token_assurance_level field is unchanged.
  • 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.
​
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.
​
PlannedDeprecationAction required

Custom number-of-days and number-of-hours velocity control windows deprecated

Announced: October 5, 2026Action required by: December 1, 2026DeprecationMarqeta is standardizing the time windows that velocity controls support. Effective December 1, 2026, Marqeta is deprecating the custom number-of-days and number-of-hours window configurations, so that velocity controls are calculated consistently across all programs.From December 1, 2026, the velocity_window field on the Velocity Controls API supports only the following values:If you have velocity controls that use a custom number-of-days or number-of-hours window, update them to a supported window before December 1, 2026. After that date:
  • You can no longer view or update controls that use these windows.
  • The API rejects any new control that has a number-of-days or number-of-hours parameter.
  • Marqeta no longer counts controls that still use an unsupported window toward transaction decisioning. Velocity limits might then be applied inconsistently, which can affect cardholder transactions.
  • Production enforcement: December 1, 2026
  • Action required: Review your active velocity controls. For each control that uses a custom number-of-days or number-of-hours window, either update it to a supported window or deactivate it by setting active to false.
To update a control, send a PUT request to the /velocitycontrols/{token} endpoint. For questions, contact your Marqeta account team.
​
PlannedAdditiveNo action required

Managed KYC and KYB onboarding outside the US

Announced: October 1, 2026Marqeta will add a managed, non-delegated Know Your Customer (KYC) and Know Your Business (KYB) onboarding product for programs in the EU, UK, Canada, and Australia. You will integrate with a single verification API. Marqeta plans to release KYC verification in December 2026 and KYB verification in March 2027.
  • Action required: None. The product is optional.
For more information, see About KYC Verification.
​
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 moving to the UX Toolkit

Announced: September 4, 2026Action required by: February 2027DeprecationWidgets are being sunset and moving to 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.Marqeta is migrating customers from Widgets to the UX Toolkit in waves, so each customer moves at a different time. Marqeta plans to move all customers to the UX Toolkit by February 2027.
  • Transition complete: February 2027
  • Action required: To find out when your migration is scheduled, contact your Account Manager.
For more information, see FAQ: Widgets to UX Toolkit Migration and UX Toolkit Getting Started.

​
Archive

The following announcements are now live. Each note links to the release notes entry for the change.