Skip to main content
To follow new Card Issuing and Processing release notes with RSS, subscribe to the current release notes feed: 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.
​

​
Restricted access for MCC group creation and updates

Action requiredBreaking changeMarqeta now restricts POST /v3/mccgroups and PUT /v3/mccgroups/{token} to API credentials with the program-manager role. Previously, these endpoints were accessible to credentials with the write role.Merchant category code (MCC) groups define transaction categorization rules used by authorization controls. Because MCC groups are program-level configuration rather than cardholder management operations, this change aligns MCC group management with how other program-level resources are already restricted, providing a more consistent and predictable permissions model.
If your integration uses the credentials with write role to create or update MCC groups, those requests now receive a 403 Forbidden response. To continue managing MCC groups, update your integration to use credentials that carry the program-manager role.
To request program-manager access, or for more information about this change, contact your Marqeta representative.For more information, see MCC Groups and Authorization Controls.
​

​
New TC10 and TC20 transaction types in the VSS Detail Report

Action requiredMarqeta now includes two additional transaction types in the VSS Detail Report sourced from the Visa Base II clearing file: TC10 (fee collection) and TC20 (funds disbursement). Previously, records for these transaction types were absent from the report, creating a gap that prevented programs from fully reconciling network fee adjustments and funds disbursements against their settlement activity.The type and original_type fields in the VSS Detail Report now accept two new values:
  • FEE_COLLECTION — a fee adjustment applied to the cardholder account by the network (TC10)
  • FUNDS_DISBURSEMENT — a funds disbursement applied to the cardholder account by the network (TC20)
If your downstream systems or reconciliation processes consume the VSS Detail Report, ensure they can handle FEE_COLLECTION and FUNDS_DISBURSEMENT as values in the type and original_type fields. No other fields or file structures are changing.

​
New is_offline_approved field on clearing transactions approved offline

Marqeta now identifies offline-approved transactions in the clearing transaction payload and the corresponding clearing webhook event. Previously, no field distinguished a transaction that the card and terminal approved offline, without real-time issuer approval, from a standard online-authorized transaction.The new is_offline_approved field returns Y when the card and terminal approved the transaction offline, for both Visa and Mastercard transactions. This field is included automatically in clearing transaction API responses and clearing webhook payloads. No action is required — this field is additive.For more information, see Transactions.

​
Additional digital wallet token transition webhook during Visa yellow-flow provisioning

Marqeta now supports processing of the create notification that Visa sends after a token provisioning request is approved and step-up (yellow-flow) verification is triggered. This notification includes the token PAN in an additional field, which Marqeta syncs ahead of activation.If you’re subscribed to digitalwallettokentransition.* webhooks, you now receive an additional digital wallet token transition webhook (type: update, reason: SYNC_TOKEN_PAN_FROM_NETWORK_PRE_ACTIVATION) when this sync occurs. No action is required from you. This event is informational only, and the existing activation transition and webhook are unaffected.This change applies only to Visa yellow-flow provisioning. There is no equivalent change for green-flow provisioning or for Mastercard.For more information, see Digital wallet token transition events and Digital Wallets Management.

​
New Token Provisioning Insight field for Mastercard digital wallet tokens

Platform release: V.2026.8.3.0Marqeta now returns Mastercard’s Token Provisioning Insight data — a risk score and a reason code for a digital wallet token — on transactions and digital wallet tokens. This satisfies a Mastercard 2026 network certification requirement.The new field, token_provisioning_insight_data, is available at the following paths.
  • On transactions: digital_wallet_token_transaction_service_provider_info.digital_service_provider.token_provisioning_insight_data
  • On digital wallet tokens: token_service_provider.token_provisioning_insight_data
The value is a three-character string that Marqeta returns to you exactly as received from the network, with no modification. This field is read-only; you can’t set or update it.
  • The first character is the risk score, 0-9, where higher values indicate a higher degree of risk.
  • The last two characters are the reason code, AA-ZZ, where AA represents the highest-risk reason and ZZ represents the lowest-risk reason.
For example, 5JA represents a risk score of 5 and reason code JA.
This field is Mastercard-only and always null for Visa and other card networks.
This field is additive, so no action is required to receive it. Use the risk score and reason code to strengthen your own fraud decisioning for Mastercard digital wallet transactions.For more information, see Transactions and Digital Wallets Management.

​
Expanded digital wallet token data for Mastercard transactions

