> ## 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. # Card Network Certifications 2024 > Learn about the certifications earned by Marqeta for each of the supported card networks. Card Network Certifications are a collection of standards and protocols set by the card networks such as Mastercard, Visa, Pulse, and Discover. These certifications ensure that all transactions processed through these card networks meet their specific requirements, as related to topics including security, data handling, and interoperability. Changes to these certifications are typically communicated through technical documents provided by the card networks to Marqeta four times a year (two major and two minor updates).

October 2024

Visa network certification

The Marqeta platform is certified with the October 2024 VisaNet Business Enhancements, effective 18 October 2024.

Marqeta changes to support this release of Visa

Article AI14466 — Support for new Zimbabwean currency codes

Effective 18 October 2024, Visa supports the new Zimbabwe Gold alpha currency code ZWG and numeric currency code 924. You will see these new currency codes in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests.

Article 2.3 — Mandatory changes to Visa Resolve Online

Effective 19 October 2024, Visa implements mandatory changes to Visa Resolve Online, Release 24.2. VROL Release 24.2 includes mandatory changes to the Disputes rules and questionnaire. * **Changes to Dispute Condition 13.1: Merchandise/Services Not Received**\ Visa updated this dispute category as follows: * Currently, issuers are required to wait 15 calendar days from the date a merchant canceled goods or services before processing a dispute. Visa clarified that the 15-calendar-day waiting period does not apply if the merchant is insolvent or bankrupt. * To remove confusing requirements for disputes where the merchandise was delivered to an incorrect location, Visa no longer requires confirmation that the cardholder attempted to return the merchandise. Issuers must still provide the date the cardholder returned (or attempted to return) the merchandise if the merchandise was delivered late. * For disputes related to non-receipt of travel services from a provider that is insolvent or bankrupt in the Europe region: If the services are covered by a bonding authority or insurance scheme, the cardholder or traveler (or the issuer on behalf of the cardholder or traveler) must attempt to obtain reimbursement from the relevant bonding authority or insurance scheme. Visa requires the issuer to provide details of the advice or guidance that was given to the cardholder or issuer by the bonding authority or insurance scheme during the attempt for reimbursement. * For airline transactions, when responding to a dispute, Visa has clarified that the acquirer must supply evidence to show that the flight departed if the cardholder is disputing that the flight did not take place. * For disputes related to future services, when responding to a dispute, Visa has clarified that the acquirer must supply evidence to show that the merchant did not cancel, and that the services were available. * **Changes to Dispute Condition 13.3: Not as Described or Defective Merchandise/Services:**\ Effective in all regions for disputes processed on or after 19 October 2024, the cardholder must return the merchandise or cancel the services. Visa requires issuers to include one of the following reasons for why the return was unsuccessful when processing a dispute. An attempt to return is only valid when the merchant: * Refused the return of merchandise * Refused to provide a return merchandise authorization or label * Instructed the cardholder not to return the merchandise * No longer exists or is not responding to the cardholder * Did not provide clear instructions on how to return the merchandise The following table summarizes the changes to the questionnaire: | Reason Code | Questionnaire Changes | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `11.x` | The new question "What is the status of the account?" is required for `11.x Authorization` disputes. Valid responses to this question are:

- **AC:** Account Closed
- **CP:** Credit Problem
- **F:** Fraud | | `12.1` | Effective 19 October 2024, the dispute reason code `12.1 Late presentment` is no longer supported. Late presentment is dropped from the processing error disputes category. You must route late presentments as `11.3` disputes. | | `12.6` | The question "Did the cardholder attempt to resolve the dispute with the merchant?" is now required for all `12.6 paid by other means` disputes. | | `13.1` | The new question "Is merchant in bankruptcy/liquidation?" is required for `13.1 Non-receipt of merchandise/services` disputes. Valid responses are "Y" and "N."

The new question "Was the merchandise delivered late?" is required if the response to "What was not received?" is "Merchandise." Valid responses are "Y" and "N."

The new question "Was non-fiat currency or non-fungible token(s) not successfully delivered to the destination wallet address supplied by the cardholder at the time of the transaction?" is required when "What was not delivered?" is "Services." Valid responses are "Y" and "N."

The field "Provide the address of the agreed location or details of the late delivery:" is displayed and required if the response to either "Was the merchandise delivered late or to the wrong location?" or "Was the merchandise delivered to the incorrect location?" is "Y."

