> ## 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 <release> of the Marqeta platform was rolled back on <date, in d Month YYYY format>. */}

<Update label="June 2026">
  <h3 id="_june_2026_new_features">
    New features
  </h3>

  <div className="release-note-subheading" id="google-unified-push-provisioning-apis"> Google Unified Push Provisioning APIs </div>

  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.

  <div className="release-note-subheading" id="new-message-reason-in-dwt"> New message reason in Digital Wallet </div>

  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).

  <div className="release-note-subheading" id="updated-sub-processor-list"> Updated sub-processor list </div>

  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).

  <h3 id="_platform_release_2026_6_8">
    Platform release 2026.6.8.0
  </h3>

  <h4 id="_2026_6_8_new_features">
    New features
  </h4>

  <div className="release-note-subheading" id="card-product-level-afd-hold-override"> Card product-level AFD hold override </div>

  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.
</Update>

<Update label="May 2026">
  <h3 id="_platform_release_2026_5_25">
    Platform release 2026.5.25.0
  </h3>

  <h4 id="_2026_5_25_new_features">
    New features
  </h4>

  <div className="release-note-subheading" id="new-jit-funding-method"> New JIT Funding method </div>

  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).

  <div className="release-note-subheading" id="new-transaction-object-field-bin-prefix"> New BIN prefix field in the Transaction object </div>

  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.

  <div className="release-note-subheading" id="new-transaction-object-fields-fee-collection"> New support for interchange adjustment transactions </div>

  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).

  <h3 id="_platform_release_2026_5_11">
    Platform release 2026.5.11.0
  </h3>

  <h4 id="_2026_5_11_new_features">
    New features
  </h4>

  <div className="release-note-subheading" id="pulse-transaction-risk-score"> New Pulse transactions risk scores in the Transactions API </div>

  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/).

  <div className="release-note-subheading" id="new-irc-for-canada-contactless-declines"> New transaction response code for contactless declines in Canada </div>

  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).
</Update>

