New features
New BIN attack mitigation feature to enhance issuer fraud controls
As part of the continued evolution of our services and our efforts to minimize cardholder fraud, Marqeta is planning to roll out a BIN attack mitigation feature within our Real-Time Decisioning platform in the near future.Our new BIN attack detection capability will leverage real-time transaction data across our issuer network to detect patterns consistent with enumeration or brute-force behavior.Key capabilities include:- Velocity-based triggers, for example, an unusual surge in authorization attempts by BIN
- Automated decline or soft-block logic on merchants experiencing high-risk attempts
- Program-configurable controls to tailor protection thresholds
- Proactive alerts to fraud teams upon detection of BIN attack attempts
New features
New Mastercard chargeback reject code
Marqeta now displays Mastercard’s new chargeback reject code,5002, in the Marqeta Dashboard when a merchant provides compelling evidence that the cardholder had authorized the disputed transaction.For more information on Mastercard disputes, see Managing Mastercard Disputes.New document retrieval button in the Marqeta Dashboard
Marqeta’s disputes system automatically downloads all merchant documents provided in Mastercard’s representments. However, the disputes system does not automatically check for documents that were submitted after the initial representment was filed.To ensure all representments include the required merchant documents, the Marqeta Dashboard now provides a self-serve Retrieve Network Documents button if no documents were submitted in the initial representment. When an agent clicks the button, the disputes system will search Mastercard for any newly added documents, then download them to the Marqeta Dashboard.To get started with the Marqeta Dashboard and explore this new feature, see Dashboard Overview and Quick Start. For more information on representments, see the Representment section of the About Disputes guide.Viewable case notes in the Marqeta Dashboard
Marqeta now allows agents to compose multiple notes that pertain to a specific dispute case. These notes are now viewable in the Marqeta Dashboard.This enhancement is designed to provide you with a comprehensive context of what is happening on a dispute case, allowing you to easily track its progress and submit it accordingly, all without leaving the Marqeta Dashboard.To get started with the Marqeta Dashboard and explore this new feature, see Dashboard Overview and Quick Start.New intake questions for disputed transactions
In accordance with Visa’s network changes, Marqeta has added new disputes questions to the Disputes API and the Marqeta Dashboard:- API users must update their case creation API contracts in order to support these new questions in the intake process.
- Marqeta Dashboard users must collect additional information from cardholders during the intake process. The Marqeta Dashboard has already been updated with the necessary changes.
New field in 3DS SCA challenge result request object
Effective 30 June 2025, Marqeta will add a new optional field calledcard_token to the ThreeDSChallengeResultRequest object. In this field, you can input the Marqeta-assigned unique card token that identifies the card being used.For more information, see the ThreeDSChallengeResultRequest object.New features
Dispute reason codes can be modified in some states
Dispute risk analysts can now modify the dispute reason code when a case is in one of the following states:OpenOpen with action requiredReady(if the case is in theReadystate, move it toOpen, make the change, then move it back toReady)
Note
This update applies to the following dispute types:
This update applies to the following dispute types:
- Integrated: Disputes for which the process is automated and managed through the card network’s system.
- Non-integrated: Disputes for which the process is manually managed by Marqeta.
| Previous Reg Type | Current Reg Type | Requirements and Guidelines |
|---|---|---|
| Regulation | Regulation | Change is allowed; add an entry in the case transition to capture the change. Example: Updating the dispute reason code from 10.3 to 10.4.NOTE: This change applies to both Reg E → Reg E and Reg Z → Reg Z. |
| No Regulation | No Regulation | Change is allowed; add an entry in the case transition to capture the change. Example: Updating the dispute reason code from 13.1 to 13.7. |
| Regulation (with provisional credit) | No Regulation | Change is allowed, but must be treated as a Regulation case, following the milestones for the Regulation-to-Regulation change. Add an entry in the case transition to capture the reason change. Example: Updating the dispute reason code from 10.4 to 13.1.NOTE: The provisional credit must remain unchanged. |
| No Regulation | Regulation | Change is allowed, but must be treated as a Regulation case, following the milestones for the Regulation-to-Regulation change. Add an entry in the case transition to capture the reason change. Follow the regulatory clock, based on the cardholder contact date. Example: Updating the dispute reason code from 13.7 to 10.4.NOTE: Milestones for Regulation disputes are set during case creation only. Because this change occurs after case creation, the Regulation flow must be modified. |
| Regulation (no provisional credit) | No Regulation | Treat changing these disputes like you would a type non-Reg E dispute. A provisional credit has not been granted in this scenario, and you are therefore not restricted to issuing a provisional credit based on the original reason code. You should issue a provisional credit based on the cardholder’s statement and the facts of the case. Milestones for Regulation disputes are set during case creation only. A pre-initiation state change and auth.clearing.chargeback webhooks are sent during case creation.To accommodate the change, you will need to “delete” milestones and “withdraw” the case to reverse the auth.clearing.chargeback webhook that was originally sent. |
| Reg E | Reg Z | Change is allowed, but you must replace the configured milestones. Add an entry in the case transition to capture the reason change. Example: Buy Now, Pay Later (BNPL) transactions. NOTE: Configuration milestones are set during case creation. |
Fraud mitigation for token provisioning
To help mitigate account takeover (ATO) fraud, Marqeta is offering a new enhancement in the identification and verification (IDNV) process during token provisioning. This feature focuses on compliance and security and is available globally.You can now tailor your designated identity verification methods, by disabling specific methods per token provisioning type, to meet your organization’s policies. For example, you can exclude the SMS One-Time Password (OTP) method for manual token provisioning, but keep it active for other provisioning types.Contact your Marqeta representative if you would like to update your IDNV settings for token provisioning. See Provisioning Digital Wallet Tokens for more information about token provisioning.Enhancements
Improved dispute creation experience for Pulse transactions
Marqeta has implemented changes to the Marqeta Dashboard to enhance the dispute creation experience for Pulse transactions.Previously, to create a dispute for a Pulse transaction within the Marqeta Dashboard, users had to select “Other” and input all the relevant information in the “memo” field. Now, users can select the applicable reason codes and input information into the appropriate fields. This change streamlines the dispute creation process and makes it more efficient.To get started with the Marqeta Dashboard and explore these new features, see Dashboard Overview and Quick Start.Dispute intake integration available for additional Visa reason codes
Dispute intake integration is now available for the following Visa reason codes that were previously non-integrated:11.2Declined authorization12.7Invalid data13.4Counterfeit merchandise13.5Misrepresentation13.7Cancelled merchandise/services13.8Original credit not accepted
LEGACY_DISPUTE or OTHER in the Marqeta Dashboard.