> ## 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. # August 2026 Card Issuing and Processing Release Notes > Release notes for the Card Issuing and Processing platform in August 2026: new features, enhancements, fixed issues, deprecations, and notable documentation changes. 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` > [!NOTE] > > 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. **Breaking changes** ## Restricted access for MCC group creation and updates Action required Breaking change Marqeta 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. > [!WARNING] > > 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](https://www.marqeta.com/docs/core-api/mcc-groups) and [Authorization Controls](https://www.marqeta.com/docs/core-api/authorization-controls). **New features** ## New TC10 and TC20 transaction types in the VSS Detail Report Action required Marqeta 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) > [!WARNING] > > 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](https://www.marqeta.com/docs/core-api/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](https://www.marqeta.com/docs/core-api/event-types.md#_digital_wallet_token_transition_events) and [Digital Wallets Management](https://www.marqeta.com/docs/core-api/digital-wallets-management). ## New Token Provisioning Insight field for Mastercard digital wallet tokens **Platform release:** V.2026.8.3.0 Marqeta 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`. > [!NOTE] > > 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](https://www.marqeta.com/docs/core-api/transactions) and [Digital Wallets Management](https://www.marqeta.com/docs/core-api/digital-wallets-management). ## Expanded digital wallet token data for Mastercard transactions **Platform release:** V.2026.8.3.0 Marqeta 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. > [!NOTE] > > 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](https://www.marqeta.com/docs/core-api/transactions) and [Digital Wallets Management](https://www.marqeta.com/docs/core-api/digital-wallets-management). ## Program-level decisioning for CVV1 mismatches at automated fuel dispensers **Platform release:** V.2026.8.3.0 Marqeta 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. > [!NOTE] > > 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](https://www.marqeta.com/docs/core-api/gateway-jit-funding-messages.md) and [Transactions](https://www.marqeta.com/docs/core-api/transactions). ## Amex support and updated PULSE range for network transaction risk score **Platform release:** V.2026.8.3.0 Marqeta 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](https://www.marqeta.com/docs/core-api/transactions). ## Issuer country code included in transaction payload and webhooks **Platform release:** V.2026.8.3.0 Marqeta 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](https://www.marqeta.com/docs/core-api/transactions) and [Card Products](https://www.marqeta.com/docs/core-api/card-products). ## Existing card\_acceptor.network\_assigned\_id field now available for Visa transactions **Platform release:** V.2026.7.20.0 **Sandbox release date:** August 11, 2026 **Production release date:** August 18, 2026 The `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](https://www.marqeta.com/docs/core-api/transactions). ## New indicator for Mastercard stablecoin and CBDC purchases **Platform release:** V.2026.7.20.0 **Sandbox release date:** August 11, 2026 **Production release date:** August 18, 2026 Action required Effective 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](https://www.marqeta.com/docs/developer-guides/card-network-certifications.md) and [Transactions](https://www.marqeta.com/docs/core-api/transactions). ## BIN prefix now included on card-not-found authorization declines **Platform release:** V.2026.7.20.0 **Sandbox release date:** August 11, 2026 **Production release date:** August 18, 2026 Marqeta 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](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-06.md#new-bin-prefix-field-in-the-transaction-object). 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](https://www.marqeta.com/docs/core-api/transactions). ## New created\_timestamp field on digital wallet token transitions **Platform release:** V.2026.7.20.0 **Sandbox release date:** August 11, 2026 **Production release date:** August 18, 2026 Digital 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. > [!NOTE] > > 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](https://www.marqeta.com/docs/core-api/digital-wallets-management). **Enhancements** ## BIN prefix now included on single-message authorization declines **Platform release:** V.2026.8.3.0 Marqeta 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](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-08.md#bin-prefix-now-included-on-card-not-found-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](https://www.marqeta.com/docs/core-api/transactions). **Bug fixes** ## Fixed: KYC record with a null manual\_override value returned an error at HTTP 200 **Platform release:** V.2026.8.3.0 Marqeta 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](https://www.marqeta.com/docs/core-api/kyc-verification). ## Fixed: created\_timestamp field on transition endpoints now follows ISO 8601 format **Platform release:** V.2026.7.20.0 **Sandbox release date:** August 11, 2026 **Production release date:** August 18, 2026 Marqeta 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](https://www.marqeta.com/docs/core-api/card-transitions), [User Transitions](https://www.marqeta.com/docs/core-api/user-transitions), and [Business Transitions](https://www.marqeta.com/docs/core-api/business-transitions). **Documentation changes** ## 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. ## Related topics - [August 2026 UX Toolkit Release Notes](https://www.marqeta.com/docs/developer-guides/ux-toolkit-release-notes/2026-08.md) - [July 2026 Card Issuing and Processing Release Notes](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-07.md) - [April 2026 Card Issuing and Processing Release Notes](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-04.md) - [May 2026 Card Issuing and Processing Release Notes](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-05.md) - [June 2026 Card Issuing and Processing Release Notes](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-06.md)