> ## 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. # Release Notes > Release notes are a convenient, central location to learn about the new features, improvements, and documentation changes in each of Marqeta's products. Updated 2-4 times a month. {/* ORDER OF APPEARANCE OF RN CONTENT General guidelines when adding new release categories (i.e., new H3 sections): - Sort all the various releases in a month by product, and THEN by date. For example, keep all Credit releases together in the same month, without a jCard release appearing in the middle. This makes it easier for readers to find what they are looking for. - Add newer releases to the TOP of their product's section. For example, release 2025.1.16 of a given product should appear BEFORE release 2025.1.9 of the same product. */} {/* (2022-12-05): Don't forget to add a section to the end of the template above called "Public repository and sample applications" when the time is right. */} {/* Boilerplate for rolled-back jCard releases: The of the Marqeta platform was rolled back on . */}

New features

Disputes portal available in early access
The new Disputes portal is now available in early access. The portal will eventually replace the Disputes section of the Marqeta Dashboard with a unified platform that features guided agent workflows, enhanced investigation tools, embedded communications, and actionable reporting and insights. The Disputes portal reaches general availability on 15 August 2026. At that point, it will be backed by the standard Marqeta service level agreement (SLA) and support commitments. To begin early access onboarding, contact your Marqeta representative. Once enrolled, access the portal at [disputes.marqeta.com](https://disputes.marqeta.com). For a full overview of the Disputes portal, see [About the Disputes Portal](/developer-guides/about-disputes-portal).

Platform release 2026.7.6.0

New features

Stop orders now match on original transaction amount
Stop order placement and enforcement now include the original transaction amount as part of the matching key, in addition to the card and merchant ID. This resolves the following issues: * **Shared-MID merchants:** For merchants that use a single merchant ID (MID) across multiple recurring subscriptions, such as marketplace subscription billing, a stop order on one subscription no longer blocks authorizations for other subscriptions with a different transaction amount at the same merchant. * **Cross-cycle duplicates:** Placing a stop order for one billing cycle of a recurring charge now conflicts with (returns `409`) an existing stop order for the same card, merchant, and amount, instead of creating a redundant, disconnected stop order per cycle. The stop order response now includes a new field, `original_amount`, which Marqeta derives automatically from the underlying transaction. This field is not a required request parameter. Marqeta also returns a new error code, `403041` (`STOP_ORDER_TRANSACTION_AMOUNT_NOT_AVAILABLE`), when the original transaction amount cannot be determined. For more information, see [Subscription Management](/core-api/subscription-management/) and [Errors](/core-api/errors/).
New transaction type for processing CHAPS credit payments
Marqeta now supports `CHAPS_CREDIT`, a new transaction type for processing Clearing House Automated Payment System (CHAPS) credit payments. This transaction type is available for UK transactions only. UK banks use CHAPS to send same-day payments in British pounds, often for high-value transactions such as property purchases.
Real-Time Decisioning now allows decisioning on card and address verification transactions
Real-Time Decisioning (RTD) now evaluates zero-dollar authorizations, such as card account verification and address verification requests, at the time of the request rather than after the fact. This gives the programs consistent, real-time risk coverage across all authorization types, not just standard purchase authorizations. No action is required from you. This is an automatic enhancement to authorization coverage for existing RTD-enabled programs.
New decline scenario for partially funded cashback transactions
This change applies only to Just-in-Time (JIT) Funding gateway programs. Marqeta now declines the transaction with response code `1875` instead of approving it without the cashback when a JIT Funding gateway partially funds a cashback transaction, such as `authorization.cashback` or `pindebit.cashback`, with an amount that covers the purchase but not the full cashback amount. Cashback cannot be partially approved — it must be fully funded or not included at all. Previously, due to an error in Marqeta's processing, Marqeta silently dropped the cashback amount and approved only the purchase portion, which could create a funding discrepancy between the amount funded by the gateway and the amount settled by the network. Response code `1875` declines now include additional context in the `response.additional_information` field, to distinguish between the following decline reasons. | Scenario | Provided context | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Terminal or card product does not allow partial approval. This is the existing behavior. | "Gateway approved for partial amount but terminal/card product does not allow partial amount" | | Cashback cannot be partially approved according to the card network rules. This is the new behavior. | "Gateway approved for partial amount but cashback cannot be partially approved per network rules" | For example, for a \$100.00 request consisting of an \$80.00 purchase and a \$20.00 cashback amount: | Amount funded by the gateway | Result | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | \$0.01 to \$80.00 | Partial approval for the purchase portion only. Existing behavior, no change. | | \$80.01 to \$99.99 | **New:** Declined with response code `1875`, because the funded amount is more than the purchase amount but less than the full requested amount. | | \$100.00 | Full approval, including cashback. No change. | This change does not affect the existing decline scenario where response code `1875` fires when a JIT Funding gateway partially funds a transaction and the terminal or the card product does not support partial approvals. If the JIT Funding gateway funds the full requested amount of purchase plus cashback, the transaction is approved as before. For more information, see [Transaction Response Codes](/developer-guides/about-transactions#_transaction_response_codes) and [Gateway JIT Funding Messages](/core-api/gateway-jit-funding-messages).

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#_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#_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
Marqeta's Real-Time Decisioning (RTD) 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 Marqeta's fraud models, you can detect suspicious activity more accurately, reduce false positives, recognize trusted merchants, and improve approval rates for legitimate transactions. This data may 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
Marqeta's 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.

Platform release 2026.6.22.0

New features

New response code for terminated cards with reissued replacement
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](/developer-guides/about-transactions#_transaction_response_codes).
New three-of-a-kind weak PIN detection
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
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. 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
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. #### Changed functionality
Fixed: fields not returned on Mastercard STIP transactions
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.

Platform release 2026.6.8.0

New features

Card product-level AFD hold override
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). ### Notable Documentation Changes #### Updated digital banking documentation 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.