<Update label="April 2026">
  <h3 id="_april_2026_new_features">
    New features
  </h3>

  <h4 id="_changes_to_network_report_field_names">
    Changes to network report field names
  </h4>

  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>
    **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.
  </Note>

  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.

  <h3 id="_platform_release_2026_4_27_0">
    Platform release 2026.4.27.0
  </h3>

  <h4 id="_2026_4_27_new_features">
    New features
  </h4>

  <div className="release-note-subheading" id="_random_pin_generation_when_creating_a_new_card">Random PIN generation when creating a new card</div>

  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`.

  <h3 id="_platform_release_2026_4_13_0">
    Platform release 2026.4.13.0
  </h3>

  <h4 id="_changed_functionality">
    Changed functionality
  </h4>

  <div className="release-note-subheading" id="_fixed_error_and_reason_code_for_pin_reveal_on_inactive_cards">Fixed: Error and reason code for PIN reveal on inactive cards</div>

  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.
</Update>

<Update label="March 2026">
  <h3 id="_march_2026_new_features">
    New features
  </h3>

  <h4 id="_fraud_feedback_via_two_way_sms">
    Fraud feedback via two-way SMS
  </h4>

  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.

  <h4 id="_api_rate_limiting_begins_27_april_2026">
    API rate limiting begins 27 April 2026
  </h4>

  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.

  <div className="release-note-subheading" id="_definition_of_rate_limits">Definition of rate limits</div>

  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.

  <div className="release-note-subheading" id="_determining_rate_limits">Determining rate limits</div>

  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.

  <div className="release-note-subheading" id="_response_when_rate_limit_is_exceeded">Response when rate limit is exceeded</div>

  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.

  <div className="release-note-subheading" id="_customer_next_steps">Customer next steps</div>

  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.

  <div className="release-note-subheading" id="_resources">Resources</div>

  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).

  <h4 id="_disputes_processing_for_transaction_below_programs_dispute_threshold">
    Disputes processing for transaction below program's dispute threshold
  </h4>

  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.

  <h4 id="_fraud_reporting_for_account_funding_transactions">
    Fraud reporting for account funding transactions
  </h4>

  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).

  <h3 id="_platform_release_2026_3_30_0">
    Platform release 2026.3.30.0
  </h3>

  <h4 id="_2026_3_30_new_features">
    New features
  </h4>

  <div className="release-note-subheading" id="_pin_validation_fraud_check_feature_flag_implementation">PIN validation fraud check feature flag implementation</div>

  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.

  <div className="release-note-subheading" id="_copying_a_pin_to_a_reissued_card">Copying a PIN to a reissued card</div>

  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).

  <div className="release-note-subheading" id="_new_transaction_types_and_fields">New transaction types and fields</div>

  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.

  <div className="release-note-subheading" id="_new_fields_in_network_reports">New fields in network reports</div>

  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.

  <h3 id="_platform_release_2026_3_16_0">
    Platform release 2026.3.16.0
  </h3>

  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.

  <h3 id="_platform_release_2026_3_2_0">
    Platform release 2026.3.2.0
  </h3>

  <h4 id="_2026_3_2_new_features">
    New features
  </h4>

  <div className="release-note-subheading" id="_new_flag_for_card_re_issuance">New flag for card re-issuance</div>

  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.

  <h3 id="_notable_documentation_changes">
    Notable documentation changes
  </h3>

  Marqeta has added the following pages to our documentation:

  | Topic                                                                              | Description                                                                                                                                                                    |
  | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
  | <a href="/core-api/rate-limiting/">Rate Limiting</a>                               | Describes the upcoming implementation of rate limits for Core API requests at Marqeta                                                                                          |
  | <a href="/core-api/disputes-evidence-collection/">Disputes Evidence Collection</a> | 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 |
  | <a href="/core-api/subscription-management/">Subscription Management</a>           | Describes the new Subscription Management feature and associated API                                                                                                           |
</Update>

<Update label="February 2026">
  <h3 id="_february_2026_new_features">
    New features
  </h3>

  <h4 id="_dispute_case_transition_webhooks">
    Dispute case transition webhooks
  </h4>

  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                            |

  <h4 id="_self_service_credential_api">
    Self-service credential API
  </h4>

  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.

  <h3 id="_platform_release_2026_2_16_0">
    Platform release 2026.2.16.0
  </h3>

  <h4 id="_new_card_art_customization_options_for_digital_wallet_tokens">
    New card art customization options for Digital Wallet Tokens
  </h4>

  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.

  <h4 id="_new_field_in_transactions_payload">
    New field in Transactions payload
  </h4>

  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`.

  <h4 id="_updates_to_the_funding_sources_api">
    Updates to the Funding Sources API
  </h4>

  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/).

  <h4 id="_new_transaction_response_code">
    New transaction response code
  </h4>

  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).

  <h4 id="_new_status_for_users_api">
    New status for Users API
  </h4>

  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).

  <h4 id="_new_field_in_business_transitions_webhooks">
    New field in Business Transitions webhooks
  </h4>

  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).
</Update>

<Update label="January 2026">
  <h3 id="_january_2026_new_features">
    New features
  </h3>

  <h4 id="_added_support_for_mastercard_bin_attack_flag_in_3d_secure_requests">
    Added support for Mastercard BIN attack flag in 3D Secure requests
  </h4>

  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).

  <h4 id="_new_evidence_collection_requirements_for_disputes">
    New evidence collection requirements for disputes
  </h4>

  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             |

  <h3 id="_platform_release_2026_1_19_0">
    Platform release 2026.1.19.0
  </h3>

  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.

  <h3 id="_platform_release_2026_1_5_0">
    Platform release 2026.1.5.0
  </h3>

  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.
</Update>


## Related topics

- [Release Notes](/docs/developer-guides/release-notes-2025.md)
- [2024 Release Notes](/docs/developer-guides/release-notes-2024.md)
- [2021 Release Notes](/docs/developer-guides/release-notes-2021.md)
- [2022 Release Notes](/docs/developer-guides/release-notes-2022.md)
- [2023 Release Notes](/docs/developer-guides/release-notes-2023.md)