Platform release: V.2026.8.3.0Marqeta now returns expanded digital wallet token data for Mastercard transactions, giving you access to additional token information ahead of the Mastercard AN 13386.2 mandate, which takes effect 10 November 2026.Previously, transaction responses included data for up to two digital service providers per transaction. Transaction responses now include data for up to five digital service providers per transaction, including a new indicator that flags when a digital service provider is an affinity partner (a co-branded or loyalty partner integrated into the digital wallet) rather than the primary wallet provider.In a token-to-token transaction, a cardholder pays with a token that was itself provisioned from another digital wallet token, rather than directly from the underlying PAN. For example, when a token is loaded from one wallet app into a second wallet app. For these transactions, Marqeta now also returns additional information about the source token, that is the original token from which the transaction token was derived.
  • Original token number.
  • Token unique reference.
  • Token requestor ID.
  • Payment app or device ID.
These fields are included automatically for Mastercard transactions in the digital_wallet_token_transaction_service_provider_info object, across Transaction API responses, JIT Funding requests, and webhook payloads. Existing integrations continue to work without changes. Use these fields to trace a transaction back to its originating wallet or device, such as when you’re investigating a dispute or a suspected fraud case that involves token-to-token provisioning.
Source token information requires Data Element (DE) 104 / Subelement (SE) 006 to be enabled directly with Mastercard. Digital service provider fields are returned automatically and don’t require additional configuration.
Equivalent clearing file data (PDS 0016) is not supported at this moment.For more information, see Transactions and Digital Wallets Management.

​
Program-level decisioning for CVV1 mismatches at automated fuel dispensers

Platform release: V.2026.8.3.0Marqeta now enables JIT Funding programs to make the final authorization decision on card security code (CVV1) mismatches at automated fuel dispenser (AFD) transactions (MCC 5542), instead of Marqeta automatically declining the transaction.At outdoor pay-at-pump terminals, the cardholder never enters a CVV, so the only available security signal is the CVV1 value read from the card’s magnetic stripe. Previously, a CVV1 mismatch always triggered an automatic decline before the transaction reached your JIT Funding gateway.For card products with this feature enabled, a CVV1 mismatch on an authorization or sale request at MCC 5542 no longer triggers an automatic decline. Instead, the transaction continues to your JIT Funding gateway with the verification result populated in the card_security_code_verification object (type: CVV1, response.code: 0001), for your program to evaluate it using your own risk signals.
The CVV1 value itself is never included in the JIT Funding payload or otherwise shared with your program — only the verification result.
To decline a transaction after evaluating the CVV1 mismatch yourself, use the new CRYPTOGRAPHIC_FAILURE decline reason. This decline reason maps to the same network response code that the automatic CVV1-mismatch decline already used, so there’s no change in what the card network sees.This feature applies only to CVV1 (magnetic stripe) verification at MCC 5542, and doesn’t apply to CVV2 verification or other merchant category codes.This feature requires additional activation steps. To learn about activating it for your program, contact your Marqeta representative.For more information, see Gateway JIT Funding Messages and Transactions.

​
Amex support and updated PULSE range for network transaction risk score

Platform release: V.2026.8.3.0Marqeta now returns network transaction risk scores for American Express (Amex) transactions, and has updated the allowable range for PULSE-provided scores.Previously, the fraud.network.transaction_risk_score field on the /transactions endpoints supported Mastercard, Visa, and PULSE only, with PULSE scores limited to a range of 1-99.The fraud.network.transaction_risk_score field now supports the following ranges, by card network.
  • Mastercard: 0-99
  • Visa: 1-99
  • PULSE: 0-99
  • Amex: 0-99
No action is required — this is an expansion of an existing field.For more information, see Transactions.

​
Issuer country code included in transaction payload and webhooks

Platform release: V.2026.8.3.0Marqeta now includes an issuer_country field in the transaction object, available in GET /transactions responses and transaction webhooks. Use this field to apply country-specific compliance, tax, or risk logic based on the card’s issuing country, without maintaining your own bank identification number (BIN)-to-country mapping.Previously, transaction payloads and webhooks didn’t identify the issuing country of the card used in a transaction.For this new field, Marqeta normalizes all values to ISO 3166 numeric format; alpha-3 codes are converted (for example, FRA becomes 250), and numeric codes pass through unchanged.If Marqeta can’t resolve the issuing country for a transaction, the issuer_country field is omitted.To enable this field for your program, contact your Marqeta representative.For more information, see Transactions and Card Products.

​
Existing card_acceptor.network_assigned_id field now available for Visa transactions

Platform release: V.2026.7.20.0Sandbox release date: August 11, 2026Production release date: August 18, 2026The card_acceptor.network_assigned_id field on the transaction payload is now populated for Visa transactions. Previously, this field was available for Mastercard transactions only.The card_acceptor.network_assigned_id field is a unique identifier assigned by the card networks to identify a merchant or payment facilitator. It can be used for merchant aggregation and identification across different acquirers.For Visa transactions, this field now contains the Visa Merchant Identifier (VMID). Marqeta extracts the VMID from the network message when present. For Visa clearing transactions, the value is inherited from the matched authorization.For Mastercard transactions, Marqeta extracts the value from the network message for both authorizations and clearings when present.For more information, see Transactions.

