Skip to main content

​
October 2026 release notes

Subscribe to these release notes with RSS: https://www.marqeta.com/docs/developer-guides/release-notes/rss.xml
Marqeta rolls out Card Issuing and Processing platform releases in phases. If you don’t see a feature in your environment yet, you will after Marqeta updates your environment to the new version. Platform release numbers, such as V.2026.8.31.0, identify the release, not the date it becomes available.
​

​
Exception File Management API

Marqeta now supports the Exception File Management API, which lets you add, update, retrieve, and remove terminated cards on Visa’s exception file. Adding a card to the exception file prevents stand-in processing (STIP) from approving transactions on the card while the Marqeta platform is unavailable, and, depending on the action code, also blocks force-posted clearing transactions. This feature requires additional activation steps. To activate it for your program, contact your Marqeta representative.For more information, see Exception File Management.

​
New enhanced fleet data fields for Mastercard fleet transactions

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta now supports enhanced fleet data for Mastercard fleet transactions, returning fuel and non-fuel pricing detail and itemized purchase information in the fleet_data object. Previously, fleet_data returned only the purchase type and point-of-sale prompt data, without the pricing or item-level detail card networks can require for fleet purchases.The fleet_data object now includes the following fields:
  • gross_fuel_price and gross_non_fuel_price — the fuel and non-fuel amounts of the purchase.
  • purchase_override — indicates whether the merchant supports purchase override. For Mastercard transactions, if purchase_override is false or the merchant doesn’t support override, you must approve or decline the transaction in its entirety. If purchase_override is true, you can instead return a 16-digit hex value that follows Conexxus/IFSF standards (for example, C1E0000000000000).
  • items — up to 15 line items for the purchase (up to three fuel items and up to 12 non-fuel items), each with fuel_item, product_code, product_description, unit_price, unit_of_measure, product_quantity, and gross_price fields.
No action is required — these fields are additive.For more information, see Transactions.

​
New support for Visa’s Purchase Identifier field and Visa Recurrent Reference ID

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta now supports Visa’s Purchase Identifier field (Field 62.7) on inbound Visa authorization messages, including the new Visa Recurrent Reference ID, introduced as part of Visa Recurrent — Visa’s program for recurring payments.When an acquirer participating in Visa Recurrent sends Field 62.7 with a Purchase Identifier Format of 7, the accompanying identifier is the Visa Recurrent Reference ID — a network-issued identifier that links every transaction tied to a single recurring-payment agreement. This field is available on the Transaction object and via webhook.Card programs can use this identifier to build subscription-visibility features, such as displaying a cardholder’s active recurring charges, offering cancel/pause controls for a subscription, or alerting cardholders to upcoming renewals and price changes.This adds the following fields:
  • purchase_identifier — the raw Purchase Identifier value from Field 62.7, positions 2–26.
  • visa_recurrent_reference_id — populated with the same value as purchase_identifier when Field 62.7’s Purchase Identifier Format (position 1) is 7; null otherwise.
To activate this feature for your program, contact your Marqeta representative.For more information, see Transactions.

​
New av_accepted_countries_token field on card products

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta now supports a separate accepted countries list for $0 account verification (AV) transactions on a card product, independent of the list used for regular purchase authorizations.Previously, all transaction types — purchases, AV requests, and refund authorizations — evaluated the same accepted_countries_token on the card product. A program restricting purchases to a specific set of countries also blocked AV requests from merchants whose acquirer is registered in a different country, preventing cardholders from adding their card to a wallet or a merchant’s card-on-file system, even when no funds were involved.The new optional config.transaction_controls.av_accepted_countries_token field on the card product points AV transactions to a different accepted countries list. When set, Marqeta uses this list instead of accepted_countries_token for all $0 AV requests; all other transaction types continue to use accepted_countries_token. Set it to DISABLED to revert AV transactions back to using accepted_countries_token — card product config values can’t be deleted, so this is how you remove the override. If the field is absent or set to DISABLED, AV transactions would be validated against the accepted_countries_token.When an AV transaction is blocked by av_accepted_countries_token, Marqeta returns the same block response it returns for accepted_countries_token: response code 1864 (country.blocked).No action is required for existing programs if the existing accepted_countries_token is appropriately handling AV transactions.For more information, see Card Products and Accepted Countries.

​
New afd_preauth_expiration_hours field on card products

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta now supports configuring the duration of automated fuel dispenser (AFD) pre-authorization hold expirations. Previously, AFD pre-authorization holds always expired after a fixed duration set by the card network (2 hours for Visa, 30 minutes for Pulse), with no way for programs to extend the hold to cover a merchant’s clearing window.The new optional config.transaction_controls.afd_preauth_expiration_hours field on the card product sets the AFD (MCC 5542) pre-authorization hold expiration, in whole hours, at the card product level. Marqeta resolves the hold duration in this order:
  1. The card product’s afd_preauth_expiration_hours, if set to a value greater than 0.
  2. A program-level default, if your Marqeta representative has configured one for your program and no card product override is present.
  3. The duration requested by the card network in the authorization message.
  4. The MCC group configuration.
  5. The program’s default expiration (typically 10 days), as a final fallback.
