The payment was authorized.
That used to feel like a clean answer.
It is not anymore.
Scams and social engineering have made payments messier because the customer may technically approve the transaction while being manipulated into doing it. The login can be valid. The credential can be valid. The device can be familiar. The customer can click the button.
And the transaction can still be harmful.
That is the uncomfortable middle ground where old fraud models start sweating.
Payments has historically loved clean categories. Authorized or unauthorized. Fraud or dispute. Customer initiated or merchant initiated. Good merchant or bad merchant. Valid credential or stolen credential. Approved transaction or declined transaction.
Scams do not care about your categories.
A scammer does not need to steal a card if they can convince the customer to use it. They do not need to break the bank if they can manipulate the person. They do not need to bypass every authentication control if they can talk the victim through the authentication flow like a very evil onboarding specialist.
That means payment companies need to ask a harder question.
Not just, "Was the payment authorized?"
But, "Was the payment safe?"
Visa's Spring 2026 Biannual Threats Report said scams have become the fastest-growing source of consumer harm as criminals increasingly use AI and social engineering to manipulate people into authorizing payments themselves. Visa also said it identified nearly $1 billion in scam-related activity from July to December 2025, making scams the single largest category of consumer payment fraud during that period. Visa's Spring 2026 threat report announcement is available here.
That is not a small shift.
It means fraud is not only about compromised credentials, stolen cards, bot attacks, account takeover, or synthetic identities. Those still matter. But the fastest-growing harm is increasingly about manipulation.
Fake investment opportunities. Impersonation. Romance scams. Fake merchants. Fake support. Urgency tactics. AI-generated messages. Deeply convincing phishing. Business email compromise. Vendor impersonation. Payroll redirection. Purchase scams. Refund scams. People being guided into doing exactly the thing the scammer needs them to do.
The payment may look legitimate because the victim made it legitimate.
That is the problem.
Authentication is important.
It proves something about access.
It does not prove the user made a good decision.
A user can authenticate while under pressure. A business user can approve a vendor payment after being fooled by a convincing email. A consumer can authorize a purchase from a fake merchant. A payroll administrator can change payment instructions because an imposter sounded believable. A customer can complete step-up authentication because the scammer told them it was necessary to "secure the account."
The control worked.
The customer still got harmed.
That does not mean authentication failed. It means authentication was asked to solve a problem it was never designed to solve.
Authentication can help determine whether the person using the credential is likely the authorized user.
It cannot always determine whether the authorized user is being manipulated.
That distinction is going to matter more as scams get better.
Payment companies often rely on authorization status as the end of the risk conversation.
The transaction was approved.
The customer authenticated.
The credentials were valid.
The system worked.
Maybe.
But in scam scenarios, those facts may only tell you that the rails functioned. They do not tell you whether the outcome was safe, fair, expected, or recoverable.
That does not mean every authorized scam payment becomes the provider’s liability. Liability depends on rail, rules, facts, contracts, regulations, and many other things lawyers get paid to argue about in rooms with unfortunate lighting.
But operationally, "authorized" is not enough.
If scam patterns are increasing, companies need to understand where those scams appear inside their ecosystem. Which merchants generate complaints? Which transaction types are tied to customer harm? Which support themes repeat? Which affiliates, channels, or landing pages produce disputes? Which payment flows are being manipulated? Which customer segments are most exposed? Which transactions are authorized but later regretted, disputed, or reported?
Authorized payment data without context is a very polished blindfold.
Scam risk is not only a consumer education problem.
Merchants matter.
Some scam activity is tied to fake merchants. Some is tied to misleading merchants. Some is tied to merchants that technically sell something but do it in a way that creates consumer harm. Some is tied to aggressive subscription practices, confusing terms, hidden cancellation paths, poor fulfillment, fake urgency, deceptive ads, or affiliate traffic that says things the merchant would never admit in underwriting.
That means acquirers, PayFacs, processors, ISVs, and platforms need to monitor merchant behavior after approval.
If a merchant generates recurring complaints that customers were misled, that is a signal.
If customers repeatedly say they did not understand they were subscribing, that is a signal.
If chargebacks cluster around "merchandise not received" or "not as described," that is a signal.
If refunds spike after a marketing campaign, that is a signal.
If the merchant’s website changes after approval, that is a signal.
If support tickets sound like scam victims describing the same script, that is a signal.
Signals do not help if nobody connects them.
AI does not create dishonesty.
Humanity had that feature pre-installed.
What AI can do is make manipulation more scalable, more personalized, and harder to detect. Scam scripts can be generated faster. Phishing messages can be cleaned up. Voice and image tools can make impersonation more convincing. Social engineering can be customized to the victim. Fake merchants can generate better content. Bad actors can test messages, refine them, and deploy them at scale.
That changes the economics of scams.
If manipulation becomes cheaper, faster, and more believable, payment companies cannot rely on customers spotting every red flag.
Customer education helps.
It is not enough.
A serious response needs monitoring, merchant controls, transaction context, customer support feedback, data sharing, friction in the right places, and systems that can identify when a technically authorized payment is behaving like part of a scam pattern.
The goal is not to infantilize customers.
The goal is to stop pretending that "they clicked it" explains everything.
Scam risk does not live only in the fraud department.
It lives in product design.
How easy is it to add a new payee? How easy is it to change payment instructions? How quickly can funds move after a new account is added? What warnings are shown? Are warnings generic wallpaper, or do they appear when the risk actually changes? Can suspicious transactions be paused? Can support teams see relevant context? Can customers report scams easily? Can merchants modify billing terms without review? Can affiliate links drive customers into confusing checkout experiences?
Product choices create scam surface area.
A fast flow with no friction may improve conversion.
It may also improve scam throughput.
That does not mean every risky flow needs to become painful. It means friction should be intentional. Add friction where the risk changes. Step up approval where the transaction is unusual. Hold funds where reversibility is limited. Review merchant changes where customer harm could increase. Treat payment instruction changes like risk events, not profile edits.
Scammers love workflows that are optimized only for speed.
Customer support is often where scam signals appear first.
That is inconvenient because support data is usually messy, emotional, inconsistent, and trapped in ticket systems that fraud teams may not review.
Too bad.
Support is a fraud sensor.
When customers say they were tricked, misled, pressured, confused, subscribed without understanding, unable to cancel, told to move money, or asked to ignore warnings, those are not just customer service issues. They are risk signals.
If support themes do not feed into fraud strategy, merchant monitoring, product changes, and escalation paths, the company is ignoring the people describing the harm in real time.
That is a choice.
Usually a bad one.
Start by separating authorization from safety. Keep authentication and authorization controls, but stop treating them as the whole fraud conversation.
Map where scams could occur in your ecosystem. Merchant onboarding, checkout, subscription flows, account changes, payee creation, payouts, customer support, refund workflows, affiliate traffic, and payment instruction changes all deserve attention.
Connect data sources. Fraud alerts, disputes, support tickets, merchant monitoring, chargebacks, refunds, complaint themes, transaction velocity, and onboarding records should not live in separate rooms ignoring each other.
Review merchant behavior. Scam risk often shows up in patterns. Complaints, refunds, chargebacks, descriptor confusion, fulfillment problems, website changes, and marketing claims can all matter.
Add friction where the risk changes. Do not slow down everything. Slow down the risky things: new recipients, high-dollar transactions, unusual behavior, changed payment instructions, suspicious merchants, and activity that does not fit the customer or business.
Preserve evidence. When a scam is reported, you need to know what happened. What did the customer see? What did the merchant say? What warnings appeared? What approvals occurred? What device and account behavior was present? What support interactions happened?
If you cannot reconstruct the story, you cannot learn from it.
The payment was authorized.
That does not mean it was safe.
Scams and social engineering are changing the fraud conversation because criminals increasingly manipulate people into approving transactions themselves. That breaks old models that equate valid credentials and authorization with acceptable risk.
If you are an ISV, PayFac, platform, merchant, processor, marketplace, or payment company, now is the time to look beyond the approval response. Understand the story around the payment. Watch merchant behavior. Listen to support signals. Connect disputes and complaints back to product workflows. Add friction where the risk changes.
Payments Therapist helps payment companies understand where fraud strategy, merchant monitoring, customer harm, product design, payment operations, and risk controls do not line up.
"Authorized" is an important fact.
It is not the whole truth.