Payment Brand Changes
U.S. and U.S. Territories

Effective October 25, 2026, Visa Response Code 57 will be classified as “Issuer Will Never Approve-Reattempt SIF” for System Integrity Fee (SIF) billing.

Please do not retry transactions declined with Response Code 57 to avoid SIF charges.

_{Published September 15, 2026 | P2026.0807}

On October 23, 2026, Visa will reclassify authorization response codes to 05 (Do not honor) when incorrectly used by card issuers in the following transaction types.

Table – Visa Reclassified Response Codes When Incorrectly Used by Card Issuers

_{Published September 15, 2026 | P2026.0886}

Update: The bulleted list of required data fields has been removed and replaced with a link to the Developer Center for the most current information.

Visa requires merchants to submit the appropriate authorization reversal below within 24 hours of transaction completion:

• Partial authorization reversal. if the final transaction amount is lower than the amount initially authorized

• Full authorization reversal. If the purchase is cancelled or the transaction is not completed before the final amount is settled

To return cardholders’ available funds as quickly as possible, reversals must be submitted accurately and include all required data fields. Visit our Developer Center for partial and full authorization reversal requirements and specifications.

^{Updated September 15, 2026 | P2026.0546
Published July 15, 2026 | P2026.0546}

Visa will introduce updated branding requirements for Visa Payment Passkey (VPP) to provide clearer naming and visual identification. These requirements will apply to new VPP implementations starting September 1, 2026, and to all VPP implementations starting September 1, 2027.

 The updated branding requirements cover the use of the following:

• FIDO™ passkey icon
• Visa brand mark
• Visa Sensory branding during VPP enrollment and authentication
• Visa brand presence and screen sequence during checkout flows

Please contact your third-party processor to ensure VPP implementations align with these branding updates.

More information is available on the Visa Brand Center page.

^{Published July 15, 2026 | P2026.0979}

Please make sure to include the following required elements in all transaction receipts as outlined in the Visa rules:

• Payment Credential
• Authorization Code
• Card network/scheme name
• Description of goods or services
• Merchant, Marketplace, or Digital Wallet Operator (DWO) location
• Acquirer, Consumer Bill, Payment Services, DWO, Marketplace, or Merchant name
• Return and refund policies
• Transaction amount and transaction currency symbol
• Transaction date
• Transaction type
• Other details embossed on card

You may visit our Developer Center for information on where to access the complete list of required data elements and specifications.

^{Published August 14, 2026 | P2025.1785}

Effective July 25, 2026, Visa network tokens will be required in processing stored credential transactions identified as POS Entry Mode 10 (Credential on File).

Please make sure you or your payment processor support Visa Token Service directly or through a token requestor-token service provider. Compliance with Visa’s Merchant-Initiated Transaction framework is also required for recurring transactions or where applicable.

^{Published June 15, 2026 | P2024.2601}

On June 1, 2026, Visa will introduce new branding requirements to all new executions for the following payment experiences:

• Tap to Peer-to-Peer (P2P)
• Visa Tap to Add Card
• Tap to Activate
• Tap to Confirm

Visa will also require Enabled by Visa as the brand endorsement messaging for Visa Direct, including Visa+ and Visa Tap to P2P. More information can be found in the Visa Brand Center page.

_{Note: Effective June 1, 2027, merchants must adhere to the branding requirements for all executions for the above mentioned payment experiences.} 

_{Published April 15, 2026 | P2025.3418}

Visa is enhancing their card-present $0 account verification (a “zero-dollar” check used to confirm a card is valid) to support PIN verification. This change aligns $0 verifications with standard purchase authorizations, so that the card’s bank can receive the PIN, verify it, and return in a PIN result.

On top of this, the enhancement helps support scenarios where you securely store a customer’s card for future merchant-initiated transactions, such as subscriptions or recurring payments.

What you need to do

If you use PIN with $0 account verification for Visa card-present transactions, please confirm that you are able to support:

1.    Receiving and handling PIN-related response codes returned on the $0 account verification response:

• 14 – Not in positive PIN verification file
• 55 – PIN incorrect or missing
• 75 – Allowable number of PIN-entry
• 81 – Cryptographic error found in PIN
• 86 – Cannot verify PIN (for example, no PVV)

2.    PIN retry behavior, including resending the $0 account verification when appropriate, following standard PIN retry logic.

If you are unsure whether you use $0 account verification PIN today, contact your JPMorganChase representative or your third-party processor/terminal provider for confirmation.

^{Published May 15, 2026 | P2025.2360}

Banque de France recommends merchants globally to enable 3DS authentication coverage for card-not-present transactions using cards issued in France. If you have not yet implemented measures for 3DS authentication, please take immediate action to align with these recommendations.

Visa also recommends reviewing the Banque de France announcement and website for further details.