​
New indicator for Mastercard stablecoin and CBDC purchases

Platform release: V.2026.7.20.0Sandbox release date: August 11, 2026Production release date: August 18, 2026Action requiredEffective 24 July 2026, Marqeta distinguishes Mastercard purchases of fiat-backed stablecoins and central bank digital currencies (CBDCs) that are Transaction Type Identifier (TTI) P76, from floating cryptocurrencies, TTI P70.Stablecoin and CBDC purchases now surface as special_condition_indicator = STABLECOIN_CBDC_PURCHASE. Floating-cryptocurrency purchases continue to surface as special_condition_indicator = CRYPTOCURRENCY_PURCHASE.If your program uses the Marqeta crypto-decline control, no action is required. Stablecoins and floating cryptocurrencies are now both blocked automatically.If your program uses the special_condition_indicator field for decisions or reports, review any logic that treats CRYPTOCURRENCY_PURCHASE as a catch-all for all crypto purchases, and add STABLECOIN_CBDC_PURCHASE where stablecoin and CBDC purchases should be treated the same way.For more information, see Card Network Certifications and Transactions.

​
BIN prefix now included on card-not-found authorization declines

Platform release: V.2026.7.20.0Sandbox release date: August 11, 2026Production release date: August 18, 2026Marqeta now includes the bin_prefix field on authorization declines with a card-not-found reason, matching the bank identification number (BIN) prefix support already available for batch clearing declines.Previously, an authorization decline with response code 1011 (card not found) returned the decline reason without a card identifier, so programs could only reconcile card-not-found declines that arrived through batch clearing.The bin_prefix field is now populated on authorization decline events with response code 1011, in addition to the batch clearing declines documented previously. Use this field to identify the BIN range or program associated with the declined card without exposing the full card number.No action is required — this field is additive.For more information, see Transactions.

​
New created_timestamp field on digital wallet token transitions

Platform release: V.2026.7.20.0Sandbox release date: August 11, 2026Production release date: August 18, 2026Digital wallet token (DWT) transition responses and webhooks now include a created_timestamp field with millisecond precision. Use this field to order transitions that share the same whole-second created_time.This field is available on the digital_wallet_token_transition_response model returned by POST /v3/digitalwallettokentransitions, GET /v3/digitalwallettokentransitions/{token}, and GET /v3/digitalwallettokentransitions, and is included on the DWT transition webhook.The created_timestamp field is an ISO-8601 UTC timestamp expressed to the millisecond, for example, 2026-07-14T10:30:00.123Z. The existing created_time field is unchanged and remains second-precision. The value is stable across webhook send, resend, and replay.No action is required — this field is additive.
Transitions created before this release might not include a created_timestamp. Fall back to created_time for those transitions.
For more information, see Digital Wallets Management.
​

​
BIN prefix now included on single-message authorization declines

Platform release: V.2026.8.3.0Marqeta now populates the bin_prefix field on single-message (SMS) authorization declines with a card-not-found reason (response code 1011), in addition to the dual-message authorization declines already supported.Use this field to identify the BIN range or program associated with the declined card without exposing the full card number.No action is required — this field is additive.For more information, see Transactions.
​

​
Fixed: KYC record with a null manual_override value returned an error at HTTP 200

Platform release: V.2026.8.3.0Marqeta fixed an issue where GET /kyc/{token}, GET /kyc/user/{user_token}, and GET /kyc/business/{business_token} returned an error payload with an HTTP 200 status code for KYC records that had no stored manual_override value.With this release, these endpoints return the KYC record correctly, with manual_override set to false.For more information, see KYC Verification.

​
Fixed: created_timestamp field on transition endpoints now follows ISO 8601 format

Platform release: V.2026.7.20.0Sandbox release date: August 11, 2026Production release date: August 18, 2026Marqeta has fixed an issue where the created_timestamp field on card, user, and business transition responses (/cardtransitions, /usertransitions, /businesstransitions) didn’t follow the ISO 8601 standard.Previously, created_timestamp used a non-standard separator between the seconds and milliseconds component. The corrected format uses the standard ISO 8601 period separator (YYYY-MM-DDThh:mm:ss.sssZ).To avoid disrupting existing integrations that parse the non-standard format, the corrected format is gated behind a per-program setting and is disabled by default.To enable the corrected ISO 8601 format for your program, contact your Marqeta representative.For more information, see Card Transitions, User Transitions, and Business Transitions.
​

​
Documentation site information architecture enhancements

Marqeta has reorganized the documentation site to make navigation more intuitive. The structure of the site has changed, but all existing content remains available in its new location.In the first round of changes, release notes and card network certifications moved to their own tabs in the top navigation bar. The Core API and DiVA API references now live in the API Reference tab in the top navigation bar; use the drop-down menu to switch between them.