Payment fraud rarely begins with a technically sophisticated attack. More often, it begins with something designed to end a conversation quickly: a convincing payment screenshot, a green success message, or a link that looks close enough to a trusted brand.
The difficult part is that each of these artifacts can look legitimate in isolation. A polished screenshot can be edited. A phishing page can have HTTPS. A valid-looking transaction reference can still be copied from another payment.
That is why a useful verification system should not ask only, “Does this look real?” It should combine independent signals and keep the final authority outside the untrusted artifact.
I have been working on this problem while building ScamDekho, a set of scam-checking tools focused on common Indian fraud patterns. This article explains the safety-first workflow behind that work and how developers or merchants can adapt it.
Start with the right trust boundary
A screenshot is evidence of what appears on the sender's screen. It is not proof that money reached the recipient.
For a merchant, the trusted source is their own bank account or UPI transaction history. The safest operational rule is therefore simple:
Do not release goods, issue a refund, or mark an invoice as paid until the credit appears in an account you control.
Everything else in the workflow is triage. It can reveal warning signs, prioritize manual review, and help explain why an artifact looks suspicious, but it should not override settlement data from the recipient's bank.
Why single-signal detection fails
Many quick checks are useful but weak when used alone:
- HTTPS protects a connection; it does not prove that the site owner is honest.
- A young domain can be risky, but every legitimate new business also starts with a young domain.
- A strange UPI handle can provide context, but wording alone does not prove that an image was edited.
- A different font may indicate pasted text, but compression, device rendering, accessibility settings, and app updates can also change appearance.
- A transaction ID that looks valid may have been copied from an unrelated payment.
A better system treats these as contributing signals. Confidence should rise only when multiple independent observations point in the same direction.
Layer 1: Confirm settlement out of band
Before analyzing pixels or domains, check the destination account directly.
The verification flow should never ask the sender to provide more evidence from the same device. A second screenshot or screen recording still comes from the untrusted side of the transaction. Instead:
- Open the merchant's bank or UPI application independently.
- Check the transaction history and current balance.
- Match the amount, time, and payer details where available.
- Treat “pending” as unpaid until the bank confirms otherwise.
For a staffed shop, turn this into a written policy. Fraud succeeds when an employee feels pressured to make an exception.
Layer 2: Triage the payment screenshot
Screenshot analysis is most useful when it explains evidence rather than returning a mysterious score.
A layered image review can consider:
App identity and component consistency
Does the visible receipt resemble the named payment application? Are the header, icons, spacing, status components, and wording internally consistent? This should allow for app versions, device sizes, languages, and legitimate layout changes.
Transaction-field coherence
The amount, payer or payee details, provider labels, dates, and transaction identifiers should make sense together. No single identifier format should be treated as universal proof because formats can change across providers and payment flows.
Local editing evidence
Pasted amounts and status labels can leave local differences in anti-aliasing, alignment, edge sharpness, compression, or background texture. These findings are stronger when they appear in a small edited region while the surrounding screenshot remains consistent.
Known-fake patterns
Scammers often reuse templates. Carefully bounded exact or perceptual signatures can identify repeated samples, while avoiding broad matches that could incorrectly flag legitimate receipts.
I made a public version of this workflow available in ScamDekho's payment screenshot checker. It combines local pattern checks with visual analysis and returns an evidence-based verdict. The page deliberately reminds users that the result cannot confirm bank settlement.
Layer 3: Analyze every associated link
Payment fraud frequently includes a URL: a refund form, a fake support page, an “invoice,” a KYC update, or a page asking the victim to scan a QR code.
A safe URL pipeline should begin without opening the destination in a normal browsing session. Useful checks include:
Normalize the hostname
Extract the effective hostname, convert internationalized domain names to a consistent representation, and look for misleading subdomains or character substitutions. The trusted brand should appear in the registrable domain, not merely somewhere to the left of it.
Check reputation and age
Compare the URL and domain against phishing or malware intelligence, then consider registration age and historical reputation. A clean result is not a guarantee: newly created attack domains may not have been reported yet.
Inspect TLS without over-trusting it
Certificate validity matters for secure transport, but free certificates are available to attackers too. Treat TLS as one input, not a legitimacy badge.
Look for impersonation patterns
Page content can reveal fake login forms, urgent payment language, brand impersonation, forced downloads, and requests for credentials or one-time passwords.
The companion ScamDekho website and link checker applies this multi-signal approach and reports the reasons behind its SAFE, SUSPICIOUS, or SCAM assessment. As with image analysis, the report should support a decision rather than replace human judgment.
Layer 4: Use conservative decision logic
The most important design decision is what happens when evidence is incomplete.
For a payment workflow, uncertainty should not silently become approval. A simplified policy might look like this:
function paymentDecision({ bankCredit, screenshotVerdict, linkVerdict }) {
if (bankCredit === "confirmed") return "ACCEPT_PAYMENT";
if (screenshotVerdict === "scam" || linkVerdict === "scam") {
return "BLOCK_AND_REVIEW";
}
return "WAIT_FOR_BANK_CONFIRMATION";
}
Notice that a SAFE screenshot does not return ACCEPT_PAYMENT. Only independently confirmed credit does that.
Layer 5: Preserve evidence and respond safely
When a case is suspicious:
- Do not click links or call phone numbers supplied by the suspected sender.
- Preserve the original screenshot and message rather than repeatedly resaving them.
- Record the sender identifier, URL, amount, time, and transaction reference shown.
- Contact the bank or payment provider through its official application or website.
- Train staff not to issue a “refund” for money that never arrived.
- Report the incident through the appropriate cybercrime channel when necessary.
The goal is not to argue with the sender. It is to slow the process down, preserve evidence, and move verification to trusted channels.
What automated tools should communicate
Security interfaces can create dangerous confidence if they present a score without limitations. A responsible result should show:
- the verdict and confidence or evidence level;
- the specific signals that contributed to it;
- which checks could not be completed;
- the difference between “no known threat found” and “proven safe”;
- a clear next action for the user;
- a reminder that bank settlement must be checked independently.
False positives and false negatives are both possible. App interfaces change, screenshots are compressed, threat-intelligence feeds lag behind new attacks, and legitimate domains can be compromised. Transparent explanations make those limits easier to handle.
The broader engineering lesson
Fraud detection works best as a system of independent controls:
- Authoritative confirmation from the bank or account owner.
- Artifact analysis for visible manipulation and internal inconsistency.
- Infrastructure analysis for domain, reputation, and delivery risks.
- Conservative policy when evidence is missing or conflicting.
- Human escalation for high-value or ambiguous cases.
No individual layer is perfect. Together, they make it much harder for one convincing screenshot or polished phishing page to control the decision.
If you are building a payment, marketplace, support, or moderation workflow, keep the trust boundary explicit: analyze untrusted evidence, explain the signals, and let an authoritative source make the final call.
Disclosure: I am the founder of ScamDekho and built the tools linked above. This post describes the design principles and limitations behind them, not a guarantee that automated analysis can identify every scam.
Top comments (0)