_{Published April 15, 2026 | P2026.0363}

Visa requires the submission of Tag 9F7C, Customer Exclusive Data in the chip data tag of VisaNet contactless chip transactions, when present on a card or mobile device. Tag 9F7C enables loyalty, rewards, and personalized cardholder experiences through dynamic digital wallet updates.

Please visit our Developer Center for the complete specifications required to ensure your system is able to support the transmission of Tag 9F7C.

_{Published April 15, 2026 | P2026.0361}

Update: Visa revised the effective date for DCAP support of AFT token-based transactions in Guam to June 12, 2026, from April 17. In addition, the effective date for AFT token-based and PAN-based transactions in the other areas of the U.S. will be revised to October 23, 2026, from October 1, as reflected in the updated table below. 

Account Funding Transactions (AFTs) will be allowed by Visa to qualify for the Digital Commerce Authentication Program (DCAP) starting the following dates:

Table – DCAP Updated Effective Dates for AFTs

If you process authorization or clearing through a third-party service provider, please contact them to ensure they are able to meet Visa’s AFT authentication requirements for tokenized and PAN-based transactions on the effective dates specified above.

_{Updated July 15, 2026 | P2026.1618
Published April 15, 2026 | P2025.2358, P2025.2511}

Starting April 17, 2026, Visa will make the following changes:

• Introduce the Visa Infinite Privilege Charge and Visa Ultra High Net Worth charge consumer products
• Expand the existing products Visa Infinite Charge, Visa Infinite Privilege Credit and Debit and Visa Ultra High Net Worth Credit and Debit products for issuance in additional regions as shown below

Table – New and Expanded Visa Infinite, Visa Infinite Privilege, and Visa Ultra High Net Worth products

Existing interregional interchange fee programs apply.

^{Published March 13, 2026 | P2025.2354}

Update: To clarify, Visa will start identifying eligible transactions for DCAP on the following effective dates:

• April 17, 2026 – U.S. and Guam
• October 1, 2026 – Puerto Rico and U.S. Virgin Islands

The Digital Commerce Authentication Program (DCAP) is an optional program launched by Visa in order to enhance data sharing for customer-initiated card-not-present transactions. Participating in DCAP requires providing additional enhanced data through messages by Visa approved authentication solution (e.g. Visa Secure, 3DS or Visa Token Service).

With this, transactions eligible for the program will be identified by Visa starting on the effective dates mentioned above through the introduction of the new DCAP indicator. The indicator will be retained during authorization and returned in clearing.

If you process authorization or clearing through a third-party service provider, please contact them to ensure they meet Visa’s requirements.

^{Updated January 15, 2026 | P2025.0641, P2025.0642, P2025.2344
Published December 15, 2025 | P2025.0641, P2025.0642}

Visa strongly recommends that merchants include the Original Transaction ID (OTID) in all PAN- and token‑based standing instruction merchant‑initiated transaction (MIT) authorization. Merchants should:

• Always capture and pass the OTID in every MIT authorization message
• Ensure the initial cardholder-initiated transaction (CIT) includes the correct POS environment code with indicators I, R, or C, using the same credentials intended for future MITs
• Leverage Visa’s MIT Service to securely store, retrieve, and pass the OTID into the MIT authorization message to simplify implementation and ensure accurate linkage to the CIT 

Doing the above enables:

• Precise linkage from the initial CIT to follow‑on MITs at the subscription level, preventing over‑blocking and avoiding declines caused by merchant‑level stop instructions 
• Fewer repeated retries and declines, minimized compliance‑associated fees, and the ability to unlock more Visa value‑added services and insights through improved data integrity
• Merchant visibility into cardholder cancellation and subscription management via notifications

^{Published March 13, 2026 | P2025.3425}

On February 21, 2026, Visa will increase the permitted clearing variance from 20 to 30% for MCC 5812 – Eating Places and Restaurants and MCC 5814 – Fast Food Restaurants. Visa will also be adding MCC 5811 – Caterers to the same permitted clearing variance.

This update aims to reduce dispute risks should merchants need to process a final transaction amount with a clearing variance of more than 20%.

^{Published January 15, 2026 | P2025.2026}

In 2026, Bulgaria will adopt the euro as their national currency. This change will affect transactions outlined below.

^{Published September 15, 2025 | P2025.2121}

By December 31, 2025, Visa will require full compliance to Visa Fleet 2.0 requirements. Please work with your service provider to ensure your software is updated accordingly.

In addition, merchants who accept Visa Fleet cards must provide enhanced data for Visa Fleet card transactions under the following merchant category codes (MCCs):

• MCC 4468—Marinas, Marine Service, and Supplies
• MCC 5499—Miscellaneous Food Stores—Convenience Stores and Specialty Markets
• MCC 5541—Service Stations (With or without Ancillary Services)
• MCC 5542—Automated Fuel Dispensers
• MCC 5983—Fuel Dealers—Fuel Oil, Wood, Coal, and Liquefied Petroleum