The question "Did the cardholder return the merchandise?" is required when the response to "Was the merchandise delivered late?" is "Y." Valid responses are "Y" and "N." | | `13.2`
`13.3`
`13.7` | For `13.2 Cancelled recurring transactions`, `13.3 Not as described/defective/quality`, and `13.7 Cancelled merchandise/services` disputes, you must include text asking the agent to provide supporting evidence when initiating prearbitration. | | `13.3` | For `13.3 Not as described or defective merchandise/services` disputes, the new question "Was non-fiat currency or purchase of non-fungible token(s) (NFT), the non-fiat currency or non-fungible token received by the cardholder did not match the description provided at the time of the transaction?" is required if the response to "Not as described" and "What was not received?" is "Services." Valid responses to this question are "Y" and "N."

New allowable responses for "Provide certification of one of the following" are included when the response to "Not as described" and "What was not received?" is "Merchandise" and the response to "Did cardholder attempt to return?" is "Y." The allowable responses under these conditions are:

- **MNLER:** Merchant no longer exists or is not responding
- **MNPCIR:** Merchant did not provide clear instructions on how to return | | `13.3`
`13.7`
`13.5` | For `13.3 Not as described or defective merchandise/services`, `13.7 Cancelled merchandise/services`, and `13.5 Misrepresentation` disputes, a question has changed from "Provide a detailed description of how the cardholder attempted to return and the disposition of the merchandise" to "Provide a detailed description of how the cardholder attempted to return merchandise."

A new field "What is the disposition of the merchandise?" is displayed and required if the response to "Did the cardholder attempt to return the merchandise?" is "Y." The field for this response supports 5000 characters maximum. |

Article 2.9 — Changes to support Payment Fraud Disruption blocking

Effective 18 October 2024, Visa implements a new feature that allows issuers to unblock a primary account number (PAN) that has been blocked by the Payment Fraud Disruption service. To support this mandate, Marqeta will create a process for you to follow to unblock PANs. Development of this feature is still ongoing. This note will be updated with more detail when development is complete.

Article 2.14 — New interregional and regional fee programs for account funding transactions

Effective 18 October 2024, Visa introduces new interregional and regional fee programs for certain money transfer account funding transactions in the Asia-Pacific (AP), Central Europe, Middle East, and Africa (CEMEA), and Latin America and Caribbean (LAC) regions. To support this mandate, Marqeta adds the following new account funding transaction types: `AFT_OR_OCT_ELIGIBILITY`, `CONSUMER_BILL_PAYMENT`, `REQUEST_TO_PAY`. For more information about account funding transaction types, see [Transactions](/core-api/transactions/).

Article 3.2 — Changes to support new data requirements in Visa Direct transactions

Effective 18 October 2024, Visa implements changes to support new enhancements in account funding transactions and original credit transactions. To support this mandate, Marqeta now includes the `account_owner` and `payment_facilitator` objects in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. In addition to these new objects, Marqeta now includes the following new fields in the `acquirer` object in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests: * `city` * `country_code` * `merchant_street_address` * `name` * `postal_code` * `state` * `street_address` For more information on these new objects and fields, see [Transactions](/core-api/transactions/).

Article 3.4 — Changes to support cross-border account funding transactions

Effective 18 October 2024, Visa implements changes to require certain sender and recipient data for cross-border money transfer account funding transactions to contain the business application identifier value of `WT` (Wallet Transfer). You will see this sender and recipient data in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests.

Article 3.7 — Changes to Visa Token Service issuer notifications to support the issuer On Behalf Of Credential Update Service

Effective 18 October 2024, Visa implements changes to the V.I.P. System to identify issuer token notification messages for expiration date updates to primary account numbers (PANs) and e-commerce and card-on-file tokens that are originated by the Issuer On Behalf Of (OBO) Credential Update Service. Visa’s OBO Credential Update Service enhances authorization rates by updating PAN and token credentials and thus avoiding declines due to expired payment credentials. Visa now differentiates between PAN and token credentials that were updated using the OBO Service rather than issuer-initiated updates. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 3.9 — Changes to support Visa Secure authentication data quality requirements

Effective 18 October 2024, Visa implements a new tag to indicate that a transaction does not meet the Visa Secure authentication data quality requirements. To support this mandate, Marqeta now includes the `three_ds_data_quality` field in the `cardholder_authentication_data` object in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. The possible values for this field are `SUFFICIENT_DATA` and `INSUFFICIENT_DATA`.

Article 3.11 — Requirements to support Visa Secure Smart Attempts service for Visa Secure issuers

