Inspiration

QR codes make payments fast and convenient, but they also hide an important detail from the user:

Where is the money actually going?

A QR image can look completely normal even when the data inside it has changed.

A payment QR may contain a different recipient, an unexpected amount, or modified payload data. A QR can also lead to a suspicious website instead of representing a payment at all.

This creates risks such as payment redirection, QR phishing or "quishing", data tampering, and social-engineering attacks.

We wanted to create a simple security checkpoint that allows users to inspect what is actually inside a QR code before they confirm a payment.

That became QRProof.

What it does

QRProof is a web-based financial cybersecurity tool for checking QR codes before payment.

Instead of trusting the appearance of a QR image, QRProof decodes and analyzes the underlying data.

It can inspect:

  • QR payment structure
  • Recipient or payment destination
  • Payment amount
  • Currency
  • Country
  • Reference information
  • CRC integrity
  • Payload completeness
  • Suspicious URL patterns

Users can provide QR data by:

  • Uploading an image
  • Dragging and dropping an image
  • Pasting an image from the clipboard
  • Using a camera
  • Pasting the decoded QR payload directly

QRProof then shows what the QR actually contains and explains why a result may require additional verification.

Payment destination verification

One of the core protections in QRProof is destination comparison.

The user can enter the recipient they expect to pay.

QRProof compares that expected destination against the recipient encoded inside the QR.

If they match, the check passes.

If they do not match, QRProof warns the user before they continue to their banking application.

This is designed to reduce the risk of payment-redirection attacks where a legitimate-looking QR has been replaced with one belonging to an attacker.

Amount verification

QRProof can also compare the expected payment amount against the amount encoded in the QR.

For example, if the user expects to pay 550 THB but the QR contains 600 THB, the system identifies the mismatch, increases the risk score, and recommends that the user stop and verify the payment.

QR integrity checking

QRProof parses payment QR payloads using their structured fields and validates the CRC value stored in the payload.

The system can identify cases such as:

  • Valid CRC
  • Invalid CRC
  • Missing CRC
  • Incomplete payload
  • Incorrect field length
  • Modified or damaged payload data

CRC validation helps detect data changes, but QRProof does not treat CRC as a digital signature.

It verifies data integrity, not the identity of the organization that originally created the QR.

Trusted Recipient Baseline

Users can save recipients they trust, such as:

  • Regular stores
  • Landlords
  • Service providers
  • Company accounts
  • Frequently used payment destinations

These trusted recipients are stored locally and can be used as a baseline during future checks.

If the destination suddenly changes, QRProof can warn the user instead of silently treating the new destination as normal.

Risk Score

QRProof combines multiple security signals into a risk score from 0 to 100.

Signals can include:

  • Invalid CRC
  • Recipient mismatch
  • Amount mismatch
  • Missing payment amount
  • QR containing a URL instead of payment data
  • Changes from a previously watched QR
  • Invalid or incomplete payload data

The score is designed as a decision-support signal.

It does not guarantee that a QR is safe or fraudulent.

QR phishing and suspicious links

Not every QR is a payment QR.

QRProof can distinguish between payment data and web links.

For URLs, it performs basic heuristic checks for patterns such as:

  • URL shorteners
  • Punycode domains
  • @ inside URLs
  • Unusual protocols
  • Other suspicious URL structures

This helps users notice when a QR may be attempting to redirect them to a phishing or fake-login page.

QR comparison and tamper detection

QRProof can compare two QR payloads and identify changes in:

  • Recipient
  • Amount
  • Reference
  • CRC
  • Payload data

This can help when comparing:

  • A QR displayed at a store with one sent through chat
  • Two versions of an invoice
  • A QR before and after forwarding
  • A QR suspected of being replaced or modified

Users can also add a QR to a watchlist.

If important information changes during a later inspection, QRProof can highlight the difference.

Human confirmation before payment

QRProof does not transfer money.

Before the user opens their banking application, they can review:

  • Recipient
  • Amount
  • Risk score
  • Verification results

The goal is to introduce one deliberate security step between:

Scanning a QR

and

Sending money

The core workflow is:

Scan → Decode → Verify integrity → Verify destination → Verify amount → Assess risk → Human decision

How we built it

QRProof was designed around deterministic inspection wherever possible.

The system parses structured QR payment payloads field by field instead of asking an AI model to simply decide whether an image looks suspicious.

It performs:

  • TLV-style payload parsing
  • Nested payment-field extraction
  • CRC16 validation
  • Destination comparison
  • Amount comparison
  • QR-to-QR comparison
  • Rule-based risk scoring
  • Suspicious URL heuristics
  • Trusted-recipient comparison

For image scanning, QRProof can use the browser's BarcodeDetector when available and fall back to another QR-reading method when necessary.

Image preprocessing such as contrast adjustment, grayscale conversion, and inversion can also help improve decoding.

Trusted recipients, history, settings, watchlist information, and language preferences can be stored locally in the browser.

Challenges we faced

One challenge was making the system useful without making dangerous claims.

A mismatched recipient does not automatically prove fraud.

A suspicious URL does not automatically mean malware.

And a valid CRC does not mean that a QR came from a legitimate bank or merchant.

Because of this, QRProof was designed to explain why something deserves attention instead of simply labeling everything as safe or fraudulent.

Another challenge was QR decoding reliability.

Different browsers provide different capabilities, and QR images can have poor contrast, unusual colors, or other visual issues.

We therefore included multiple ways to provide QR data and a fallback path where users can paste the raw payload directly.

What we learned

Building QRProof showed us that cybersecurity is not only about detecting malware after something goes wrong.

A useful security system can also introduce a verification checkpoint before a high-risk action happens.

For QR payments, the important question is not only:

"Does this QR look real?"

but:

"What recipient, amount, and data are actually encoded inside it?"

We also learned the importance of separating data integrity from authenticity.

CRC can detect certain changes to a payload, but it is not a cryptographic signature and cannot prove who created the QR.

What's next

Future versions of QRProof could add:

  • Threat-intelligence services for URL reputation
  • Stronger merchant and recipient verification
  • Shared trusted-recipient lists for organizations
  • Additional payment QR standards
  • More advanced phishing detection
  • Secure cloud synchronization
  • Integration with payment or banking workflows

QRProof is currently designed as a security assistant, not a replacement for a banking application.

Our goal is simple:

Inspect the real data before the user sends real money.

Built With

  • anti-phishing
  • api
  • application
  • barcodedetector
  • code
  • crc16
  • decoder
  • fraud
  • image
  • localstorage
  • parser
  • payment
  • prevention
  • processing
  • qr
  • security
  • tlv
  • web
Share this project:

Updates

Submission history