Mastercard’s Scam Merchant Push: The Networks Are Done Waiting for Chargebacks

There is a point in every bad merchant story when everyone suddenly agrees the merchant was a problem.

The chargebacks are obvious. The complaints are piling up. The website looks fake in hindsight. The refund policy reads like it was written by a raccoon with a law degree. Support has a folder full of angry customers. The sponsor bank is asking questions. The acquirer wants answers. The platform is trying to remember who approved this merchant in the first place.

Great.

Also too late.

By the time the merchant is already producing chargebacks, complaints, and network pain, the payments system has usually allowed the problem to run for a while. The scam did not begin when the first dispute arrived. It began when the merchant got access to the system, looked legitimate enough to process, and stayed active long enough to hurt real customers.

That is the part Mastercard appears to be targeting.

Mastercard recently announced Merchant Trust Services, a strategy designed to use network-wide intelligence, cyber and identity capabilities, and real-time analytics to help banks and payment providers distinguish legitimate merchants from risky ones earlier in the lifecycle. Mastercard describes the effort as a way to help identify scam merchants before they reach consumers, not just after the damage is done. Mastercard Documentation

That is not just a card-network compliance footnote.

It is a signal.

The networks are done waiting for chargebacks to prove a merchant is a problem.

And if you are an acquirer, PayFac, PSP, ISO, marketplace, or software platform that helps merchants get into the payments system, this is not someone else’s headache.

It is your operating model.

The Chargeback Is Too Late

Chargebacks matter.

They show customer harm. They create financial exposure. They trigger network programs. They damage merchant portfolios. They make sponsor banks nervous. They also give everyone a measurable number to point at, which is helpful in the same way a smoke alarm is helpful after the kitchen is already on fire.

But chargebacks are often a lagging signal.

A scam merchant can launch a polished storefront, run ads, accept card payments, ship nothing useful, stall refund requests, and disappear before the dispute data tells the full story. By the time chargebacks spike, the merchant may have already processed volume, withdrawn funds, damaged consumers, and created exposure for everyone upstream.

That is why after-the-fact monitoring is not enough.

The old posture was often: approve the merchant, monitor ratios, react when the numbers get ugly.

That model was never great. It was just familiar.

Scam merchants are built to exploit that delay. They do not need to operate forever. They just need enough time to look real, collect payments, and move on before the system finishes noticing.

Mastercard’s push is part of a broader move toward earlier detection: identify bad signals during onboarding, authorization, transaction activity, website behavior, customer complaints, and ongoing monitoring.

In other words, stop treating the chargeback as the first serious alarm.

By then, the scam has already had a head start.

Scam Merchants Are Getting Better at Looking Normal

The uncomfortable part is that scam merchants do not always look like cartoon villains at onboarding.

They may have a professional-looking website. They may have clean product photos. They may have terms and conditions. They may have customer support contact information that technically exists. They may use normal payment flows, ordinary card-not-present transactions, and marketing language that sounds plausible enough to pass a quick review.

Generative AI makes that easier.

A fake storefront can now have better copy, better imagery, better reviews, better product descriptions, and better branding than a legitimate small business that is still using a logo from 2014 and a contact form that goes nowhere.

That is a real problem for payments risk.

Classic fraud controls are good at catching certain things: stolen cards, velocity attacks, bot behavior, account takeover, mismatched signals, and transaction anomalies. Scam merchants can be harder because the individual card transaction may look authorized. The customer meant to buy. The cardholder was real. The authorization may be legitimate.

The scam is in the merchant’s promise.

The product is fake. The delivery is fake. The claim is misleading. The subscription trap is buried. The trial terms are deceptive. The refund path is impossible. The storefront exists just long enough to capture payments and frustrate recovery.

That kind of risk does not always scream at the point of authorization.

It whispers through patterns.

Website signals. Merchant identity signals. Complaint velocity. Refund friction. Dispute categories. Abnormal fulfillment behavior. Mismatched business descriptions. Advertising claims. Sudden spikes. Similar storefronts. Shared infrastructure. Reused identities. Support narratives. Transaction behavior that is technically allowed but commercially suspicious.

If those signals live in different systems and nobody owns the full picture, the scam merchant gets time.

Time is the product.