_{Note: MCC 5552 – Electric Vehicle Charging is currently excluded. Visa Fleet card transactions must provide both cardholder-supplied data and supplemental transaction data for these transactions.}

_{Published November 14, 2025 | P2024.2288}

Visa updated their Service Fee program to include the key changes below:

• Adding MCC 4900—Utilities – Electric, Gas, Water, and Sanitary in the Service Fee program, in addition to the existing permitted MCCs:
  • MCC 8211—Elementary and Secondary Schools
  • MCC 8220—Colleges, Universities, Professional Schools, and Junior Colleges
  • MCC 8244—Business and Secretarial Schools
  • MCC 8249—Vocational and Trade Schools
  • MCC 9211—Court Costs, Including Alimony and Child Support
  • MCC 9222—Fines
  • MCC 9311—Tax Payments
  • MCC 9399—Government Services (Not Elsewhere Classified)

• Registration of or providing a Merchant Verification Value (MVV) is not required
• Government approval processing tax payments with a service fee is no longer necessary
• Payments and service fees can be processed in a single transaction, allowing you to select the most efficient processing method

_{Published December 15, 2025 | P2025.2465}

On October 18, 2025, Visa will add new Spend Qualified Indicator (SQI) values to supplement the existing values shown in the table below.

The new SQI values may be applied to Interchange Reimbursement Fee programs in certain markets, similar to the current values. Future programs may include an expanded level of spend qualification which may utilize the new values.

Please visit our Developer Center for the complete specifications of the SQI values.

Table – Visa New and Existing SQI Indicators

_{Published October 15, 2025 | P2025.0648}

Starting October 18, 2025, Visa will standardize requirements for processing delayed charges for loss, theft, or damages.

A delayed charge transaction for damages, will require merchants to obtain cardholder consent through one of the following:

• Cardholder signature on the same page and near the description of potential charges for delayed charge transactions
• Cardholder signature on the agreement and initials on each page, including the page with the charge description
• Other documentation proving the cardholder's liability for damages

These requirements apply to the following merchant types:

• Vehicle Rental Merchants (Including but not limited to MCCs 3351 – 3441)
• Lodging Merchants (Including but not limited to MCCs 3501 to 3840)
• MCC 7999 – Recreational Services (Aircraft, bicycle, and motorcycle rental)
• MCC 4457 – Boat Rentals and Leasing
• MCC 7296 – Clothing Rental (Costumes, uniforms, and formal wear)
• MCC 4411 – Steamship and Cruise Lines
• MCC 7394 – Equipment, Tool, Furniture, and Appliance Rental and Leasing
• MCC 4789 – Transportation Services
• MCC 7519 – Motor Home and Recreational Vehicle Rentals
• MCC 7033 – Trailer Parks and Campgrounds

_{Published October 15, 2025 | P2025.1574}

On October 17, 2025, Visa will add Visa Stop Payment Service (VSPS) checks in the account verification process. This will notify merchants of stop instructions for a primary account number for recurring and installment transactions.

Please be prepared to receive the following VSPS decline response codes:

• R0 – Stop this payment
• R1 – Stop all future payments
• R3 – Stop all merchants

These VSPS decline response codes indicate that the cardholder has withdrawn their consent to use their card for payment. Please do not attempt to resubmit an authorization request after receiving any of the VSPS decline response codes.

_{Published October 15, 2025 | P2025.0651}

On October 17, 2025, Visa will add response code 78 – Blocked, first used or special condition—new cardholder not activated or card is temporarily blocked to the list of permitted response codes for credit voucher and merchandise return authorization transactions. Updated list show below.

Table 1 – Visa Valid Card Issuer-Provided Approve Response Codes

Table 2 – Updated Visa Valid Card Issuer-Provided Decline Response Codes

<sup>1. Applies only to non-reloadable prepaid cards that do not support credit transaction types, or certain healthcare-related prepaid products where transactions are restricted to certain merchant categories. Response code 57 is not valid for general credit or debit card transactions.
2. This is not a new response code; it already exists for other transactions, but it is now being leveraged for merchandise return and credit vouchers.</sup>

^{Published September 15, 2025 | P2025.0649}

Visa has updated their Visa Acquirer Monitoring Program (VAMP) ratio to include fraud disputes, in addition to non-fraud disputes.

Merchants exceeding VAMP ratio thresholds and minimum monthly counts to enter the program will be assessed a merchant excessive fee of 8 USD by Visa, multiplied by each instance of fraud and each dispute, beginning October 1, 2025.

It is recommended to take the following measures to reduce being identified in VAMP:

• Implement fraud prevention and security tools to detect and prevent unauthorized transactions
• Use advanced dispute mitigation tools, such as Real-time Dispute Resolution (RDR) systems
• Conduct thorough analyses of chargebacks to yield insights on underlying causes of disputes

_{Published August 15, 2025 | P2025.1030}

Update: The Visa Smart Debit/Credit (VSDC) Certificate Authority (CA) 1408-bit public key must be removed from all terminals by July 1, 2025 to prevent transaction processing failures.

Visa has extended the expiration date of the Visa Smart Debit/Credit (VSDC) Certificate Authority (CA) 1984-bit public key to December 31, 2034 as shown in the below table. The expiration date of the 1408-bit public key remains the same.

Visa has extended the expiration date of the Visa Smart Debit / Credit (VSDC) Certificate Authority (CA) keys for the 1984-bit public key.

Please reach out to your point-of-sales (POS) service provider to ensure that all terminals supporting Offline Data Authentication or Offline Enciphered PIN contain Visa public keys with the updated expiration dates shown below. Take note to not use expired keys or keys past their expiration date.

Table – Visa Extended Expiration Date for VSDC CA Key

_{Updated June 13, 2025 | P2025.0233
Updated December 13, 2024 | P2024.1949
Published  November 15, 2024 | P2022.1122}

Effective October 28, 2026, Mastercard will support product graduation from consumer product code MWE: World Elite Mastercard® Card to commercial product code MAB: World Elite™ Mastercard® for Business Card through the Account Level Management Product Graduation Plus (ALM PGP) service. This change applies to U.S. card issuers and U.S. merchants only.

Because ALM PGP migrates eligible cardholders across product codes without changing the primary account number, some transactions may be processed as commercial and require additional commercial (corporate card) addendum data¹.

Visit our Developer Center from October 1 onwards for the required specifications for the MAB product code.

_{1. Merchants in the U.S. region must ensure that, when submitting U.S. intraregional clearing for transactions eligible for a graduated product code, the required commercial addendum data is included. This requirement is in addition to any other addendum messages required based on the transaction type (e.g., MoneySend and Payment Transactions, T&E, Passenger Rail).}

_{Published September 15, 2026 | P2026.0724}

Effective October 23, 2026, Mastercard will introduce the following values for their Token Assurance Level field in authorization messages.

Table – New Mastercard Token Assurance Level Field Values

_{Published September 15, 2026 | P2026.1192}

Effective October 23, 2026, Mastercard will revise their fleet program to require updated Fleet 2.0 transaction data. Merchants that do not meet the new specifications by this date will not qualify for fleet interchange rates and will be assessed standard rates. Visit our Developer Center for details on the updated requirements.

_{Note: Applies to Fleet Fuel Locations –  4468, 5499, 5541, 5542, 5983; Electric Vehicle Charging – 5552; and Fleet Maintenance Locations – 5013, 5511, 5531, 5532, 5533, 5599, 7531, 7534, 7535, 7538, 7542, 7549, 7692, 7699.}

_{Published September 15, 2026 | P2026.1796, P2023.1184, P2023.1547}

Effective October 23, 2026, Mastercard will introduce new device type values to support magnetic stripe retirement and identify physical EMV chip cards issued without magnetic stripes.

• 35: Card with contact chip and contactless interfaces; no magnetic stripe
• 36: Card with contact chip interface only; no magnetic stripe, no contactless interface
• 37: Card with contactless interface only; no magnetic stripe, no contact chip interface

What you need to do

If you use a third-party processor/terminal provider, confirm that they support and correctly process the new device type values.

If your terminal is provided by JPMorganChase, no action is needed.

_{Published September 15, 2026 | P2026.1178}

Mastercard is now declining gaming and gambling transactions globally on India-issued cards to meet Indian regulatory requirements. This applies to the following MCCs:

• 7800 - Government-owned Lottery
• 7801 – Internet Gambling
• 7802 – Government Licensed Horse/Dog Racing
• 7995 – Gambling Transactions

_{Published September 15, 2026 | P2026.1570}

Mastercard introduced Mastercard One Credential – a single, digitally connected credential which enables cardholders to set and manage their payment preferences through a seamless digital experience in their banking app or website.

Complete specifications will be available on our Developer Center on October 1, 2026, or you may reach out to your JPMorganChase representative for more information.

_{Published September 15, 2026 | P2025.0536, P2025.0511}

Mastercard now requires all Authentication Requests (AReqs) to contain at least one fully populated, accurate field from each category: Cardholder Identifier, Address/Delivery, and Technical.

Effective October 13, 2026, Mastercard will also require support for approved Multi-Factor Authentication (MFA) methods under EMV 3DS, as OTP alone will no longer qualify.

What you need to do:

• If you authenticate 3DS through JPMorganChase, provide the cardholder’s complete and accurate billing and shipping address information. For full Mastercard specification requirements, visit the Payment Developer Portal.
• If you use a third party 3DS service provider, confirm that enhanced data fields are populated and required MFA methods and specifications are supported by your provider.

^{Published August 14, 2026 | P2026.0334}

Mastercard’s Low Risk Validation (LRV) within Mastercard Identity Check (EMV 3-D Secure/3DS) is now available to e-commerce merchants globally¹.

LRV is an e-commerce authentication flow that uses token data, enhanced data, and Smart Authentication risk scoring to reduce unnecessary step-up (challenge), helping improve approval rates and lower fraud.

Fraud liability considerations

• When the issuing bank accepts LRV (ECI = 06, AAV leading indicator = kN, SLI = 216), liability remains with the merchant (no 3DS liability shift)

• When the issuing bank challenges the transaction, liability shifts to the issuer under the standard 3DS challenge flow

What you need to do

To participate in LRV, you must ensure authentication requests meet Mastercard's minimum Enhanced Data Standards by including at least one fully populated and accurate field within the cardholder identifier, address/delivery, and technical data field categories (unless prohibited by local regulation).

Next steps

• If you use a third-party 3DS provider, confirm LRV capability and required data field support with your provider
• If you authenticate 3DS through JPMorganChase, please contact your JPMorganChase representative for more details

^{1. Except in Europe where Mastercard uses Transaction Risk Analysis (TRA) Exemption for risk-based authentication, allowing issuers to challenge only the highest-risk transactions.}

^{Published August 14, 2026 | P2026.1229}

Mastercard has enabled payment passkeys as a multi-factor authentication (MFA) option during EMV 3DS browser-based challenge transactions under the Identity Check (IDC) program. Cardholders may already have a passkey set up from other experiences, such as Token Authentication Service (TAS) flows or their card’s banking app or website. 

Please contact your payment service provider or 3DS provider to confirm that your integration supports Mastercard passkeys and update your configuration if needed.

^{Published August 14, 2026 | P2026.0838}

Mastercard’s Transaction Link Identifier (TLID) is a 22-character unique identifier assigned to every new transaction (e.g. aRyU-3Ti981f_6WvBaqM03). It is used to track and link related transaction activities across multiple stages over time.

Starting December 1, 2026, deposit transactions will be considered non-compliant if the TLID is missing or incorrect so make sure to retain and use the TLID in all subsequent related transactions. Mastercard will continue to support Trace ID, Banknet reference number, and switch serial number until further notice.

For complete TLID specifications, please visit the Developer Center.

^{Published July 15, 2026 | P2024.0472}

Mastercard’s First-Party Trust Program lets you prove a cardholder authorized a disputed transaction (Reason Code 4837: No Cardholder Authorization) for Dual Message System e-commerce transactions.

How the Program Works

• When a transaction is disputed, you can submit data from at least two previous, non-fraud transactions along with the disputed transaction.
• If the disputed transaction matches the historical legitimate transactions, you may avoid chargebacks, subject to program terms and conditions.

How to Submit Evidence

• Use Identity Check Insights (during pre-authorization)
• Use Ethoca Consumer Clarity (when a dispute is raised)

To enroll or learn more, please contact Mastercard or Ethoca at:

• First-Party Trust Program – first.party.trust@mastercard.com
• Ethoca Consumer Clarity – customerservice@ethoca.com
• Identity Check Integrations – digital.identity.solutions.support@mastercard.com

Participation in this program is optional.

^{Published June 15, 2026 | P2025.1706u1}

Effective June 2, 2026, for merchants in states that prohibit MCC 5723 (Firearms and Ammunition), Mastercard will send MCC 5941 (Sporting Goods Stores) instead in the authorization and clearing messages if MCC 5723 is incorrectly submitted by the bank. All related lifecycle messages will also show MCC 5941.

_{Published April 15, 2026 | P2025.2773}

Effective April 17, 2026, Mastercard will reinstate the Fraudulent Processing of Transactions Chargeback as a compliance case.

This change addresses fraud schemes where customers are tricked into approving additional fraudulent, face-to-face, card-read transactions shortly after a legitimate purchase. These transactions can appear under a different merchant name or location.

A common fraud scheme works like this:

1. A cardholder tries to pay at the pump.

2. The attendant claims the transaction didn’t go through and brings the cardholder inside to pay (or offers to take the card inside for them).

3. Inside, the attendant uses a fraudulent or tampered merchant terminal to run an in-person, card-read transaction under a different merchant name and location than what the cardholder authorized.

As a result of this change, you may see an increase in dispute compliance cases related to above fraudulent activity scenarios.

_{Published April 15, 2026 | P2025.2063}