Effective 18 October 2024, Visa implements changes to add support for the new Visa Secure Smart Attempts service processing. Visa sends a new value in the authorization message if the transaction is low risk and below low payment amount thresholds, as defined by Visa on behalf of the issuer in one of the following conditions: * The issuer’s access control server (ACS) is unavailable * The issuer’s account is not enrolled in Visa Secure * An ACS is not defined for a given account range To support this mandate, Marqeta now includes the 3D Secure indicator value `FRICTIONLESS_SMART_ATTEMPTS` in the `3ds_authentication_method` object in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. For more information about the 3D Secure indicator value, see [Transactions](/core-api/transactions/).

Article 3.21 — Changes to support a new Business Application Identifier for account funding transactions and original credit transactions

Effective 18 October 2024, Visa implements changes to support a new Business Application Identifier value for account funding transactions and original credit transactions. To support this mandate, Marqeta adds the new account funding transaction types `LIQUID_ASSET`. For more information about account funding transaction types, see [Transactions](/core-api/transactions/).

Article 4.5 — Introduction of Tap to Add Card

Effective 18 October 2024, Visa is introducing a new service called Tap to Add Card, which extends the Visa Chip Authenticate Service to token provisioning from wallet apps on mobile devices. Issuers that choose to participate in the new service will be able to differentiate Tap to Add Card provisioning requests from other types of provisioning requests. Issuer participation is optional, but only issuers that participate will have the credential chip data validated during token provisioning originated with Tap to Add Card. When using Tap to Add Card, cardholders are prompted to tap their cards, and then are prompted to manually enter the CVV2 value. Visa does not attempt to authenticate the EMV application cryptogram. The cryptogram and the data used to create the cryptogram are not forwarded to the issuer.

Visa changes with no impact on your card program

Article 1.5 — Requirements to support the Address Verification Service

Effective 18 October 2024, Visa requires issuers in Canada, including all provinces and territories, and all remaining European countries to support the Address Verification Service. Marqeta already supports the Address Verification Service globally, and performed no additional development to support this mandate.

Article 2.13 — Expansion of the Visa Direct Strategic Fee Program to cross-border and European domestic transactions

Effective 18 October 2024, Visa implements changes to allow cross-border and Europe domestic Visa Direct account funding transactions and original credit transactions to qualify for the Visa Direct Strategic Fee Program. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 2.15 — Changes to merchant category codes

Effective 18 October 2024, Visa implements changes to support a new merchant category code: `MCC 3840: Rio Hotels`. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 2.16 — Changes to enabler verification value field

Effective 18 October 2024, acquirers are required to support the enabler verification value (EVV). In addition, Interlink issuers may choose to support the EVV. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 2.17 — Enhancements to support global processing alignment for issuers

Effective 18 October 2024, Visa introduces a new Authorization Characteristics Indicator value. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 3.10 — Changes to support Visa Chip Authenticate for account verification

Effective 18 October 2024, Visa implements changes to the Visa Chip Authenticate service to support online card authentication method validation for account verification request messages in the Canada, Latin America and Caribbean (LAC), and U.S. regions. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 3.13 — Changes to Type of Purchase field in fuel transactions

Effective 18 October 2024, Visa is implementing changes to support fuel transactions that involve multiple fuel codes. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 3.20 — Requirements to support extended clearing and maximum processing dates

Effective 31 May 2024, Visa implemented changes to support an expected clearing date to allow participating acquirers and issuers to receive the Visa-derived maximum processing date. This change allows acquirers to request an extension of up to 30 days to the authorization clearing period for certain cardholder-initiated card-not-present transactions. It also allows issuers to receive the extended authorization request. When an acquirer requests an extended authorization clearing, Marqeta allows for an extended authorization period of up to 30 days for clearing to take place. Effective 18 October 2024, Visa introduces the `maximum_processing_date` field. This field indicates the date by which the extended authorization must clear. The field is populated by Visa before an authorization request is sent to the issuer, and will be returned to the acquirer in the authorization response.

Article 5.2 — Improvements and modifications to VisaNet Business Enhancement Release

Visa is making a concerted effort to improve the VisaNet Business Enhancements Release process for major releases in April and October, and the minor releases in January and July. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 5.3 — Changes to TLV field article placement and best practice

Effective with the April 2024 release, Visa announced changes to the VisaNet Business Enhancements Global Technical Letter and Implementation Guide with regard to the new structure and placement of the tag-length-value (TLV) V.I.P. fields and their contents. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 5.4 — Enhancements to VisaNet documentation

Visa continues the ongoing process of modernizing the payments industry terminology used in the VisaNet technical specification manuals. Endpoints should continue to expect to see terminology changes as new versions of the VisaNet Technical manuals are released in 2024. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 7.2.2 — Update to interchange fee processing for Canadian domestic transactions from Consumer Bill Payment Service providers