Mastercard Is Moving the Fight Earlier

Mastercard’s Merchant Trust Services announcement is important because it frames merchant legitimacy as something that can be evaluated earlier and more continuously.

Mastercard says the service uses network intelligence, cyber and identity capabilities, and real-time analytics to distinguish legitimate merchants from risky ones, online and in store. The company is positioning it as a way for banks and payment providers to identify scam merchants before consumers are harmed, rather than reacting only after loss occurs. Mastercard Documentation

That matters because it changes the center of gravity.

Merchant monitoring is not just a portfolio report.

It is not just a monthly chargeback review.

It is not just a MATCH lookup, a website scan, or a one-time onboarding checklist.

It is becoming a continuous risk process.

The lifecycle now matters: who the merchant is, what they sell, how they onboarded, what their website shows, how their transaction behavior changes, whether complaints are emerging, whether refunds look strange, whether disputes tell a consistent story, and whether external risk signals suggest the merchant is not what it claimed to be.

That is a lot more operationally demanding than “check the merchant at onboarding and hope the ratios stay cute.”

It also means platforms may need to think differently about merchant data.

If a risk signal appears, can the acquirer or PayFac quickly understand the merchant’s website, ownership, onboarding file, processing history, refund behavior, dispute profile, customer complaints, and support communications?

If not, the monitoring program is not really continuous.

It is just fragmented evidence waiting for a bad day.

Speed Matters When the Alert Arrives

Scam merchant monitoring gets real the moment a warning signal appears.

It is one thing to say a merchant should be investigated. It is another thing to actually gather the facts, understand the behavior, contact the right parties, decide whether processing should continue, document the decision, and communicate carefully without turning the review into chaos.

That is where many programs struggle.

Faster investigation sounds reasonable until your merchant data lives in five systems, your website review is outsourced, support complaints are not connected to risk, your PayFac agreement is vague, and nobody knows who has authority to suspend processing.

The operational question is not just whether you can identify a suspicious merchant.

It is whether you can act quickly once you do.

Can you pull the merchant file? Can you see the website as it appeared during onboarding? Can you compare current activity to approved activity? Can you review refund and dispute behavior? Can you understand complaint themes? Can you see payout exposure? Can you document why a merchant was held, terminated, or allowed to continue?

If you have to invent that workflow after the alert arrives, you are already behind.

This Is Not Just an Acquirer Problem

Formally, network obligations often land on acquirers and payment facilitators.

Practically, the work flows downstream.

A platform may control the merchant onboarding flow. A PayFac may manage sub-merchant approval. A PSP may hold the transaction history. A marketplace may own the seller relationship. A software company may control the website integration, support records, product category, business description, and customer communications.

So when a scam merchant signal appears, the acquirer may be responsible for responding, but the platform may be the only one with the context needed to respond well.

That is where the “processor handles risk” argument starts to fall apart.

If your onboarding flow let the merchant in, your platform shaped the risk.

If your product gave the merchant access to buyers, your platform participated in the exposure.

If your support team received the first complaints, your platform had early warning.

If your dashboard shows refunds, disputes, payout timing, and customer messages, your platform may hold the evidence everyone needs.

That does not mean every platform is legally responsible for everything. Contracts matter. Network roles matter. Program structure matters.

But operationally, hiding behind the acquirer is not enough.

The customer sees the platform. The merchant uses the platform. The sponsor bank may ask the platform’s partner for answers. The PayFac may ask the platform for documentation. The network may expect action. The processor may need data fast.

The risk may start as a merchant problem.

It becomes an ecosystem problem very quickly.

Monitoring Is an Operating Model, Not a Dashboard

This is the part that separates serious programs from dashboard theater.

A dashboard can show risk signals.

It cannot own them.

Merchant monitoring requires an operating model: what gets reviewed, who reviews it, what evidence matters, what thresholds trigger escalation, who can hold funds, who can suspend processing, who communicates with the merchant, who documents the decision, and who confirms that the problem was actually resolved.

That operating model should connect the signals that usually live apart:

• Onboarding and KYB information.
• Website and product review.
• Merchant category and business description.
• Transaction velocity and volume changes.
• Refund rates and refund friction.
• Chargebacks and dispute categories.
• Customer complaints and support themes.
• Payout behavior and reserve exposure.
• Advertising claims and external website signals.
• Shared identities, infrastructure, or patterns across merchants.