Starting April 17, 2026, Mastercard will no longer allow full primary account numbers (FPAN) to appear in any document used for disputes. With this, merchants should NOT upload documents for Mastercard containing the FPAN, as this would violate Mastercard rules and may result in fines or additional fees. This rule also applies if the same document is sent again in a later¹ dispute and still shows the FPAN.

To avoid the violation, merchants should only show the last four digits of the card number in any document. Here are some ways to mask the rest of the numbers to ensure that the FPAN cannot be read or reconstructed:

• Cover the other digits with black ink
• Use a software to block out the digits
• Replace the digits with symbols like X, *, or #

Whatever method is used, make sure the FPAN cannot be read or reconstructed.

^{1. If a document is sent with the FPAN, Mastercard will not cancel the dispute, but the fee will be assessed.}

^{Published February 13, 2026 | P2025.1932}

Starting March 31, 2026, Mastercard will update their processing requirements for outbound transactions made with Mainland China-issued cards as outlined in the tables below.

These changes are designed to comply with Mainland China’s regulatory standards and may impact how certain transactions are processed. Expect these changes to be enforced at both the authorization request stage and the clearing stage.

Table 1 – Prohibited or invalid card acceptor business codes (MCCs) for which all transactions will be rejected

Table 2 – Restricted or invalid MCCs for which transactions more than 5,000 USD will be rejected

^{Published January 15, 2026 | P2025.3056}

Mastercard has shared the following best practices for preventing enumeration attacks. These attacks involve fraudsters systematically testing card numbers and credentials to identify valid card details.

• Capture and validate CVC2. Always require and validate the CVC2 code when adding a card or processing transactions. This is mandatory for card add in the Europe region and strongly recommended elsewhere.
• Enable EMV 3-D Secure authentication. Ensure EMV 3-D Secure is performed for all card adds and e-commerce transactions to provide an additional layer of security and prevent unauthorized card use.
• Implement CAPTCHA technology. Use CAPTCHAs during card add and checkout to block bots and automated attacks.
• Use Address Verification Service (AVS). Where supported, use AVS to verify the cardholder’s address and further reduce fraud risk.
• Monitor for unusual activity. Watch for spikes in transaction declines, multiple card adds from the same IP address or account, and increases in high-dollar, cross-border transactions. Set up internal alerts for higher than usual failure rates in card adds and authorization transactions.
• Limit transaction velocity. Detect and prevent multiple card adds or transactions per user account or IP address within short time frames. Implement throttling to restrict the number of actions from a single user account or IP address.
• Meet PCI DSS Standards. Ensure your business and all third-party service providers (e.g., payment gateways and shopping cart providers) comply with PCI DSS requirements and have mechanisms to detect and prevent enumeration attacks.
• Report suspicious activity. Immediately report any suspected account takeover or enumeration attack to your bank.
• Remediation plan. Have a documented and actionable remediation plan to address enumeration attacks within 72 hours of detection or notification by your bank or Mastercard.

Implementing these measures will help reduce fraud losses, protect cardholder data, and maintain trust with your customers. Please review your current processes and update them as necessary to comply with Mastercard’s recommendations.

^{Published March 13, 2026 | P2025.3018}

Mastercard is no longer requiring merchants to collect CVC 2 data for all card-not-present authenticated transactions. You may refer to the table for guidance on transaction authentication.

Table – Mastercard Expected Merchant Action During Authorization

^{Published January 15, 2026 | P2023.2190u1, P2023.2190a}

In 2026, Bulgaria will adopt the euro as their national currency. This change will affect transactions outlined below.

^{Published September 15, 2025 | P2025.1973}

Effective November 4, 2025, Mastercard will apply Merchant Advice Code (MAC) to card-present transactions. This change will allow you to receive MAC value 02 (Cannot approve at this time, try again later) that will not be limited to deferred authorizations. This will help manage resubmissions for deferred authorizations.

_{Published October 15, 2025 | P2025.0809}

Mastercard advises merchants to ensure that PIN entry bypass is disabled or removed from all payment terminals, regardless of card brand (either Mastercard or Metro) unless specifically required by regulatory mandates or banking association guidelines.

This suggestion is to help enhance cardholder security and reduce the risk of fraud from lost or stolen cards and helps protect cardholders from unauthorized transactions to maintain a secure payment environment.

_{Published November 14, 2025 | P2025.2304}

On October 17, 2025, Mastercard will revise the following standards:

• Authorization resubmission requirements. Resubmitted requests must include the same merchant details and POS condition values as the original, unless exceptions apply (e.g., transit debt recovery). They must also include the original PAN and expiration date, a tokenized-stored credential obtained through Secure Remote Commerce tokenization, or new account information from the cardholder or Automatic Billing Updater.
• Token cryptogram exception. If token cryptogram data is used in a declined merchant-initiated transaction (MIT) authorization request, it must not be reused in subsequent resubmissions.
• CNP transaction restrictions. Declined card-not-present (CNP) cardholder-initiated transactions must not be resubmitted as an MIT, except for transit debt recovery.
• Merchant advice codes. Merchants should use the decline reason and merchant advice code from the issuer's response in their resubmission strategies for MITs.
• Prohibition of data manipulation. Merchants must not manipulate transaction data in resubmissions to evade payment arrangement cancellations. This includes altering the acceptor ID or acceptor name used in the merchant's transaction messages, or shifting the merchant's transaction volume to a different acceptor ID.
• Response code restrictions. If any of the following response codes are received in the issuer’s authorization response for a merchant-initiated CNP transaction, do not make additional authorization requests for the same transaction with the same account information (PAN and expiration date combination) at any time:
  • 04 (Capture card)
  • 14 (Invalid card number)
  • 15 (Invalid issuer)
  • 41 (Lost card)
  • 43 (Stolen card)
  • 54 (Expired card)
• Resubmission strategy. The authorization resubmission strategy for MITs must consider both the decline reason code and MAC, as shown below:

Table – Mastercard Authorization Resubmission Strategy for MITs

Please visit our Developer Center for the complete specifications.

^{Published September 15, 2025 | P2025.0437}

Mastercard will require an online authorization for all refund transactions submitted for clearing starting October 1, 2025. This excludes refunds conducted by airlines (MCCs 3000 through 3350 and MCC 4511), contactless aggregated transit transactions, and commercial card transactions.

_{Published June 13, 2025 | P2025.0302}

Merchants with sales of online gift cards as their primary activity are now permitted to use MCC 6051 (Quasi Cash) as purchase transactions, following Mastercard’s revision of their standards.

They may still use MCC 6540 for funding transactions, but it must be coded with the appropriate Transaction Type Identifier (TTI) values and additional transaction reference data.

To avoid potential data integrity fines, visit our Developer Center for the complete specifications for funding transactions. You may also contact your JPMorganChase representative for more information.

_{Published October 15, 2025 | P2025.1967}

Update: Mastercard has extended the 1984-bit Payment System public key expiration date to December 31, 2035, as shown in the table below.

The 1408-bit Root Certificate Authority (CA) public key must be removed from all terminals by July 1, 2025 to prevent transaction processing failures.

The 1984-bit Payment System public key expiration date has been extended to December 31, 2034 by Mastercard. The 1408-bit public key expiration date remains the same.

Reach out to your point-of-sale (POS) service provider to ensure that all terminals supporting Offline Data Authentication or Offline Enciphered PIN contain public keys with the updated expiration dates. Please do not use keys past their expiration date.

Table – Mastercard, Maestro and Cirrus Extended Expiration Date for the Payment System Public Key

_{Updated December 15, 2025 | P2024.1842u1
Updated June 13, 2025 | P2024.1842
Published February 14, 2025 | P2024.1842}

Starting April 17, 2026, American Express OptBlue will require the below merchant profile data fields during the OptBlue Program merchant registration. Those with inaccurate or incomplete required data may be blocked or canceled from the OptBlue Program, resulting in ineligibility and not being able to process authorization and clearing transactions.

Required Merchant Profile Data Fields:

• Seller ID
• Seller Legal Name
• Seller DBA Name
• Seller Street Address
• Seller City Name
• Seller Region Code
• Seller Postal Code
• Seller Country Code
• Seller Currency Code
• Language
• Authorized Signer First Name
• Authorized Signer Last Name
• Authorized Signer Country Code

If you are blocked or canceled, please reach out to your JPMorganChase representative to resolve the issue and ensure your profile data is updated, complete, and compliant with the required merchant user profile data fields.

^{Published March 13, 2026 | P2025.2646}

Bulgaria will adopt the euro as their national currency in 2026. This change will affect the below transactions.

^{Published January 15, 2026 | P2025.2868}

Update: The 1408-bit RSA Certification Authority (CA) public key must be removed from all terminals by July 1, 2025 to prevent transaction processing failures.

The 1984-bit RSA Certification Authority (CA) public key expiration date has been extended to December 31, 2034 by American Express. The 1408-bit public key expiration date remains the same.

Reach out to your point-of-sale (POS) service provider to ensure that all terminals supporting Offline Data Authentication or Offline Enciphered PIN contain public keys with the updated expiration dates. Please do not use keys past their expiration date.

Table – American Express Extended Expiration Date for the RSA Certification Authority Public Key

_{Updated June 13, 2025 | P2024.2097
Published February 14, 2025 | P2024.2097}

On October 23, 2026, Discover will expand their car rental MCC range to 3351-3500 from 3351-3441 for the following interchange programs.

Car rental MCCs included:

• PSL – Hotels/Car Rentals, U.S. Consumer AIP

Car rental MCCs excluded:

• PSL – Retail, U.S. Consumer AIP
• PSL – Card Not Present, U.S. Consumer AIP
• PSL – E-Commerce, U.S. Consumer AIP
• PSL – E-Commerce Secured, U.S. Consumer AIP
• Key Entry, U.S. Consumer AIP
• Electronic, U.S. AIP

_{Published September 15, 2026 | P2026.1085}

Discover now requires a valid date value to be provided in the Expiration Date field for all Discover card-not-present or key-entered authorization transactions. Please ensure the valid expiration date is submitted in the YYMM format to prevent transaction declines.

^{Published May 15, 2026 | P2021.1200a}

The Discover® Network Acceptance Mark has been updated. Please visit Discover’s Signage Site for more details.

_{Published April 15, 2026 | P2026.0620}

Starting January 1, 2026, Discover will require all cards to be compliant with D-Payment Application Specification (D-PAS) Connect. Ensure that your contactless D-PAS terminals have the correct terminal transaction qualifier (TTQ) to avoid terminated transactions. Discover will also discontinue support for offline plaintext PIN (OPTP).

In addition, by December 31, 2025, contactless terminals must cease supporting Zip or CTL-MSD transactions and be updated to support EMV contactless payments. D-PAS Connect transactions will fail if terminals only support CTL-MSD or Zip.

Please visit our Developer Center for the full D-PAS details. If your POS is managed by a third-party provider, please contact them to ensure compliance.

_{Published October 15, 2025 | P2025.1633}

Effective October 5, 2026, any Good Faith Adjustment request that expires after 45 days without issuer action will be automatically decided in the issuer's favor.

These transaction processing requirements will apply:

• Preauthorized transactions must be completed within 30 minutes of authorization
  • Transactions that receive a 220 failure response after this timeframe will not be eligible for a Good Faith Adjustment request
• Reversal requests must be submitted within 1 hour of the original transaction

Good Faith Adjustment requests are not permitted for:

• More than two adjustment requests for the same transaction
• Merchant authorized transactions (MAT)
• Incremental Authorizations on automated fuel dispenser (AFD) transactions

Merchants may be asked to provide supporting documentation during the adjustment request review period.

_{Published September 15, 2026 | P2026.1382}

Effective October 15, 2026, NYCE will reduce the 25 MB maximum file size allowance for supporting documents submitted for dispute processing. 

Please ensure total size of all supporting documents per dispute is 4 MB or less to prevent submission failures and potential dispute losses.

^{Published July 15, 2026 | P2026.1617}

Update: Starting March 21, 2026, Accel and STAR fraud chargebacks will be challenged through the Outgoing Pre-Arbitration Cycle, where:

• Status updates will be visible in the Chargeback Management (CBIS) user interface
• Funds will only be transferred if the card issuer accepts the chargeback or does not respond within the required timeframe

On March 21, 2026, Fiserv will migrate the exception processing platform for Accel and STAR to Transaction Research and Exception Processing (TREP). This will lead to a revision in Accel’s timeframe for merchant response to chargebacks/exceptions, while STAR’s will remain unchanged, as shown in the table below. Exception items created before the update will adhere to the current timeframes.

Table – Merchant Response Timeframe for Exception Processing

^{Updated March 13, 2026 | P2024.1160
Published January 15, 2026 | P2024.1457, P2024.1160}

Bulgaria will adopt the euro as their national currency in 2026. This change will affect the below transactions.

^{Published January 15,  2026 | P2025.3181}

Update: The 1408-bit Root Certificate Authority (CA) public key must be removed from all terminals by July 1, 2025 to prevent transaction processing failures.

The 1984-bit Root Certificate Authority (CA) public key expiration date has been extended to December 31, 2035 by UnionPay International. The 1408-bit public key expiration date remains the same.

Reach out to your point-of-sale (POS) service provider to ensure that all terminals supporting Offline Data Authentication or Offline Enciphered PIN contain public keys with the updated expiration dates. Please do not use keys past their expiration date.

Table – UnionPay Extended Expiration Date for the Root CA Public Key

_{Updated June 13, 2025 | P2024.0007
Published February 14, 2025 | P2024.0007}

Update: The 1408-bit JCB/Certification Authority (CA) public key must be removed from all terminals by July 1, 2025 to prevent transaction processing failures.

The 1984-bit JCB/Certification Authority (CA) public key expiration date has been extended to December 31, 2034 by JCB International. The 1408-bit public key expiration date remains the same.

Reach out to your point-of-sale (POS) service provider to ensure that all terminals supporting Offline Data Authentication or Offline Enciphered PIN contain public keys with the updated expiration dates. Please do not use keys past their expiration date.

Table – JCB Extended Expiration Date for the JCB/CA Public Key

_{Updated June 13, 2025 | P2023.2284
Published February 14, 2025 | P2023.2284}