Payment Request Verification to Prevent Invoice Phishing

Checking payment requests comes down to one rule: never rely on the message itself to prove it’s real. Treat any invoice, wire request, ACH update, or “urgent” payment email as untrusted until you verify it through a separate, pre-known channel (a saved phone number, vendor portal, or in-person confirmation).

A good process is simple: verify the requester’s identity out-of-band, verify the destination account against your records, and require a second set of eyes for anything that moves money.

The threat you’re actually facing: “looks normal” payment fraud

Entrepreneurs rarely get hit by cartoonish phishing. The most expensive attacks look like routine business: a supplier sends an updated invoice PDF, a contractor “changed banks,” your bookkeeper gets a note from “you” asking for a quick transfer, or a client asks to pay via a new account. This is commonly grouped under business email compromise (BEC) and invoice fraud—where the attacker impersonates someone you already work with, often using a real thread, real names, and the right timing.

Your goal isn’t to “spot every fake.” Your goal is to make it operationally hard to get paid to the wrong place, even if someone on your team believes the email.

Define “payment request” broadly (or you’ll miss the real ones)

If you only scrutinize wires, you’ll still lose money through smaller but frequent channels. A “payment request” includes:

Any new invoice that changes where or how you pay
Any request to update bank details (wire/ACH/SEPA equivalents), payee name, or remittance address
Any request to pay faster than usual (“today,” “before EOD,” “we’ll stop shipment”)
Any request to buy gift cards, crypto, or “temporary” payments “until the portal works”
Any request that bypasses your normal workflow (“just reply with confirmation,” “don’t loop in AP”)

If it can redirect cash, it deserves verification.

The verification triangle: identity, destination, and authorization

A payment request is safe to execute only when all three checks pass:

1) Identity: prove who is asking

Do not “verify” by replying to the email thread. If the sender’s mailbox is compromised, the attacker receives your reply.

Use one of these out-of-band methods:

Callback to a saved number from your contacts/CRM/vendor master (not the email signature, not the invoice PDF).
Vendor portal message inside the platform you already use (procurement/accounting portal).
Live chat or ticket from the vendor’s official website—navigated by typing the domain yourself.
In-person or video call for high-value or first-time payments.

If you can’t reach them, you wait. “Urgency” is a tactic, not a requirement.

2) Destination: prove where the money is going

Even if the requester is real, the destination could be tampered with. Make destination verification a separate step:

Compare the bank account/routing/IBAN in the request against your vendor master record or prior paid invoices stored in your accounting system.
If it’s “new details,” treat it as a change request, not a payable invoice. That triggers stricter controls (below).
For new vendors, confirm the destination using documentation obtained independently (e.g., vendor portal banking page) and validate it during the out-of-band call.

Practical tip: keep a “last-known-good” payment profile snapshot for each vendor (bank details, payee legal name, billing contact). Changes should be rare—and therefore loud.

3) Authorization: prove your business approved it

Many scams succeed because one person can request and execute. Separate duties:

One person enters or prepares the payment.
A second person approves and releases it.
For owner-operated businesses, you can still enforce separation by using bank features (dual approval) or a “review then release” rule with a short delay.

Authorization should verify the business purpose, not just the numbers: what is being paid, for which PO/service, and whether it matches your normal terms.

A simple “Payment Request Check” workflow (usable tomorrow)

You want a checklist that’s short enough to use under pressure.

Step A: classify the request in 10 seconds

If any of these are true, it’s “high-risk” and needs extra verification:

Bank details changed (even “just the receiving account”)
New vendor or first payment
Unusual amount or timing
Pressure, secrecy, or “don’t follow the usual process”
Message came from a personal email or a new domain
Payment method is unusual for that vendor (gift cards, crypto, prepaid)

Step B: freeze the action, preserve the evidence

Don’t click attachments or links yet. Save what you have:

Keep the email, headers if available, and any invoice files.
If you already clicked, don’t panic—just stop and verify before paying.

Step C: verify out-of-band using your own contact info

Use a known channel and ask questions an attacker struggles with:

“We received a bank change request—can you confirm the old account ending digits we had on file?”
“What was the last invoice number we paid and the amount?”
“Which purchase order is this tied to, and who is your account manager on our side?”

If they can’t answer or try to move you back to email, treat it as suspicious.

Step D: validate the payment object itself

Before releasing funds:

Confirm invoice matches contract/PO/services delivered.
Confirm totals and payment terms match your agreement.
Confirm destination exactly matches your records (character-by-character on bank fields).

Step E: require a second approval above a threshold

Pick a number you can live with (e.g., $500, $2,000, $10,000). The point is consistency. Above that threshold:

Two-person approval required
If you’re solo, do a forced delay + second factor (e.g., enter today, release tomorrow after a fresh review)

Red flags that matter more than “bad grammar”

Modern payment scams often use perfect writing. The better signals are operational:

Bank change bundled with urgency (“new account effective immediately”)
New email domain that looks close to the real one (one letter swapped, extra word, different TLD)
Reply-to mismatch (From looks right, replies go somewhere else)
New contact claims to be “taking over” billing and pushes you to update details
Process disruption (“portal is down,” “use this temporary account”)
Unusual secrecy (“CEO request,” “keep it confidential,” “don’t involve AP”)
A real thread suddenly pivots to money after weeks of normal conversation

Treat any one of these as reason to switch to the high-risk workflow.

Make bank-detail changes hard by design

Most losses happen at the moment bank details change. Put this policy in writing (one page) and follow it every time:

Bank changes are accepted only via a defined method (vendor portal submission or a signed form)
Changes must be confirmed by callback to a known number
Changes require a cooling-off period (e.g., 24–48 hours) before first payment
First payment to a new account is limited (a test payment), when feasible
Any “urgent change” is automatically escalated (because it’s exactly what attackers ask for)

This does not need enterprise bureaucracy. It needs consistency.

Protect the places attackers exploit: inboxes and vendor records

You can reduce how often these requests appear by tightening two operational points:

Email account protections (the minimum that pays off)

Turn on multi-factor authentication for email and accounting tools.
Review mailbox rules/forwarding (attackers often create hidden forwarding rules).
Use a separate email alias for vendor onboarding, not your public-facing address.

Vendor master hygiene (your source of truth)

Keep vendor contact info and payment profiles in one system.
Lock down who can edit bank details.
Log changes (who changed what, when).
Periodically review recent changes—especially before large payment runs.

If you suspect a payment request is fraudulent

Your response should be as procedural as your prevention:

Stop the payment (or recall/cancel if still pending).
Call your bank immediately—speed matters for any chance of recovery.
Notify the real vendor using a known channel (they may be compromised too).
Secure accounts: reset credentials, invalidate sessions, check forwarding rules.
Document everything (emails, timestamps, account numbers used).

The core idea: treat it as an incident with financial urgency, not an “IT issue.”

Why does this matter

Payment-request phishing doesn’t need malware or technical failure—only one moment of trust in the wrong channel. A lightweight verification habit prevents irreversible losses, protects vendor relationships, and keeps your business from spending weeks untangling accounting and legal fallout after a single misdirected transfer.

Sources

Next Step: https://cyberspark.blog/2026/01/20/baseline-account-protection-settings-for-every-account/