Platform release 2026.5.25.0

New features

New JIT Funding method
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#_the_jit_funding_object).
New BIN prefix field in the Transaction object
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#400900%E2%80%93400999-error-codes) page.
New support for interchange adjustment transactions
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 Marqeta's 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).

Platform release 2026.5.11.0

New features

New Pulse transactions risk scores in the Transactions API
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](/core-api/transactions/).
New transaction response code for contactless declines in Canada
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](/developer-guides/about-transactions#_transaction_response_codes).

New features

Changes to network report field names

Marqeta is standardizing network report field names to follow lowercase `snake_case` format consistently. Effective 27 April 2026, Marqeta will update the field names of the following network reports: | Network | Report name | | ---------- | ------------------ | | Visa | VSS Detail SMS Raw | | Mastercard | T112 T464 | | Pulse | EDF | Additionally, unused or deprecated columns will be reserved for future use. For example, the `HASHED_PAN` column in the T112 report will be renamed to `reserved_1`. **Note** This update will initially apply only to new Marqeta customers. Existing Marqeta customers will continue to receive reports with their current field name format until otherwise notified. If your integration relies on header names, you will have to update your header names to match the new standardized format when this change is released to existing Marqeta customers. If your integration relies on column positions, no action will be required. For more details about field mapping for T112 reports, see the T112 file specification.

Platform release 2026.4.27.0

New features

Random PIN generation when creating a new card
Marqeta has added a new boolean value called `use_random_pin` to the`config.poi.other` object in the [Card Products](/core-api/card-products) API. When `use_random_pin` is set to `true`, cards of this card product type will be assigned a random PIN. The default value of this field is `false`.

Platform release 2026.4.13.0

Changed functionality

Fixed: Error and reason code for PIN reveal on inactive cards
An issue has been fixed in this release that caused PIN `/reveal` API requests to return the error `404001` ("Card not found") for existing cards not in an `ACTIVE` state. These API calls will now return a more accurate error - `400985` ("Card is not in an active state"). For more information on Marqeta error codes, see the [Errors](/core-api/errors/) page.

New features

Fraud feedback via two-way SMS

Marqeta now enables cardholders to provide feedback via two-way SMS for transactions that have been flagged as potentially fraudulent by Marqeta's Real-Time Decisioning (RTD) platform. Through the `GENERATE_SMS` supplementary action available in the RTD platform, you can now configure your RTD rules to send a cardholder an SMS to confirm whether a transaction was genuine or fraudulent. Marqeta's RTD system directly receives the cardholder's response. If the cardholder confirms that the transaction was genuine, Marqeta's system will automatically allow the cardholder to retry the transaction within a time window that you can configure in the RTD platform. If the cardholder confirms that the transaction was fraudulent, take appropriate action in accordance with your processes and policies. If you are a current RTD customer, you can contact your Marqeta account manager to enable two-way SMS for your program, starting 1 April 2026.

API rate limiting begins 27 April 2026

Marqeta is implementing API rate limits on Core API requests to the Marqeta platform, in accordance with industry standards. **Enforcement of API rate limits will begin on 27 April 2026.** Starting on this date, any API requests that exceed your applicable program limits will be subject to throttling.
Definition of rate limits
Rate limiting is a control mechanism that restricts the number of API requests or operations that can be performed within a specific time period and applies thresholds to API endpoints, user authentication attempts, and system operations. Rate limits at Marqeta provide enhanced protection against service disruptions and improved overall system availability. They also ensure proper compute and storage resource allocation and a reliable API experience.
Determining rate limits
High-threshold rate limits apply at the program level. Your program will have one aggregated API throughput limit across all Core API calls. Authorization traffic is excluded from the calculation of rate limits. Rate limiting will not impact authorization traffic.
Response when rate limit is exceeded
After 27 April 2026, when your program exceeds the established limit, subsequent API requests will receive an `HTTP 429 (Too many requests)` status code. These requests must be resubmitted once traffic drops below the program limit.
Customer next steps
Marqeta recommends that high-API-volume customers review current API usage and request patterns for your program to prepare for this transition. Your Account Manager can guide you through finalizing the appropriate threshold for your program.
Resources
More information is available in the [Rate Limiting](/core-api/rate-limiting/) guide. If you have any questions or would like to discuss your specific rate limit requirements, contact [Marqeta Support](mailto:support@marqeta.com).

Disputes processing for transaction below program's dispute threshold

To ensure that all disputes are visible and meet regulatory compliance, Marqeta has made it mandatory for customers to raise disputes even if the amount of the transaction does not meet the program's dispute threshold. Previously, programs individually managed these disputes by providing a provisional credit and writing them off. Now, after you raise the dispute, Marqeta automatically issues a provisional credit and the disputes system applies a program write off without submitting the dispute to the card networks. Marqeta, or your program, sends a notification to cardholders that the case was won and closed, depending on who manages the cardholder communications. For customers whose cardholder notifications are not managed by Marqeta, you must implement additional logic to handle the provisional credit webhooks based on the dispute amount. For more information about webhook updates, reach out to your Marqeta representative. See also Marqeta's [Disputes under threshold](/developer-guides/about-disputes/#_disputes_under_threshold) developer guide.

Fraud reporting for account funding transactions

Effective 18 April 2026, Marqeta will require customers to send the `fraud_type_classification` field in `POST /cases` payloads for fraudulent Visa account funding transactions (AFTs) if the `fraud_type` is `MANIPULATION_OF_ACCOUNT_HOLDER`. The `fraud_type_classification` field now accepts the following additional values: * `CHARITY_SCAM` * `HOLIDAY_AND_TICKET_SCAM` * `UTILITY_SCAM` * `LOAN_SCAM` * `PARENT_GRANDPARENT_RELATIVE_SCAM` * `JOB_SCAM` For more information, see [The fraud\_classification\_type\_dispute\_details object](/core-api/disputes-visa/#_the_fraud_classification_type_dispute_details_object).

Platform release 2026.3.30.0

New features

PIN validation fraud check feature flag implementation
Marqeta has created a new fraud-check feature flag. You can use the fraud-check feature when making a PIN change request via a widget to support offline PIN updates. This check was designed to prevent fraudulent transactions when offline PIN verification fails at the terminal and no PIN is present in field `52` of the incoming authorization message. When the feature flag is set to `TRUE`, the system performs an authorization fraud check to verify that the online PIN is present and matches the most recent PIN update made by the cardholder. This validation helps prevent unauthorized card usage by confirming that the PIN entered during the transaction is consistent with the PIN update, ensuring that the legitimate cardholder who possesses the card is conducting both the PIN update and the transaction. If you would like to enable this feature flag for your card program, contact your Marqeta representative.
Copying a PIN to a reissued card
Marqeta now enables you to copy a PIN from a source card to a reissued card by setting the new `copy_pin_from_source_card` field to `true` in the `POST/cards` endpoint. If the previous card has no PIN assigned, the reissued card is created without a PIN, and the `pin_is_set` field is set to `false`. This field can only be used with `reissue_pan_from_card_token` or `new_pan_from_card_token`, not with `translate_pin_from_card_token`. Marqeta also introduces a new error code, `400984`, to indicate that `copy_pin_from_source_card` can only be used with `reissue_pan_from_card_token` or `new_pan_from_card_token`. For more information, see [Create card](/core-api/cards/#post_cards) and [Errors](/core-api/errors/#400900-400999-error-codes).
New transaction types and fields
Marqeta has added two feature-flag-enabled transaction types: * `fee.collection.debit` * `fee.collection.credit` These new transaction types include the following optional payload fields: * `sub_type` - Transaction subtype * `network_metadata.message_reason_code` - Message reason code, as provided by the card network To enable the transaction types and fields listed above for your program, contact your Marqeta representative. Additionally, Marqeta provides a new `cardholder_impact` payload field for all transactions, which indicates whether the transaction impacts the cardholder ledger.
New fields in network reports
Marqeta adds the following new fields to the T112 network reports sent to customers: * `reconciliation_date` - Represents the clearing system's processing date based on the clearing center's local time zone. The date is represented in `YYMMDD` format. * `settlement_date` - Represents the date when the settlement service initiates financial settlement for the transaction. The date is represented in `YYMMDD` format. The reconciliation date and settlement date may sometimes differ. For example, for a transaction processed during a weekend, the reconciliation date will fall on the weekend date, but if the settlement bank is closed during the weekend, the settlement date will fall on the following business day. These fields can help you to better understand the clearing and settlement timelines for Mastercard transactions.

Platform release 2026.3.16.0

The 2026.3.16.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.

Platform release 2026.3.2.0

New features

New flag for card re-issuance
Marqeta now enables you to reissue a card with a new primary account number (PAN) and choose whether to retain or terminate the original source card after the new card is activated. Historically, Marqeta only supported issuing a new PAN in lost or stolen scenarios using the `new_pan_from_card_token` field. In that flow, the source card is immediately terminated once the replacement card is issued. This process remains unchanged and continues to be the recommended approach for lost or stolen cases. Marqeta now enables you to generate a new PAN as part of the standard re-issuance flow using `reissue_pan_from_card_token` by setting `generate_new_pan` to `true`. In this setup, the original card does not have to be terminated immediately and can remain active based on your `activation.actions` configuration. This supports scenarios such as migrating a card from one bank identification number (BIN) to another while keeping the original card active during the transition period. For more information on creating and reissuing cards, see the [Cards](/core-api/cards/) API reference.

Notable documentation changes

Marqeta has added the following pages to our documentation: | Topic | Description | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Rate Limiting | Describes the upcoming implementation of rate limits for Core API requests at Marqeta | | Disputes Evidence Collection | Describes Regulation E evidence collection requirements for Managed by Marqeta (MxM) customers and hybrid card programs and how to submit evidence using the `/cases` endpoint | | Subscription Management | Describes the new Subscription Management feature and associated API |

New features

Dispute case transition webhooks

Marqeta has created webhook events for dispute case transitions, eliminating the need for continuous API polling and enabling real-time notifications for dispute case updates. You can now subscribe to `casetransition.*` events to receive instant notifications when dispute cases change status. The following event types are available under `casetransition.*` events: | Event type | Definition | | --------------------------- | -------------------------------------- | | `open` | Case created | | `open_with_action_required` | Action required | | `ready` | Ready for chargeback submission | | `chargeback.initiated` | Chargeback submitted | | `pending_close` | Temporary state before the case closes | | `closed` | Case closed |

Self-service credential API

Marqeta has added a self-service credential API to the CoreAPI authentication functionality. The self-service credential API allows you to create and manage the admin access tokens that authenticate users of a given application. Using the `self` endpoint, you can create up to 20 admin access tokens per application, manage credential rotation using expiration policies, as well as retrieve and delete admin access tokens. This functionality is currently in limited release. Contact your Marqeta representative if you would like to add it to your program. For further information, see the [Self-Service Credentials](/core-api/self-service-credentials/) page.

Platform release 2026.2.16.0

New card art customization options for Digital Wallet Tokens

Marqeta is enhancing the ability to customize the card art of digital wallet tokens (DWTs). Historically, DWT artwork was limited to the `card_art_id` in the [Card Products API](/core-api/card-products/). With this release, Marqeta enables you to set card art at the card level. To do so, add a `DIGITAL_WALLET_TOKEN_CARD_ART_ID` field to the [Cards](/core-api/cards/) `metadata` object and set your desired card art ID as the value. For any new token provisioning, Marqeta will check the Card `metadata` attributes. If `DIGITAL_WALLET_TOKEN_CARD_ART_ID` is set, it will override the Card Product's `card_art_id` artwork. For existing tokens, the same logic will apply during card lifecycle events such as card swaps and card re-issuance events.

New field in Transactions payload

Marqeta will now include a new field, `reconciliation_cycle`, in the [Transactions](/core-api/transactions/) payload and webhooks for clearing transactions on the Mastercard network. This field represents the reconciliation period within a given reconciliation date, helping improve clarity and alignment with network reconciliation cycles. The `reconciliation_cycle` field will be returned as a two-digit value ranging from `01` to `06`.

Updates to the Funding Sources API

Marqeta has added `GET` functionality to the following Funding Sources endpoints: * `/fundingsources/program` * `/fundingsources/programgateway` To access `GET /fundingsources/program`, you must be assigned the `Read`, `Program Manager`, or `Admin` roles. To access `GET /fundingsources/programgateway`, you must be assigned the `Program Manager`, or `Admin` roles. For more about program funding sources, see [Program Funding Sources](/core-api/program-funding-sources/). For more about program gateway funding sources, see [Program Gateway Funding Sources](/core-api/program-gateway-funding-sources/).

New transaction response code

Marqeta has added a new response code, `1950`, for representment declines. For a full list of transaction response codes, see [Transaction response codes](/developer-guides/about-transactions/#_transaction_response_codes).

New status for Users API

Marqeta has added a new status, `TERMINATED`, to the `GET /users/{token}` endpoint. For more on the `GET /users/{token}` endpoint, see [Retrieve user](/core-api/users/#get_users_token).

New field in Business Transitions webhooks

Marqeta has added a new field, `metadata`, to `businesstransitions` webhooks. This field contains customer-injected metadata associated with the business. For more information on `businesstransitions` webhooks, see [Account holder transition events](/core-api/event-types/#_account_holder_transition_events).

New features

Added support for Mastercard BIN attack flag in 3D Secure requests

In compliance with Mastercard's updated requirements, Marqeta now enables card programs to reject 3D Secure (3DS) transactions that Mastercard has flagged as BIN attacks. When Mastercard flags a transaction as a suspected BIN attack, card programs will receive a 3DS completion webhook with `transaction_reason = NETWORK_SUSPECTED_BIN_ATTACK`. For more information on 3DS webhooks, see [3D Secure transition events](/core-api/event-types/#_3d_secure_transition_events).

New evidence collection requirements for disputes

Marqeta is implementing new evidence collection requirements for dispute events under Regulation E. These requirements vary by program type and are only applicable to programs that are Managed by Marqeta or hybrid. | Program type | Program responsibility | Required evidence | | ----------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Marqeta-managed JIT programs | Program provides money movement evidence; Marqeta handles communications | Documentation for provisional credit grant, reversal, and permanent credit submitted via API or the disputes portal within 3 business days | | Hybrid JIT programs | Program provides both money movement evidence and communication evidence | Documentation for all credit events plus consumer communication records submitted via API or the disputes portal within 3 business days | | Marqeta-managed pre-funded programs | Marqeta handles all evidence collection and communications | No evidence required — monitor dispute events through the disputes portal | | Hybrid pre-funded programs | Program provides communication evidence; Marqeta handles money movement evidence | Consumer communication dates and content for all credit events submitted via API or the disputes portal within 3 business days |

Platform release 2026.1.19.0

The 2026.1.19.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.

Platform release 2026.1.5.0

The 2026.1.5.0 release of the Marqeta platform contains infrastructure improvements and backend issue fixes only. There are no customer-facing enhancements or fixed issues in this release.