Effective 18 October 2024, Visa implements changes to allow Canadian domestic Consumer Bill Payment Service transactions to qualify for any applicable fee program. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 7.4.1 — Changes to Visa Secure to support the Digital Authentication Framework in Canada

Effective 18 October 2024, issuers in the Canada region that participate in EMV 3D Secure may optionally participate in the Visa Secure Digital Authentication Framework program. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 9.3.2 — Changes to support back-to-back account funding transactions

Effective 18 October 2024, Visa implements a new indicator to identify back-to-back funding transactions on a general purpose card as account funding transactions in the European Economic Area countries and United Kingdom, including Gibraltar. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 9.4.1 — Expansion for Visa Prepaid Workplace Benefits product in the European region

Effective 18 October 2024, Visa implements changes to provide the expanded Visa Workplace Benefits product for prepaid domestic purchase transactions in the European region. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 11.2.1 — Changes to the Business Card — Level 2 fee program for transactions from fleet and fuel merchants

Effective 18 October 2024, Visa updates the fee edit criteria requirements for the existing Business Card — Level 2 fee program to incorporate a new value in the Type of Purchase field. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 11.2.2 — Changes to Visa Corporate and Visa Purchasing Fee Programs for transactions from fleet and fuel merchants

Effective 18 October 2024, Visa changes the fee edits that apply to Visa Corporate and Visa Purchasing (including fleet) credit purchase transactions with fuel data from fleet and fuel merchants. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 11.2.4 — Introduction of the Visa Direct Strategic fee program

Effective 18 October 2024, Visa implements changes to allow U.S. domestic Visa Direct account funding transactions and original credit transactions to qualify for the Visa Direct Strategic fee program. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 11.2.6 — New U.S. domestic Visa+ original credit transaction client-to-client fee program

Effective 18 October 2024, Visa implements a new U.S. domestic client-to-client fee program, including fee descriptor, fee program indicator, and rate for Visa+ original credit transactions. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 11.2.7 — Update to interchange fee processing for U.S. domestic transactions from Consumer Bill Payment Service providers

Effective 18 October 2024, Visa implements changes to allow U.S. domestic Consumer Bill Payment Service (CBPS) transactions to qualify for non-CBPS interchange fee programs. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article 11.2.8 — New private bilateral agreement program

Effective 18 October 2024, Visa introduces a new private bilateral agreement program. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Mastercard network certification

The Marqeta platform is certified on Mastercard Release 24.Q2, effective 18 October 2024.

Marqeta changes to support this release of Mastercard

GLB 8411.1 — Introducing an indicator for multi-use virtual cards

Effective 5 November 2024, Mastercard is introducing the ability to identify consumer multi-use virtual card numbers not generated by Mastercard on Account Status Inquiries. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

GLB 8418.1 — Introducing a MoneySend payment transaction type identifier and modifying the Send Blocking Service

Effective 5 November 2024, Mastercard is introducing the `FAST_REFUND` transaction type identifier for MoneySend Fast Refunds to original card payment transactions. You will see this transaction type in the `original_credit` object in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. Marqeta has completed the development work required for the Send Blocking Service modification, although the changes are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions related to the Send Blocking Service modification.

GLB 8431.1 — Introducing geographic coordinates data fields

Effective 18 October 2024, Mastercard is introducing geographic coordinates for the acceptor and service location to enhance the value and transparency of transaction data. To support this mandate, Marqeta now includes two new fields in the `card_acceptor` object: `geographic_coordinates` and `service_geographic_coordinates`. You will see these fields the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests.

GLB 9971.1 — Enhancing processing for Mastercard Installments Program with merchant participation in Australia

Effective 18 October 2024, Mastercard is enhancing authorization and clearing messages to include a Mastercard Assigned ID for qualified installment transactions where the merchant has agreed to participate in the Mastercard Installments Program in Australia. You will see this value in the `network_assigned_id` field in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests.

GLB 10225.1 — Support for new Zimbabwean currency codes

Effective 18 October 2024, Mastercard supports the new Zimbabwe Gold alpha currency code ZWG and numeric currency code 924. You will see these new currency codes in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests.

Mastercard changes with no impact on your card program

AN 7723 — Modifying Account Level Management Service data participation requirements

Effective 5 November 2024, Mastercard is modifying the population of Account Level Management Service Data on all qualifying transactions. You no longer need to opt-in to receive the ALM Service Data in qualifying authorization and clearing messages. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

AN 8402 — Enhancing processing to support the Qualified Small Businesses Interchange Program in Canada

Effective 18 October 2024, Mastercard is enhancing its clearing processing to validate transaction compliance for consumer credit interchange programs participating in the Canada region’s Qualified Small Businesses Interchange program. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

