April 2026
New features
Changes to network report field names
Marqeta is standardizing network report field names to follow lowercasesnake_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 |
HASHED_PAN column in the T112 report will be renamed to reserved_1.NoteThis 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.
Platform release 2026.4.13.0
Changed functionality
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 page.March 2026
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 theGENERATE_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 guide.If you have any questions or would like to discuss your specific rate limit requirements, contact Marqeta Support.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 guide.Fraud reporting for account funding transactions
Effective 18 April 2026, Marqeta will require customers to send thefraud_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
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 and Errors.New transaction types and fields
Marqeta has added two feature-flag-enabled transaction types:-
fee.collection.debit -
fee.collection.credit
-
sub_type- Transaction subtype -
network_metadata.message_reason_code- Message reason code, as provided by the card network
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 inYYMMDDformat. -
settlement_date- Represents the date when the settlement service initiates financial settlement for the transaction. The date is represented inYYMMDDformat.
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 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 |
February 2026
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 tocasetransition.* 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 theself 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 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 thecard_art_id in the Card Products API. 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 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 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 addedGET functionality to the following Funding Sources endpoints:-
/fundingsources/program -
/fundingsources/programgateway
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. For more about program gateway funding sources, see 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.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.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.January 2026
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 withtransaction_reason = NETWORK_SUSPECTED_BIN_ATTACK.For more information on 3DS webhooks, see 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 |