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.
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 istoken.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.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.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. You can also sign up to receive email notifications about sub-processor updates at Sub-processor 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.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.0Marqeta 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 code1919 (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.
New three-of-a-kind weak PIN detection
Platform release: V.2026.6.22.0You can now reject 4-digit card PINs that contain three or more identical digits in any position, such as1222, 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.0Marqeta has expanded the set of Mastercard fraud reason codes that map to human-readable descriptions. Thefraud.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.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.0Marqeta 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 theGET /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.0Marqeta now enables you to configure an Automated Fuel Dispenser (AFD) hold increase amount at the card product level using the newafd_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.New JIT Funding method
Platform release: V.2026.5.25.0The Just-in-Time (JIT) Funding object now includes a new method to support network stand-in processing (STIP) approvals for refunds.For a full list of JIT Funding object methods, see Gateway JIT Funding Messages.
New BIN prefix field in the Transaction object
Platform release: V.2026.5.25.0Marqeta 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 calledbin_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 code1011(card not found). Use this field to identify which BIN range or program the declined clearing belongs to for reconciliation and chargeback purposes.
/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.For a full list of error codes, see the Error Codes page.
New support for interchange adjustment transactions
Platform release: V.2026.5.25.0Action requiredMarqeta 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 issuerfee.collection.debit— generated if a refund for the lagged interchange is processed twice
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:For more information on webhook event types, see Event Types.For more information on webhook event types, see Event Types.
New Pulse transactions risk scores in the Transactions API
Platform release: V.2026.5.11.0Sandbox release date: June 1, 2026Production release date: June 1, 2026Marqeta now includes Pulse transaction risk scores in thefraud.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.New transaction response code for contactless declines in Canada
Platform release: V.2026.5.11.0Sandbox release date: June 1, 2026Production release date: June 1, 2026Marqeta 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.Fixed: fields not returned on Mastercard STIP transactions
Platform release: V.2026.6.22.0Marqeta has fixed an issue where thestandin_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.0Marqeta has fixed an issue where string fields in thecard_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.Updated digital banking documentation
Platform release: V.2026.6.8.0Marqeta now has two new pages for Digital Banking: External Cards and Transfers, which replace the previous Instant Funding page.- The 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 page documents endpoints that allow you to create and manage instant fund transfers (push or pull) over card rails.