Set afd_preauth_expiration_hours to 0 to remove the card-product-level override and fall through to the next value in this order.
The configured duration is a minimum hold period. The actual hold release can occur slightly later, depending on system processing schedules.
To set a program-wide default instead of configuring individual card products, contact your Marqeta representative.No action is required for existing programs — card products that don’t set afd_preauth_expiration_hours are unaffected.This is a companion control to Card product-level AFD hold override, which configures the hold amount rather than its duration.For more information, see Card Products.
​

​
Fixed: Omitting the request body on PUT /fees/ returned a 400 error

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta fixed an issue where PUT /fees/{token} returned an unexpected 400 error when a request omitted the request body.With this release, this endpoint treats a request with no body as a no-op and returns 200 OK, leaving the fee unchanged.For more information, see Fees.

​
Fixed: POST /gpaorders/unloads allowed an amount of 0 or a negative value

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta fixed an issue where POST /gpaorders/unloads accepted an amount of 0 or a negative value.With this release, amount on this endpoint requires a minimum value of 0.01.For more information, see GPA Orders.

​
Fixed: Negative start_index or count returned an unexpected 500 error on several list endpoints

Platform release: V.2026.8.31.0Sandbox release date: October 7, 2026Production release date: October 7, 2026Marqeta fixed an issue where sending a negative start_index or count value to GET /fundingsources/programgateway, GET /accountholdergroups, GET /autoreloads, GET /businesstransitions/business/{business_token}, or GET /mccgroups returned an unexpected 500 Internal Server Error.With this release, these endpoints return 400 Bad Request and name the invalid parameter. Valid requests are unaffected.For more information, see Program Gateway Funding Sources, Account Holder Groups, Auto Reload, Business Transitions, and MCC Groups.
​

​
Corrected success response for POST /pins/reveal

Action requiredMarqeta has corrected the API reference for POST /pins/reveal. A successful request returns 200 with the card’s PIN in the pin field of the response body, not 204 with no body. If you generate client code from the Marqeta OpenAPI spec, regenerate your client so it reads pin from the 200 response.For more information, see Reveal pin.

​
Corrected Visa check eligibility webhook event type

Action requiredMarqeta has corrected the documented event type for the Visa check eligibility event from token.checkeligibility to digitalwallettoken.token.checkeligibility.Use digitalwallettoken.token.checkeligibility when you subscribe to this event and when you read the type field in the webhook notification.For more information, see Event types.

​
Corrected currency code in the currency conversion sample

Marqeta has corrected the sample currency conversion response in the Transaction Processing in Europe guide. The top-level currency_code field now shows EUR instead of USD, which matches the settlement currency code 978. This is a documentation change only. No action is required.For more information, see Transaction Processing in Europe.

​
Removed MAX_CARD_ORDERS_PER_DAY_LIMIT_REACHED from the Errors page

Marqeta has removed the MAX_CARD_ORDERS_PER_DAY_LIMIT_REACHED response enum, error code 400074, and the message Max card orders per day limit reached from the Errors page. This is a documentation update for accuracy only. No action is required.For more information, see Errors.

​
Corrected Greek and Romanian language codes for digital wallet tokens

Marqeta has updated the Digital Wallets Management API reference to list ell for Greek and ron for Romanian in the metadata.cardproduct_preferred_notification_language field, replacing grc and rou. This is a documentation only change.For more information, see Digital Wallets Management.

​
Updated translate_pin_from_card_token description for card creation

Marqeta has updated the description of the translate_pin_from_card_token field in the Cards API reference. The POST /cards request returns error code 400664 if you populate this field and set either reissue_pan_from_card_token or new_pan_from_card_token. The previous description mentioned only reissue_pan_from_card_token.For more information, see Create card.

​
Corrected the response for Visa Click to Pay get user data

Marqeta has updated the API reference for GET /digitalwallets/clicktopay/visa/getdata/{user_token} so that it matches the response the endpoint returns. This is a documentation change only. No action is required.The API reference now documents the following:
  • New cardholder fields: externalConsumerIDOwnerBID, nationalIdentifiers, and consent in data[].consumerInformation.
  • New payment instrument fields: cardType, issuerName, and panReferenceID in data[].paymentInstruments[].
  • Required fields: The fields that the response always includes are now marked Returned, such as externalConsumerID, firstName, lastName, phones, emails, locale, and countryCode.
  • Cardholder status: data[].consumerInformation.status (ACTIVE or DISABLED) replaces data[].consumerInformation.state, which the response never returned.
  • Billing address fields: The response returns the billing address as addressLine1, addressLine2, and addressLine3. The API reference previously listed address1 and address2 for the response, which it never returned. Requests to enroll a cardholder or card and to update card information continue to use address1 and address2.
For more information, see Retrieve user data for Click to Pay for Visa.