GLB 8403.2 — Limiting PAN exposure in tokenized transactions

Effective 16 October 2024, Mastercard is further protecting cardholders by limiting exposure to the Primary Account Number (PAN) in the acceptance environment for tokenized transactions by limiting exposure to the full PAN. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

GLB 8414.2 — 24.Q4 miscellaneous core system updates

This announcement describes the miscellaneous core system changes that occur with Release 24.Q4. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

GLB 8405.1 — Repurposing a data element

Effective 5 November 2024, Mastercard is repurposing the previously reserved data element `119`. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

GLB 8410.1 — Enhancing processing for consumer non-reloadable prepaid products

Effective 18 October 2024, Mastercard is enhancing processing for consumer non-reloadable prepaid products by ensuring that merchant advice codes are present in financial transaction request response messages. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

GLB 9921.1 — Assigning and repurposing leading indicators to the Accountholder Authentication Value

Effective 18 October 2024, Mastercard is assigning the leading indicator `kW` and repurposing the leading indicator `kG` to the Accountholder Authentication Value (AAV) suite of values. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

US 8424.1 — Validating Business Service Arrangement in the U.S.

Effective 18 October 2024, Mastercard is ensuring the Business Service Arrangement (BSA) transaction qualification criteria for BSA levels one and two correspond with the interchange rate designators in the U.S. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Discover network certification

The Marqeta platform is certified with the October 2024 Discover Release 24.2, effective 18 October 2024.

Marqeta changes to support this release of Discover

Article II — New merchant category code

In accordance with applicable law, the new merchant category code `MCC 5723: GUN AND AMMUNITION STORE` was made available as of 1 July 2024. The use of this MCC on our networks is acceptable where permitted or required by law, and shall not be used where prohibited. All transactions submitted to Discover must comply with all applicable laws and regulations. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Article VII — Updated debt repayment requirements

Effective 18 October 2024, Discover no longer requires a separate Discover Merchant Number for debt repayment. Additionally, Discover introduces a new debt repayment transaction indicator. These changes, which ensure industry alignment and promote acceptance growth, will be effective with Release 25.1 on 11 April 2025. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

Pulse network certification

The Marqeta platform is certified on Pulse Release 24.2, effective 18 October 2024.

Marqeta changes to support this version of Pulse

Enhanced data file version

Effective 18 October 2024, Pulse migrates enhanced data file (EDF) version 242 to the production environment. Processors that currently receive the EDF, and plan to upgrade to either the optional or mandated file, are required to initiate a project with their Pulse Relationship Manager. Marqeta has completed the development work required for this mandate, although the modifications are not visible to you. There are no changes to how you interact with the Marqeta platform or how you handle transactions.

April 2024

Visa network certification

The Marqeta platform is certified with the April 2024 VisaNet Business Enhancements, effective 12 April 2024.

Marqeta changes to support this release of Visa

Article AI13324 — Merchant Value-Added Tax registration identifier