None of those signals is perfect by itself.

Together, they tell a story.

The problem is that many platforms are not built to read the story. Product sees one piece. Risk sees another. Support sees complaints. Finance sees losses. The processor sees transactions. The acquirer sees portfolio exposure. Legal sees contract language. Nobody sees the whole merchant until the incident review, when everyone gathers around the conference table to admire the obvious red flags in hindsight.

That is not monitoring.

That is archaeology.

False Positives Are Part of the Job

Scam merchant monitoring is necessary.

It is also messy.

Legitimate merchants can get flagged. New businesses can have thin histories. A sudden sales spike may be growth, not fraud. High refunds may reflect a seasonal issue, not a scam. Customer complaints may be noisy. A website may look suspicious because the merchant is bad at ecommerce, not because they are stealing from people.

That means platforms need review discipline.

A strong monitoring program should be fast, but it should not be reckless. It needs evidence standards, decision rights, escalation paths, and communication rules. It needs to distinguish between confirmed scam activity, suspected activity, weak documentation, operational sloppiness, and legitimate merchants that need coaching or enhanced review.

False positives are not just an inconvenience.

They can hurt merchants, create support storms, damage platform trust, and create legal or contractual disputes if the platform cannot explain what happened.

That is why the answer is not “flag everything and shut it down.”

The answer is controlled escalation.

Hold where appropriate. Investigate quickly. Document the basis. Communicate carefully. Terminate when necessary. Reinstate when justified. Learn from the case.

Merchant monitoring is not supposed to be a panic button.

It is supposed to be governance.

What Platforms Should Be Doing Now

The practical readiness question is simple:

Can you investigate a suspicious merchant quickly without inventing the process under pressure?

If the answer is no, now is the time to fix it.

Start with onboarding. Are you collecting enough information to understand what the merchant sells, who controls the business, where the website lives, how fulfillment works, and what risk category the merchant belongs in?

Review website and offer monitoring. Can you tell if the merchant changes products, redirects traffic, adds misleading claims, or starts selling something different from what was approved?

Connect complaints to risk. Are support tickets, refund complaints, delivery issues, and dispute narratives visible to the team responsible for merchant monitoring?

Define escalation ownership. Who reviews scam merchant alerts? Who contacts the merchant? Who talks to the acquirer or PayFac sponsor? Who decides whether to hold funds, suspend processing, or terminate?

Clarify contracts. Do your agreements with merchants, platforms, PayFacs, processors, and acquirers allow fast action when scam activity is suspected or confirmed?

Preserve evidence. Can you produce onboarding records, website screenshots, transaction history, support complaints, refund patterns, dispute data, and investigation notes within hours, not weeks?

Train support. When processing is paused or a merchant is under review, support needs language that is accurate, controlled, and useful. “The processor did it” is not a customer communication strategy.

Test the workflow. Run a tabletop exercise before the real alert arrives. Pick a merchant, pretend a scam signal came in, and see how long it takes to gather the facts and make a decision.

If that exercise turns into a scavenger hunt, congratulations. You found the problem before Mastercard, your acquirer, or your sponsor bank found it for you.

The Takeaway

Mastercard’s scam merchant push is a warning shot.

The network is signaling that merchant risk needs to be identified earlier, investigated faster, and handled with more discipline. Merchant Trust Services points toward network intelligence and real-time analytics being used to distinguish legitimate merchants from risky ones before consumers are harmed.

The big lesson is not complicated.

Waiting for chargebacks is too late.

Scam merchants are getting better at looking legitimate. Fake storefronts can look polished. Deceptive offers can process normal card transactions. Consumer complaints may surface before ratios get ugly. Risk signals may be spread across onboarding, product, support, disputes, refunds, and transaction systems.

If your platform enables merchant acceptance, owns merchant onboarding, supports sellers, or controls the customer experience, merchant monitoring is part of your operating model whether you like it or not.

The networks are not waiting for chargebacks to prove a merchant is a problem.

Platforms should not either.

Want to get featured on the Cents Chat podcast? Complete our survey.