> ## 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. # June 2026 Card Issuing and Processing Release Notes > Release notes for the Card Issuing and Processing platform in June 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. **New features** ## Check Eligibility webhook for DWT Marqeta now sends a webhook event when a card is declined during the check eligibility step of Visa's Digital Wallet Tokenization (DWT) flow. Previously, you only received webhook events during the approve provisioning step. This update gives you earlier visibility into declined tokenization attempts, enabling you to monitor provisioning activities more closely, and detect potential fraudulent activity such as bank identification number (BIN) attacks. The new webhook event type is `token.checkeligibility`. This event is triggered only for declined token provisioning attempts — approved check eligibility requests do not generate a notification. Ensure that your endpoint is configured to handle the `token.checkeligibility` event type to receive the webhook. For more information on webhook event types, see [Event Types](https://www.marqeta.com/docs/core-api/event-types.md#_digital_wallet_token_visa_only_events). ## Google Unified Push Provisioning APIs Marqeta now supports Google Unified Push Provisioning (UPP) APIs in production. You can now integrate production and begin testing activities for Google UPP, covering both Web Push Provisioning and In-App Provisioning. As part of the onboarding process, you must complete the Google Console setup, including configuring your Google business profile and submitting an account-linking request to connect your issuer profile with Marqeta. This ensures your account leverages Marqeta's pretty good privacy (PGP) keys for Google UPP, eliminating the need to exchange keys directly with Google. For more information, contact your Marqeta representative. ## New message reason in Digital Wallet Marqeta now sends a new message reason, `Out of date credential - expired PAN`, for digital wallet token transitions. Marqeta terminates tokens that are associated with expired PANs as part of Visa's best practices. Card programs will now receive this updated message reason in such use cases. For more information, see [Transitioning DWTs](https://www.marqeta.com/docs/developer-guides/managing-the-digital-wallet-token-lifecycle.md#_transitioning_dwts). ## Updated sub-processor list Marqeta's sub-processor list has been updated as of 12 June 2026. Marqeta engages sub-processors to assist with the provisioning of the card program management and processing services offered to our customers. Our list of sub-processors is available at [Sub-processors](https://www.marqeta.com/sub-processors). You can also sign up to receive email notifications about sub-processor updates at [Sub-processor Updates](https://www.marqeta.com/subprocessor-updates). ## Enriched data in Real-Time Decisioning The Marqeta Real-Time Decisioning (RTD) platform now supports additional transaction and merchant data beyond standard authorization fields, giving programs more context to detect fraud as transactions happen. Requests can include order details, account metadata, device information, shipping and billing information, geolocation, and behavioral signals. By combining this additional context with the Marqeta fraud models, you can detect suspicious activity more accurately, reduce false positives, recognize trusted merchants, and improve approval rates for legitimate transactions. > [!NOTE] > > This data might not be available for all transactions. Enriched merchant data is sourced from third-party data partners and matched against transactions that flow through RTD. If there is no match to an existing transaction in RTD, the data will not be available. ## Real-time fraud decisioning on token provisioning The Marqeta Real-Time Decisioning (RTD) engine now integrates directly into the token provisioning flow, letting issuing programs detect and block fraud during token provisioning before a response is returned to the card network. If you choose to activate this feature for your program, every token provision request for Visa and Mastercard is evaluated by RTD's rule engine before the network response is issued, providing you with real-time fraud decisioning. RTD enables you to set transaction thresholds to detect systematic primary account number (PAN) enumeration from specific token requestors or devices. RTD then automatically blocks token requestors and devices after they exceed configurable thresholds. RTD also enables you to set rules on when you want to unblock requestors and devices after an attack occurs. When RTD declines a token provision request due to suspected fraud, the Token Provisioning service returns a standardized network response. This makes declined invalid PANs indistinguishable from fraud-triggered declines to prevent enumeration signal leakage. To activate this feature for your program, contact your Marqeta representative. ## New response code for terminated cards with reissued replacement **Platform release:** V.2026.6.22.0 Marqeta now returns a distinct response code when a terminated card has a replacement card issued on the same PAN with a new expiry date. This enables merchants to recognize that updated card credentials are available and retry the transaction with the new card details. Previously, all terminated card declines returned response code `1919` (`card.terminated`), regardless of whether a replacement card existed. Merchants couldn't distinguish between a permanently closed account and one where a new card had been issued. Marqeta enhanced the following reason codes to distinguish between these particular scenarios. * **New response code `1953` (`card.terminated.reissued`):** Returned when a terminated card has an active replacement card on the same PAN with a different expiry date. This signals that new account information is available. Merchants should update their stored credentials and retry the transaction. * **Updated response code `1919` (`card.terminated`):** Now exclusively indicates a permanent termination with no replacement card. Merchants should not retry. Programs that terminate cards and reissue on the same PAN in the case of lost or stolen replacements and card refreshes, will now send merchants the correct "update credentials" signal. This reduces failed recurring payments and improving the cardholder experience. Programs that terminate cards without reissuing see no behavioral change. For more information, see [Transaction Response Codes](https://www.marqeta.com/docs/developer-guides/about-transactions.md#_transaction_response_codes). ## New three-of-a-kind weak PIN detection **Platform release:** V.2026.6.22.0 You can now reject 4-digit card PINs that contain three or more identical digits in any position, such as `1222`, `5999`, `7771`, `6626`, `1141`, and `9199`. This adds 360 new combinations to the existing weak-PIN blocklist, strengthening protection against easily guessed PINs. This feature is controlled by a new setting at a program level. This setting is off by default, so existing programs see no change in behavior. When you enable it for a program, the validation applies to both the set-PIN and change-PIN flows for online PIN, with matching enforcement at the Hardware Security Module (HSM) layer. Rejected PINs return the existing weak-PIN error code. This feature requires additional activation steps. To activate three-of-a-kind enforcement for your program, contact your Marqeta representative. ## Updated Mastercard transaction risk score reason code descriptions **Platform release:** V.2026.6.22.0 Marqeta has expanded the set of Mastercard fraud reason codes that map to human-readable descriptions. The `fraud.network.transaction_risk_score_reason_description` field now returns meaningful descriptions for codes 30–72 and 99, in addition to the existing codes 01–29. Previously, the codes 30-72, 99, and any unmapped value were passed through with the description `OTHERS`. With this release, these codes return descriptive text that explains the risk factors Mastercard identified for the transaction. This change affects only the `fraud.network.transaction_risk_score_reason_description` field. The `fraud.network.transaction_risk_score_reason_code` field is unchanged. It passes the raw code value from Mastercard, whether or not a description mapping exists. Any value not in the mapping table including the non-numeric values Mastercard might send in the future, continues to return `OTHERS` as description. This change applies to Mastercard transactions across all programs. > [!NOTE] > > This change is backward-compatible. Codes 01–29 are unchanged, and no action is required. Codes 30–72 and 99 now populate with descriptions where they were previously unmapped. ## Webhooks for declined authorization reversals **Platform release:** V.2026.6.22.0 Marqeta now sends a webhook notification when an authorization reversal is declined. Previously, when an authorization reversal could not be matched to an original transaction, no webhook was sent. The declined reversal was visible only in the `GET /transactions` API and the dashboard, however, programs had no real-time notification. With this release, programs subscribed to transaction events receive an `authorization.reversal` webhook with a `DECLINED` state whenever a reversal is declined for any reason. The webhook payload includes the standard transaction fields, with `response.code` containing the decline reason code and `response.memo` containing the decline reason description. This feature is enabled by default for all programs. If your program does not want to receive webhooks for declined reversals, contact your Marqeta representative to disable this feature. ## Card product-level AFD hold override **Platform release:** V.2026.6.8.0 Marqeta now enables you to configure an Automated Fuel Dispenser (AFD) hold increase amount at the card product level using the new `afd_hold_increase_override` field of the `PUT /v3/cardproducts/{token} endpoint`. When set, this value overrides the program-wide MCC group hold increase for MCC 5542 (Automated Fuel Dispenser) transactions on that card product. The `afd_hold_increase_override` field accepts a positive whole number expressed in the major units of the cardholder's billing currency (for example, a value of 75 indicates \$75 or €75, not cents). The field does not perform runtime currency conversion, the value is applied as-is. The `hold_increase.type` remains `UP_TO_LIMIT`, consistent with existing MCC group behavior, and `hold_expiration_days` from the MCC group configuration continues to apply regardless of the override configuration. If `afd_hold_increase_override` is not configured on a card product, the MCC group `hold_increase.value` drives hold amount. This change enables programs with mixed card products to now set different hold values for each product, and multi-currency programs can avoid insufficient holds that previously resulted from hold values being interpreted in local currency units. For more information on webhook event types, see [Card Products](core-api/card-products). ## New JIT Funding method **Platform release:** V.2026.5.25.0 The Just-in-Time (JIT) Funding object now includes a new method to support network stand-in processing (STIP) approvals for refunds. | Field | Value | | - | - | | Method | `pgfs.refund.standin` | | Purpose | Informative | | Funding event | Unload | | Description | An authorization to fund a user's general purpose account (GPA) via a refund (credit voucher) was approved by network stand-in processing. | For a full list of JIT Funding object methods, see [Gateway JIT Funding Messages](https://www.marqeta.com/docs/core-api/gateway-jit-funding-messages.md#_the_jit_funding_object). ## New BIN prefix field in the Transaction object **Platform release:** V.2026.5.25.0 Marqeta now enables card programs to identify and reconcile batch clearing declines when the card does not exist in the Marqeta system, using the new transaction object field called `bin_prefix`. This new field contains the first 8 digits of the card number from the network batch clearing record. Marqeta now declines transactions in a batch clearing file for a card that doesn't exist in the Marqeta system with response code `1011` (card not found) and sends a webhook. Previously, the webhook did not contain the card identifier, which hindered programs' ability to manage multiple BINs and to determine which program, settlement reporting entity, or BIN range the declined transaction belonged to. Programs that manage multiple BINs or settlement reporting entities (SREs) can use the `bin_prefix` field to map card-not-found declines to the correct program or reconciliation ledger and automate chargeback filing against merchants who submit clearing for cards that were never issued. * `bin_prefix` - Contains the first 8 digits of the card number (BIN prefix) from the network batch clearing record. Populated only when a batch clearing file transaction is declined with response code `1011` (card not found). Use this field to identify which BIN range or program the declined clearing belongs to for reconciliation and chargeback purposes. This field is available in webhook payloads and GET `/v3/transactions` API responses. It is populated only on batch clearing file transactions declined with response code `1011`. Marqeta returns a new validation error if you attempt to set `bin_prefix` on an inbound API request. | Code | Message | | - | - | | `400986` | Field not permitted on inbound: `bin_prefix` | For a full list of error codes, see the [Error Codes](https://www.marqeta.com/docs/core-api/errors.md#400900%E2%80%93400999-error-codes) page. ## New support for interchange adjustment transactions **Platform release:** V.2026.5.25.0 Action required Marqeta now supports interchange adjustment transactions for the Visa Commercial Enhanced Data Program (CEDP). These transactions allow Marqeta to process lagged interchange adjustments that Visa generates after settlement when a transaction does not meet CEDP data quality standards. When Visa identifies a qualifying transaction — typically within 10–15 days of settlement — it issues an adjustment to true up to the applicable non-CEDP interchange rate. Marqeta receives this adjustment as part of the Visa Base II clearing file and processes it automatically. **Note:** Interchange adjustment transactions are non-cardholder-impacting. They do not affect cardholder account balances and only impact the Marqeta internal ledgers (VisaNet Interchange and Visa Interchange Earnings). Interchange adjustment transactions are enabled at the program level via a feature flag. When enabled, Marqeta automatically approves and posts the adjustment without requiring an authorization decision from your system. To enable interchange adjustment transactions for your program, contact your Marqeta representative. A second feature flag, enabled by default alongside the first, generates webhook notifications for each adjustment. The two webhook event types associated with interchange adjustments are: * `fee.collection.credit` — generated when a credit adjustment is issued to the issuer * `fee.collection.debit` — generated if a refund for the lagged interchange is processed twice You must configure your platform to receive and process `fee.collection.credit` and `fee.collection.debit` webhook events. If you do not want to receive these webhook events, contact your Marqeta representative to disable the second feature flag. The following fields are included in interchange adjustment webhook payloads: | Field | Description | New or existing | | - | - | - | | `type` | Transaction type: `fee.collection.debit` or `fee.collection.credit` | Existing | | `sub_type` | Value: `interchange_adjustment` | **New** | | `cardholder_impact` | Indicates whether the transaction impacts the cardholder account balance. Always `false` for interchange adjustments. | **New** | | `network_metadata.message_reason_code` | Reason code received from Visa. Initial value: `5230`. | **New** | | `original_interchange_rate_descriptor` | The original interchange rate descriptor (IRD/FPI) received from Visa. | **New** | | `interchange_rate_descriptor` | The new IRD/FPI received from Visa. | Existing | | `original_settlement_date` | The original settlement date received from Visa. | **New** | | `settlement_date` | The most recent settlement date received from Visa. | Existing | | `amount` | The amount to apply to the internal ledger. | Existing | | `currency_code` | The currency for the adjustment amount. | Existing | | `preceding_related_transaction_token` | Token for the related clearing transaction. | Existing | | `original_transaction_token` | Token for the related authorization transaction. | Existing | | `multi_clearing_sequence_number` | Sequence number for the original clearing transaction. | Existing | For more information on webhook event types, see [Event Types](https://www.marqeta.com/docs/core-api/event-types.md). For more information on webhook event types, see [Event Types](https://www.marqeta.com/docs/core-api/event-types.md). ## New Pulse transactions risk scores in the Transactions API **Platform release:** V.2026.5.11.0 **Sandbox release date:** June 1, 2026 **Production release date:** June 1, 2026 Marqeta now includes Pulse transaction risk scores in the `fraud.network.transaction_risk_score` field of the `/transactions` endpoint. This score ranges from 1-99, with a higher score indicating higher risk. For more information, see [Transactions](https://www.marqeta.com/docs/core-api/transactions/). ## New transaction response code for contactless declines in Canada **Platform release:** V.2026.5.11.0 **Sandbox release date:** June 1, 2026 **Production release date:** June 1, 2026 Marqeta has created a new transaction response code (`1952`) for contactless transactions in Canada that are declined because they exceed the amount limit. For more information, see the full list of [transaction response codes](https://www.marqeta.com/docs/developer-guides/about-transactions.md#_transaction_response_codes). **Bug fixes** ## Fixed: fields not returned on Mastercard STIP transactions **Platform release:** V.2026.6.22.0 Marqeta has fixed an issue where the `standin_by` and `standin_approved_by` fields were missing from Mastercard transactions approved through Stand-In Processing (STIP). When a card network approves a transaction on the issuer's behalf through STIP, the transaction should include `standin_by: "NETWORK"` and `standin_approved_by: "NETWORK"`. In certain cases, these fields were absent even though the transaction was correctly identified as a STIP approval. This prevented programs from programmatically identifying network-approved standin transactions. With this release, `standin_by` and `standin_approved_by` are reliably populated for all STIP approvals. The fields appear in both the transaction webhook payload and the `GET /v3/transactions` API response. This fix applies to STIP approvals across all card networks. The known occurrences were on Mastercard transactions. No action is required. ## Fixed: Control characters in card\_acceptor fields **Platform release:** V.2026.5.25.0 Marqeta has fixed an issue where string fields in the `card_acceptor` object, such as the merchant name, address, and URL, could contain control characters passed through from the card network message, such as null bytes (`\u0000`). These characters caused JSON parsing errors for some programs. Marqeta now removes control characters (U+0000 through U+001F, and U+007F) from all `card_acceptor` string fields in API responses, webhooks, and Gateway JIT Funding messages, for new and previously stored transactions. All other characters, including accented letters, are unchanged. No action is required. For more information, see [Transactions](https://www.marqeta.com/docs/core-api/transactions). **Documentation changes** ## Updated digital banking documentation **Platform release:** V.2026.6.8.0 Marqeta now has two new pages for Digital Banking: [External Cards](https://www.marqeta.com/docs/core-api/external-cards) and [Transfers](https://www.marqeta.com/docs/core-api/digital-banking-transfers), which replace the previous *Instant Funding* page. * The [External Cards](https://www.marqeta.com/docs/core-api/external-cards) page documents the endpoints that allow you to add a non-Marqeta external card required to push and pull funds from external funding sources. * The [Transfers](https://www.marqeta.com/docs/core-api/digital-banking-transfers) page documents endpoints that allow you to create and manage instant fund transfers (push or pull) over card rails. ## Related topics - [June 2026 Risk, Fraud, and Disputes Release Notes](https://www.marqeta.com/docs/developer-guides/risk-fraud-disputes-release-notes/2026-06.md) - [June 2026 UX Toolkit Release Notes](https://www.marqeta.com/docs/developer-guides/ux-toolkit-release-notes/2026-06.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) - [July 2026 Card Issuing and Processing Release Notes](https://www.marqeta.com/docs/developer-guides/card-issuing-processing-release-notes/2026-07.md)