Effective 24 March 2024, Visa provides the Merchant Value-Added Tax (VAT) Registration/Single Business Reference Number in authorization and clearing transactions originating in Belgium, France, and Luxembourg. Visa implemented this change to promote the benefits of paying with Visa, to streamline operating processes, and to provide a better payment experience to cardholders and Visa issuers when transactions are processed on VisaNet. When Marqeta receives this value from the Visa card network, you can find it in the `merchant_vat_registration_id` field in the transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. To parse and save this value in your system for use in your business processes, update your webhook logic to read the value from the `merchant_vat_registration_id` field. For more information about this field, see the [Transactions](/core-api/transactions/#get_transactions_token) API reference.

Article 1.1 — Support for Account Name Inquiries

Effective 12 April 2024, Visa mandates that all issuers support Account Name Inquiry (ANI) for all programs. To support this mandate, Marqeta offers a new account verification feature called Account Name Inquiry (ANI). This feature lets acquirers and originators verify that the name users are providing during card registration matches the name associated with the card on file at the card issuer side before performing any transactions using that account. The ANI feature helps reduce fraud and chargebacks, manage risk, and optimize initial and recurring transaction approvals. Marqeta’s ANI feature includes the following highlights: * Visa sends non-financial ANI requests to Marqeta. * JIT Funding and webhook requests include ANI data if you choose to participate in the ANI decision-making process. * JIT Funding requests include the account name Marqeta received from the card network and Marqeta’s proposed match, enabling you to send a response that either confirms or overwrites the proposed account name. * Webhooks inform you of the ANI result provided to Visa by Marqeta. To enable the ANI feature for your program, contact your Marqeta representative. For more information about the ANI feature, see [About Account Name Inquiry](/developer-guides/account-name-inquiry/) and [Using ANI with JIT Funding](/developer-guides/using-ani-with-jit-funding/).

Article 1.4 — Extended authorization and expected clearing date

Effective 12 April 2024, Visa mandates support for extended authorization. This change allows acquirers to request an extension of up to 30 days to the authorization clearing period for certain cardholder-initiated card-not-present transactions. It also allows issuers to receive the extended authorization request. This mandate will be fully implemented in the October Visa platform release.

Article 2.3 — Mandatory changes to Visa Resolve Online

The Marqeta platform supports VisaNet Business Enhancement article 2.3, which implements Visa Resolve Online (VROL) version 24.1. VROL version 24.1 includes mandatory changes to the Disputes codes and questionnaire. Effective 13 April 2024, VROL no longer supports dispute reason code `12.1 Late presentment`. Your program must now submit late presentment disputes using code `11.3 No authorization`. The following table enumerates the changes to the questionnaire: | Reason Code | Questionnaire Changes | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `10.x Fraud` | Dispute reason codes `10.1`, `10.2`, `10.3`, and `10.4` now include an optional "Fraud Type Classification" for Account Funding Transactions (AFT). | | `12.6 Duplicate transactions/Paid by other means` | If the response to the question "Are both transactions for the same merchant and on the same card?" is "Y," then the primary account number (PAN) for the original transaction and the transaction being disputed must match.

If the PAN does not match, Marqeta smart rejects the dispute and moves the dispute to the **Open with Action Required** state. Marqeta specifies the reason for the smart rejection in the webhook payload. | | `13.1 Merchandise/Services not received` | An response to the question "Does the dispute involve a Visa Commercial Card Virtual Account?" is required for the following commercial card products:

- **X1**: Visa B2B Virtual Buyer Enablement Program
- **S1**: Visa Purchasing with Fleet
- **S4**: Visa Commercial Agriculture
- **S5**: Visa Commercial Transport
- **G**: Visa Business
- **K**: Visa Corporate T\&E
- **S**: Visa Purchasing
- **X**: Visa B2B Virtual Payments | | `13.2 Cancelled recurring transactions` | For European card issuers, if the transaction occurs outside the EU region, then an response to the question "Is this dispute impacted by local law/regulation?" is required.

- If the response is "Yes", then you must include a note or an attachment specifying the local law or regulation.
- If the response is "No", then you must include one of the following dates:

- "Date cardholder withdrew permission to charge the payment credential"
- "Date issuer informed merchant of account closure" |

Article 3.5 — Mandate to support expansion of partial authorizations in transactions

Effective 12 April 2024, Visa mandates that acquirers and issuers in certain countries support partial authorization for additional merchant category codes (MCCs) for debit and prepaid card products in domestic and cross-border transactions. Partial authorizations reduce insufficient fund declines and are intended to enhance the cardholder and merchant experience at the point of sale. They provide an alternative to a declined transaction when the available Visa card or account balance is not sufficient to approve a transaction in full. Rather than declining a transaction, the transaction can be approved for a portion of the original amount requested, optimizing approval rates. To support this mandate, Marqeta allows partial authorizations for the following MCCs: | MCC | Description | | ---- | ------------------------------------------------------------------ | | 4121 | Taxicabs and Limousines | | 5399 | Miscellaneous General Merchandise | | 5411 | Grocery Stores and Supermarkets | | 5499 | Miscellaneous Food Stores—Convenience Stores and Specialty Markets | | 5541 | Service Stations (with or without ancillary services) | | 5542 | Automated Fuel Dispensers | | 5552 | Electric Vehicle Charging | | 5812 | Eating Places and Restaurants | | 5814 | Fast Food Restaurants | | 5912 | Drug Stores and Pharmacies | | 5999 | Miscellaneous and Specialty Retail Shops | Partial authorizations are supported in the following regions: | Region | Description | | --------------------------- | -------------------------------------------------------------------------------------------------------- | | Asia-Pacific | All countries, excluding Hong Kong, Indonesia, Japan, Korea, Macau, Mainland China, Taiwan, and Thailand | | Canada | All provinces and territories | | Europe | All countries | | Latin America and Caribbean | All countries, excluding Colombia, Haiti, Mexico, Uruguay, and Venezuela | | United States | All states and territories |

Article 3.6 — Mandate to support partial authorizations in account funding transactions

Effective 12 April 2024, Visa mandates that issuers receiving account funding transactions (AFTs) in the Asia-Pacific (AP) region; Canada; Central Europe, Middle East, and Asia (CEMEA) region; Latin America and Caribbean (LAC) region; and the United States must support partial authorization on all domestic and cross-border AFTs. Partial authorizations reduce insufficient fund declines and are intended to enhance the cardholder and merchant experience at the point of sale. They provide an alternative to a declined transaction when the available Visa card or account balance is not sufficient to approve a transaction in full. Rather than declining a transaction, the transaction can be approved for a portion of the original amount requested, optimizing approval rates.

Visa changes with no impact on your card program

Article 2.5 — New merchant category codes

To support this article, the Marqeta platform recognizes the following new merchant category codes (MCCs): | MCC | Description | | ---- | ------------------------- | | 3168 | Hainan Airlines | | 5723 | Gun and Ammunition Stores |

Mastercard network certification

The Marqeta platform is certified on Mastercard Release 24.Q2, effective 12 April 2024.

Marqeta changes to support this release of Mastercard

AN 7102 — Mastercard transaction link identifier

Effective 4 June 2024, Mastercard introduces the Transaction Link Identifier (TLID), a new Mastercard-generated identifier used identically across the authorization, clearing, and single-message system platforms, as well as across all message specifications. The purpose of the TLID is to link all related messages together via a single transaction-level identifier that is simple to use and sustainable for the future, without the risk of duplication or discrepancies. The TLID is designed to help ensure globally unique transaction identification and provide a means to track a transaction across multiple stages through time. This announcement provides advance notice about forthcoming card network changes to allow Marqeta time to conduct impact analysis. Prior to the 4 June 2024 date, Marqeta only parses the TLID value and echoes it back in the response.

AN 7402 — Account Status Inquiry enhancement to support name validation

Effective 12 April 2024, Mastercard mandates that all issuers support Account Status Inquiry (ASI) for all programs. To support this mandate, Marqeta offers a new account verification feature called Account Name Inquiry (ANI). This feature lets acquirers and originators verify that the name users are providing during card registration matches the name associated with the card on file at the card issuer side before performing any transactions using that account. The ANI feature helps reduce fraud and chargebacks, manage risk, and optimize initial and recurring transaction approvals. Marqeta’s ANI feature includes the following highlights: * Mastercard sends non-financial ANI requests to Marqeta. * JIT Funding and webhook requests include ANI data if you choose to participate in the ANI decision-making process. * JIT Funding requests include the account name Marqeta received from the card network and Marqeta’s proposed match, enabling you to send a response that either confirms or overwrites the proposed account name. * Webhooks inform you of the ANI result provided to Visa by Marqeta. To enable the ANI feature for your program, contact your Marqeta representative. For more information about the ANI feature, see [About Account Name Inquiry](/developer-guides/account-name-inquiry/) and [Using ANI with JIT Funding](/developer-guides/using-ani-with-jit-funding/).

AN 7569 — Advanced digital transaction data for remote commerce transactions

Effective 12 April 2024, Mastercard introduces new data elements that include information related to consumer devices and transactions. This data may be collected from merchants or digital wallets during remote commerce token transactions that qualify under the Token Authentication Framework (TAF). Marqeta passes these data elements in the `user.metadata` field of the JIT transaction payload for better authorization decisioning, as well as in webhooks for analytical purposes.

AN 7705 — Enhanced Identity Check Program

Effective 4 June 2024, Mastercard enhances their Identity Check program with two new Merchant Advice Code (MAC) verification Account Authentication Values (AAVs). To support this new mandate, Marqeta passes these new fields in the `cardholder_authentication_data.verification_result` object: * `not_verified_mac_key_validation_passed` * `not_verified_mac_key_validation_failed` These fields indicate that a transaction passed or failed MAC key validation, but was not verified due to card network connectivity issues. For detailed information on these new fields, see the [Transactions](/core-api/transactions/#get_transactions_token) API reference.

AN 7713 — New enumerated value for high-risk securities

Effective 12 April 2024, Mastercard introduces the following changes: * The Gaming and Gambling Payments Program includes an indicator to provide information to originating institutions about the receiving institutions' posting speed when processing payment transactions. This change has no impact on Marqeta. * Expanded merchant category codes (MCCs) for the Mastercard Funding Transactions Program. Marqeta already supports these changes. * Inclusion of a new transaction purpose value for high-risk securities to Data Element (DE) 108 (Additional Transaction Reference Data), subelement 03 (Transaction Reference Data), subfield 05 (Transaction Purpose). These changes expand availability of the program for originating institutions and their customers where the primary activity is the sale of cryptocurrency, gaming or gambling, and securities or high-risk securities, providing greater transparency for funding issuers. To support this change, Marqeta has added an enumerated value to support the new value of `16` (High Risk Securities) in the existing Field 108.03.05. This value is handled in the same way as any other value currently received in this field. There are no changes to transaction processing when this value is received.

AN 7776 — New authentication programs for Canada and the United States

Effective 26 June 2024 for Canada and 27 January 2025 for the United States, Mastercard introduces the Token Authentication Framework (TAF) and Identity Check Express (IDCX) authentication programs. These initiatives are designed to provide merchants, payment service providers, and commerce platforms with enhanced control over the consumer experience, while safeguarding against fraud. To support this change, Marqeta passes data element (DE) 104 (Digital Payment Data) in the JIT payload and webhooks. The Token Authentication Framework authentication program: * Applies to remote-commerce token transactions using Mastercard Secure Card on File (SCOF) specifications. * Ensures merchant fraud liability protection for compliant tokenized transactions in Canada. The Identity Check Express authentication program: * Applies to remote-commerce transactions for EMV® 3D Secure (3DS) enabled merchants. * Maintains merchant fraud liability protection when issuers authenticate using EMV 3DS through Identity Check. Card issuers participating in the Mastercard Digital Enablement Service (MDES) in Canada and the United States must process remote-commerce tokenized transactions using Mastercard SCOF specifications authenticated using TAF. When in compliance with both program and merchant participation requirements, merchants are eligible for fraud liability protection on tokenized transactions under the TAF in Canada. Be aware that a Security Level Indicator (SLI) value of 242 in the authorization message indicates a non-disputable transaction. You may also see increased usage of the electronic commerce indicator (such as `electronic_commerce_indicator: authentication_successful`) for all transactions.

Mastercard changes with no impact on your card program

AN 7703 — Enhanced authorization data for remote commerce transactions

Effective 12 April 2024, Mastercard enhances single- and dual-message systems to insert authentication data in select tokenized remote commerce authorization and financial transaction requests and response messages when the authentication data was not originally provided by the acquirer. There is no change to the Marqeta platform to support this enhancement.

AN 7708 — New reason code for first presentment messages

Effective 12 April 2024, Mastercard adds two new reason code values for use in First Presentment reversal messages: * Invalid data previously supplied: `1451 Incorrect transaction parameters` * Duplicate transaction: `1452 Duplicate transaction` These new values provide issuers with pertinent information regarding the reason for the reversal of a previously submitted clearing message, such as when a previous reversal contained invalid data, or if the previous reversal was a duplicate. There is no change to the Marqeta platform to support these changes.

Discover network certification

The Marqeta platform is certified on Discover Release 24.2, effective 12 April 2024.

Marqeta changes to support this release of Discover

Digital currency acceptance

Effective 12 April 2024, Discover supports Discover Debit Digital Currency, which is identified with an indicator if a transaction was made to purchase digital currency such as cryptocurrencies, stablecoins, and central bank digital currencies. Marqeta parses the indicator sent by the acquirer to identify these types of transactions.

Pulse network certification

The Marqeta platform is certified on Pulse Release 24.1, effective 12 April 2024.

Marqeta changes to support this release of PULSE

Digital currency acceptance

Effective 12 April 2024, PULSE supports Discover Debit Digital Currency, which is identified with an indicator if a transaction was made to purchase digital currency such as cryptocurrencies, stablecoins, and central bank digital currencies. Marqeta parses the indicator sent by the acquirer to identify these types of transactions.

January 2024

Marqeta changes to support Mastercard

AN 2630 — Mastercard Trace ID

Mastercard supports the use of Trace ID to reference the first authorization for recurring payment transactions and merchant-initiated transactions in support of Payment Service Directive 2 Regulatory Technical Standards (PSD2 RTS) Article 14 in the European Economic Area. This change enables acquirers and issuers to provide the Trace ID from the initial authorization in recurring payment transactions, partial shipment e-commerce transactions, installment payments, and other merchant-initiated transactions. PSD2 RTS Article 14 requires that issuers ensure a cardholder was fully authenticated via strong customer authentication (SCA) during the first authorization in a series of recurring payments, and in other merchant-initiated transactions, prior to approving subsequent authorization requests in the same series. Compliance with PSD2 RTS Article 14 helps you have greater confidence that the transaction or recurring payment arrangement was strongly authenticated as part of the initial authorization. It also improves your ability to optimize approval rate performance, manage product offerings, and enhance consumers' digital shopping experiences. You can find the Mastercard Trace ID in the new `merchant_initiated_original_trace_id` field in transaction payloads of Gateway JIT Funding requests, webhooks, and `GET /transactions` requests. For more information about this field, see the [Transactions](/core-api/transactions/#get_transactions_token) API reference.