> ## 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. # March 2026 Card Issuing and Processing Release Notes > Release notes for the Card Issuing and Processing platform in March 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** ## API rate limiting begins 27 April 2026 Action required by: April 27, 2026 Breaking change 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](https://www.marqeta.com/docs/core-api/rate-limiting.md) 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 Action required Breaking change 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](https://www.marqeta.com/docs/developer-guides/about-disputes/#_disputes_under_threshold) developer guide. ## Fraud reporting for account funding transactions Action required by: April 18, 2026 Breaking change 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](https://www.marqeta.com/docs/core-api/disputes-visa/dispute-cases-visa/create-dispute-case-visa.md#_the_fraud_classification_type_dispute_details_object). **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 the Marqeta 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. The Marqeta RTD system directly receives the cardholder's response. If the cardholder confirms that the transaction was genuine, the Marqeta 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. **No customer-facing changes** ## Platform release V.2026.2.16.0 **Sandbox release date:** March 26, 2026 **Production release date:** March 26, 2026 ### 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](https://www.marqeta.com/docs/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](https://www.marqeta.com/docs/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](https://www.marqeta.com/docs/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](https://www.marqeta.com/docs/core-api/program-funding-sources/). For more about program gateway funding sources, see [Program Gateway Funding Sources](https://www.marqeta.com/docs/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](https://www.marqeta.com/docs/developer-guides/about-transactions.md#_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](https://www.marqeta.com/docs/core-api/users/get.md). ### 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](https://www.marqeta.com/docs/core-api/event-types.md#_account_holder_transition_events). ## Related topics - [March 2026 Risk, Fraud, and Disputes Release Notes](https://www.marqeta.com/docs/developer-guides/risk-fraud-disputes-release-notes/2026-03.md) - [March 2026 UX Toolkit Release Notes](https://www.marqeta.com/docs/developer-guides/ux-toolkit-release-notes/2026-03.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)