Get answers to questions about the Visa and Mastercard monitoring programs.
The networks count any dispute, also known as a chargeback, within a given month, regardless of the reason for the chargeback. Situations that do not count as dispute:
The networks define fraud as any transaction where the issuers suspect the cardholder did not authorize the charge. Whenever an issuer suspects a transaction might be fraudulent, the issuer would file a Visa TC40 report or Mastercard SAFE report. Stripe sources the messages from these reports to create early fraud warnings (EFW). It is possible for a transaction to receive both an EFW and a dispute, to receive only an EFW but never a dispute, or to receive a dispute but never receive an EFW.
An enumeration attempt, which Stripe calls card testing, is any transaction where someone tries to determine if the payment credentials were valid. For the purposes of identifying and mitigating card testing attacks, Visa counts any transaction that makes it to its network processor, regardless of whether the transaction was approved or declined. Visa is using the Visa Account Attack Intelligence (VAAI), its own proprietary machine learning model to identify which transactions are enumeration attempts.
Unless you refund the charge through dispute prevention, disputes on fully-refunded transactions still count towards your total disputes in the monitoring programs. This is because the dispute can be raised before the refund has hit the cardholder’s account.
If you are enrolled in dispute prevention, you can set up rules to resolve disputes. In this case, you would refund the charge and the dispute would not be counted against your account.
No. Unfortunately, the final outcome of the dispute representment has no impact on your final numbers. The card networks are ultimately looking to see what you’re doing to prevent disputes in the first place. Additionally, if the outcome mattered, identifications would take place months after the dispute-data month because you’d need the dispute process to run its course first.
No. A customer’s bank is required to report fraud on all captured transactions, even if a refund has been issued. The only exception is if the refund processes as a reversal, but that typically only happens if issued within 2 hours of charge capture.
Under certain circumstances, Stripe might auto-represent a dispute on your behalf and not show it to you in your Stripe account dashboard. For example, Stripe does this if the transaction was protected by liability shift, if it appears the card network made an error and you shouldn’t be financially liable for the dispute, or you already fully refunded the transaction before the customer disputed the charge. However, while you’re not liable for the cost of these disputes or their fees, the disputes still count toward your monthly network totals. If you tend to issue a lot of refunds, it can make your dispute rate look lower in your account than on the network's end.
A data month is the month in which a network receives a dispute or fraud report. Mastercard refers to two different data months, one for disputes and the other for sales.Visa uses the same data month for disputes, fraud, and sales.
A report month, reporting month, or identification month is the month in which a program places your account in the program, which is typically the month after the data month containing that data.
Visa uses the same data month for its disputes, fraud, and sales metrics. Mastercard uses one data month for disputes and a separate data month for sales.
Visa uses the statement descriptor, acquirer, and market (typically country) to aggregate your data. For EU countries, Visa combines the data for all EU countries. For example, if you use several statement descriptors on a Canadian account, each statement descriptor would have its own aggregation. So your account could be identified multiple times in Visa’s monitoring program if different statement descriptors qualify to be in a monitoring program. Further, if you also have a US account, the same statement descriptor can be identified twice if it qualifies to be in a monitoring program in both the US and Canada. But if you have accounts in France and Ireland that both qualify to be in the monitoring program, Visa would combine the two accounts’ data into one program identification as both accounts are in the EU.
For disputes, Visa counts the number of total TC15s raised in the data month. For fraud, Visa counts the number of total TC40s raised in the data month. Visa combines the counts to calculate a VAMP count. Visa excludes disputes and fraud from the VAMP count if any of the following conditions apply:
For disputes, Visa counts the total dollar amount (USD) of TC15s raised in the data month. For fraud, Visa counts the total dollar amount (USD) of TC40s raised in the data month. Visa combines the counts to calculate a VAMP volume. Visa excludes disputes and fraud from the VAMP volume if any of the following conditions apply:
Visa divides the VAMP count by the total number of settled transactions in the same data month. For example, the VAMP count for February is divided by the total settled transactions in February to get the VAMP ratio for February.
This program applies only to US-based users. Visa counts the total dollar amount (USD) of TC40s raised within one month and divide this by the total dollar amount of payments captured in the same month. For example, 3DS volume that received TC40s reported in February is divided by the total dollar amount of 3DS sales captured in February. The date the fraudulent payments were captured does not factor into this equation. If you meet or exceed 75,000 USD in domestic 3D Secure-authenticated (3DS) fraud volume and a fraud-to-sales volume ratio of 0.9% in a reporting month, you qualify.
Yes. The same fraudulent transaction might appear in both the TC40 and TC15 reports. Any transaction that appears in both reports is counted twice for the VAMP count and VAMP volume.
The criteria and thresholds to enter disputes and fraud monitoring for VAMP varies across regions. Businesses will enter monitoring if they meet all of the following criteria in a data month:
Visa counts all transactions that its machine learning model identifies as an enumeration attempt regardless of whether the transaction was approved or declined. This count is the VAMP enumeration count. Visa divides the VAMP enumeration count by all transactions, both approved and declined, to get the VAMP enumeration ratio.
A business will enter enumeration monitoring if its VAMP enumeration count exceeds 300,000 and its VAMP enumeration ratio exceeds 20%.
Visa can sometimes identify only a subset of transactions on a particular descriptor if the user uses more than one. To prevent this, you should start each descriptor with the same prefix, using the following format: BIZNAME* UNIQUE DESCRIPTOR. This is referred to as a dynamic suffix. In this example, Visa would aggregate everything under BIZNAME*.
If you work with another processor/acquirer, Visa typically segregates your transaction volume. In some cases, multiple processors can use the same acquirer. When this happens, Visa aggregates your data across your multiple processors and you could receive a VAMP identification even if your VAMP ratio on Stripe does not qualify for VAMP.
If you are a US-based business, you can lose Visa Secure (formerly known as Verified by Visa) benefits if your fraud level is too high. If the volume of transactions that have an EFW exceeds $75k USD and the ratio of EFW volume to transaction volume exceeds 0.9%, issuers can dispute your approved Visa Secure transactions.
Businesses outside CEMEA will exit the program if at least one of their VAMP count or VAMP ratio is below the program thresholds. Businesses in CEMEA will exit the program if at least one of their VAMP count, VAMP volume, or VAMP ratio is below the program thresholds.
To exit the program, at least one of your VAMP enumeration count or VAMP enumeration ratio must be below program thresholds.
To regain liability shift on charges, you must fall below the Visa Secure Excessive Fraud thresholds.
Mastercard counts the total number of disputes raised within one month and divides it by the total number of transactions captured in the prior month. For example, disputes reported in February are divided by the total number of sales captured in January. The date the disputed transactions were captured doesn’t factor into this equation.
You qualify and will incur program fines in any reporting month in which you meet or exceed 100 chargebacks and have a chargeback-to-sales count ratio of 1% .
Acquirers are required to identify users that qualify for a program segmented by market and self-report this to Mastercard each month.
The best way to calculate the rate is by exporting your Mastercard disputes. The US has a delay between when disputes are received from financial partners and when they’re reported to Mastercard. To get a more accurate count, start looking at disputes from the 5th of each month to the 5th of the following month, then divide this by the previous month’s sales beginning on the first of that month. For accounts in all other markets, you can count disputes from the beginning of the month until the end of the month.
Unfortunately, it is required to report identifications to Mastercard at the account level, so even if aggregate rates across multiple accounts are below thresholds, you can still qualify if one of the accounts is not. However, if your business processes for similar services on multiple accounts, it can be requested that Mastercard reassess your situation.
The only way to exit the CMM program is to below the thresholds.
To fully exit, you need two consecutive months below ECM thresholds.
For example, if you’re identified in January and are below ECM thresholds in February, but then you’re at ECM thresholds in March, you’ll be identified in ECM again. If you go two consecutive months below ECM thresholds, but are above again in the third, you will be placed back in CMM.
Stripe can pull all of the descriptors you’re using to see how they’re formatted. If you use the same prefix for each one, then they can reach out to Visa and ask them to aggregate going forward. If the descriptors are all very different from one another for example, then you should first edit your descriptor using the appropriate prefix format. It’s best if you do this at the end of the month, so sales don’t drop on the old descriptors causing dispute rates to spike.
There are instances where the data reported to Stripe from card networks may not match with what is visible in your account. This can occur for a number of reasons, such as statement-descriptor formatting, multiple processor merchant ID(MIDs), or counting charges more than once. If you think a card network made a calculation error, contact Stripe.
The following are some cases where Stripe might hide specific disputes in your account:
These disputes don’t count towards your Stripe dispute or fraud rates; however, card networks like Visa and Mastercard count these when they calculate your dispute and fraud rates on their network.You are not debited for these disputes.
This can happen if a user’s MID (processor’s merchant ID) gets updated partway through a month. Similar to how Visa relies on the statement descriptor, Mastercard’s program relies on MID. A change partway through the month could cause the sales count to appear much lower than it actually is.
Friendly fraud is not easy to spot at charge creation, since it’s often the legitimate cardholder making the payment. The best way to prevent these types of disputes is to collect as much information as possible at charge creation, clearly communicate shipping times and/or billing terms, require the cardholder to agree to the terms of service, ship only to verified billing addresses, and/or require a signature upon delivery of goods.
Less common disputes can indicate either that your statement descriptor is not recognizable or customers are confused by the way they’re billed. Often these will make up a small percentage of your total disputes. However, if any of these are one of the top three reasons, it could be an indication that some other issue is the root of the problem.
No. While an authenticated 3DS charge can offer the benefit of liability shift on fraudulent disputes for eligible businesses when applicable network criteria are met, fraud can still occur. When this happens, the issuer reports the fraud to the network (TC40s or SAFE) and this can count towards your fraud volume. Sometimes payments that are successfully authenticated using 3DS don’t fall under liability shift. This is rare and can happen, for example, if you have an excessive level of fraud on your account and are enrolled in a fraud monitoring program.
By default, Stripe allows all authenticated 3DS payments to go through. Users may want to adjust this rule so that 3DS payments flagged as high risk are still blocked. Additionally, they should rely on other signals like they would with normal charges, such as velocity, transaction size, and/or CVC/AVS checks.