Payment Request Scams: Verify Before You Approve

Before approving a payment request, check what action the screen will perform. A claim that you are receiving a refund, selling an item or fixing an account does not make an outgoing payment safe. This guide explains verification and response for readers using different payment services around the world.

A request is not proof that you owe money

A payment request or invoice asks you to pay. It does not independently establish a legitimate purchase, debt or sender. PayPal documents scams involving both fake emails and requests sent through its own service, including invoices for unordered goods and alarming notes with fake support numbers. PayPal’s invoice and request-scam explanation.

This distinction matters: checking that a request appears inside the genuine app can establish where it was sent, but you still need to establish why you should pay it. Likewise, a familiar contact name can belong to an account someone else controls.

Read the action, not just the story

Before authorizing anything, identify the recipient, amount, currency, funding source and any recurring-payment permission. Different services use different confirmation screens. Do not assume a rule about one payment network’s PIN or collection feature applies to every app.

These are illustrative verification questions, not a claim that every unexpected request is fraudulent. Real invoices and refunds exist; the goal is to establish the transaction through trustworthy evidence.

Verify an unexpected request in five steps

1. Pause the conversation. Do not authorize a payment while someone talks you through unfamiliar screens.
2. Open the genuine app or a previously verified website independently.
3. Review the request and your transaction history. Compare it with an order, agreement or expected payment you recognize.
4. Verify the person or business through a separate trusted channel. Avoid numbers included in a suspicious invoice note.
5. If the purpose remains unexplained, decline or report the request using the provider’s own controls.

The FTC advises checking recipient information and speaking to a familiar person before acting on an unexpected request. Its guidance also warns that money sent to a scammer through a payment app can be difficult to recover. FTC payment-app guidance. This is useful prevention guidance, not a universal description of refund rights.

Example: report a suspicious PayPal request

For PayPal, its current help page describes opening the request in Activity, using the report option and following the prompts. It also describes cancelling on the website or declining in the app. Use the current controls shown in your account; interface labels and availability can change. PayPal’s reporting instructions.

Other providers have their own processes. Find their help through the genuine app or verified website rather than copying these instructions to a different service.

If you already approved or sent money

Contact the payment provider promptly and explain what happened. Distinguish a transaction you authorized after deception from one you did not authorize; give an accurate account rather than selecting a category only because it seems more likely to receive a refund. If a linked bank or card is affected, contact its genuine support too.

Ask about the applicable reporting, account-security and transaction-dispute process. Outcomes depend on the service, transaction and local rules. This article cannot promise a reversal. If you exposed a password or code, follow the provider’s recovery instructions from a trusted device. Our OTP scam guide explains why code exposure needs separate attention.

Keep transaction references, times, messages and support acknowledgments. Report to the relevant police, cybercrime or consumer-protection service for your location when appropriate. Be cautious of further requests for fees to recover the loss.

A small verification worksheet

• Expected purpose: What agreement or purchase does this payment settle?
• Verified recipient: How did I confirm who controls the destination?
• Actual action: What will approval do?
• Independent evidence: What does my account show?
• Unresolved question: What must be clarified before I proceed?

This original worksheet helps slow down a decision; it does not certify a transaction as safe. For a broader plan, use our online-safety guide.

Glossary

• Payment request: a request for someone to send money.
• Invoice: a bill claiming payment for specified goods or services.
• Authorization: approval of a transaction or permission.
• Recurring payment: an arrangement permitting repeated payments.
• Independent verification: checking through a trusted route separate from the request.

Sources and editorial review

Updated 1 October 2026. Provider instructions are scoped to the named service; FTC guidance supplies documented prevention advice. Examples and the worksheet are editorial aids. No transaction, recovery service or app performance was tested for this article. Reporting and payment protections vary by location. Send corrections through our contact page.

Written and prepared by Kshitij Gupta.

Global Instant Payment Rails & Collect-Request Rules (Zelle, Venmo, Faster Payments, SEPA & UPI)

Global Instant Payment Rails & Collect-Request Rules (Zelle, Venmo, Faster Payments, SEPA & UPI)

Technical Anatomy of Modern Payment Request & Vendor Invoice Fraud (BEC)

Financial fraud has shifted from unauthorized card theft (where the bank or card network absorbs the chargeback liability under Regulation E or Visa/Mastercard Zero Liability rules) to Authorized Push Payment (APP) fraud and Business Email Compromise (BEC). In an APP or BEC attack, the attacker manipulates the victim into voluntarily authorizing a push transfer—turning the account holder’s own cryptographic signature or MFA approval against them.

1. Email Header & Lookalike Domain Forensics: Spotting Vendor Impersonation in 30 Seconds

When an attacker intercepts a real invoice thread (often by compromising a vendor’s Microsoft 365 or Google Workspace mailbox via an OTP/session hijack and creating a hidden inbox forwarding rule for keywords like invoice, wire, ACH, or remittance), they use three technical deception techniques:

• Lookalike & Punycode Homograph Domains: Registering a visual twin of the supplier’s domain (for example, replacing m with rn, l with 1, or using Internationalized Domain Name Punycode prefixes xn--) so a glance at the sender line appears identical to the real vendor.
• From vs. Reply-To Header Split: Sending from a compromised or display-name-spoofed address while setting the Reply-To: header to an external attacker-controlled mailbox so any email inquiry goes straight to the fraudster.
• PDF Invoice Bank-Routing Substitution: Preserving the exact line items, purchase order numbers, and tax totals from the real vendor’s invoice while swapping only the ABA routing number, SWIFT/BIC code, IBAN, or crypto wallet address in the PDF footer.

# Raw Email Header Inspection Checklist (View Original / Show Original in Gmail or Outlook):
# 1. Compare From: domain against Return-Path: and Reply-To: domains
From: "Accounts Receivable - Acme Corp" <billing@acmecorp.com>
Reply-To: "Accounts Receivable" <ar-settlement@acrnecorp.com>   # <-- ALERT: Lookalike 'rn' vs 'm' domain!

# 2. Verify Authentication-Results header for strict alignment:
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@acrnecorp.com designates ...)
       dkim=pass header.i=@acrnecorp.com
       dmarc=pass (p=REJECT) header.from=acrnecorp.com
# Note: SPF/DKIM/DMARC 'pass' on a newly registered lookalike domain (acrnecorp.com)
# only proves the attacker owns the lookalike domain—NOT that it is your real vendor!

2. Settlement Finality & Reversibility Matrix by Payment Rail (2026)

Understanding why scammers insist on specific payment rails requires examining the clearing and settlement architecture of each network—specifically whether the rail is a credit push (irrevocable once settled) or a debit pull (subject to statutory dispute rights):

3. The Mandatory Four-Point Out-of-Band Verification Protocol

Whether you are managing accounts payable for a business or approving a personal payment request, enforce these four non-negotiable verification gates:

1. Out-of-Band Voice Callback on Every Routing Change: Treat any email requesting a change to a vendor’s bank account, ACH routing number, or payment method as hostile until verified by calling a phone number retrieved from your historical vendor master file or an official contract signed prior to the email thread.
2. Platform-Native Invoice Inspection: When you receive an email claiming “You have a new PayPal/Venmo/QuickBooks payment request — call +1-800-… to cancel,” never call the phone number written inside the scammer’s note field. Open a clean browser tab, type the payment service’s official domain directly, and inspect your transaction activity inside the authenticated dashboard.
3. Dual-Control Approval Thresholds: Configure business banking and ERP portals so any new payee creation or wire/ACH transfer above a fixed threshold requires two independent hardware-authenticated approvers (maker-checker separation).
4. Cross-Link with Related Fraud Defenses: Pair payment verification with WhatsApp Task & Deposit-Trap Triage, Fake Fine & Smishing Link Verification, and Deepfake Voice-Clone Out-of-Band Challenge Codes.

Enterprise Accounts Payable & Personal Treasury Controls Against Push-Payment Fraud

Because instant payment rails (Zelle, RTP, FedNow, UPI, Faster Payments, SEPA Instant, and Fedwire) prioritize sub-second clearing speed over post-settlement dispute reversibility, effective defense must operate pre-authorization. Once an authorized push payment (APP) leaves your bank account, the funds are typically hopped across two to three mule accounts or converted into stablecoins within 15 minutes.

1. How Attackers Weaponize Compromised Vendor Mailboxes (Silent Inbox Rules)

In a classic Business Email Compromise (BEC) vendor-impersonation attack, the criminal does not guess when you have an upcoming invoice—they watch your vendor’s real email inbox for weeks before striking:

• Stage 1 — Credential or Session Capture: The attacker compromises an accounting or sales employee’s Microsoft 365 or Google Workspace mailbox at one of your real suppliers.
• Stage 2 — Hidden Inbox Rule Creation: Instead of sending spam immediately (which would alert the employee), the attacker creates a silent server-side inbox rule in Outlook/Exchange or Gmail that automatically copies and hides incoming emails containing words like invoice, payment, remittance, wire, ACH, or overdue, moving replies to the RSS Subscriptions or Conversation History folder.
• Stage 3 — Thread Hijacking & PDF Alteration: The moment the real supplier emails you a legitimate $25,000 PDF invoice, the attacker intercepts the thread and sends a follow-up message 20 minutes later—either from the real compromised mailbox or a 1-character lookalike domain—stating: “Please note our primary operating account is undergoing an annual audit; kindly remit this invoice to our updated treasury routing details attached.”

# PowerShell / Exchange Online Audit Command to Detect Hidden BEC Inbox Rules:
# Administrators should run this weekly across all finance and executive mailboxes:
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName | Where-Object {
        $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage -or $_.MoveToFolder
    } | Select-Object MailboxOwnerId, Name, Enabled, ForwardTo, RedirectTo, MoveToFolder
}

2. Consumer & Small-Business Peer-to-Peer (P2P) Payment Traps Ranked by Frequency

Outside corporate invoicing, four P2P and instant-payment deception patterns account for the vast majority of consumer financial losses:

3. Hour-by-Hour Emergency Recovery Protocol If You Already Approved a Fraudulent Transfer

When a fraudulent wire, ACH, or P2P payment is authorized, recovery odds decay exponentially after the first 24 hours. Execute these five steps immediately:

1. Minute 0–15 (Call Your Bank’s Wire/Fraud Desk & Request a SWIFT/Fedwire Recall): Contact your bank’s wire room immediately, state that the transaction is a fraudulent BEC/scam transfer, and request an immediate Hold Harmless / Indemnity Wire Recall (and an ACH reversal if sent via ACH). Ask for the IMAD/OMAD tracking number (for Fedwire) or UETR (for SWIFT) so law enforcement can trace the receiving bank.
2. Minute 15–30 (Contact the Receiving Bank’s Fraud Department Directly): Look up the ABA routing number or SWIFT BIC on the fraudulent invoice to identify the receiving bank, call their fraud department directly, and provide the IMAD/OMAD reference and receiving account number so they can place an internal compliance freeze on the mule account.
3. Minute 30–60 (File an Emergency Report with National Financial Crime Clearinghouses):
   • United States: File immediately at ic3.gov (FBI Internet Crime Complaint Center) so the Recovery Asset Team (RAT) can issue a Financial Fraud Kill Chain (FFKC) freeze request through FinCEN.
   • United Kingdom: Call your bank via 159 and report to Action Fraud (applying the Contingent Reimbursement Model / mandatory APP reimbursement rules).
   • European Union / Global: Report to your national CERT/police cybercrime unit and provide the SWIFT UETR to initiate an interbank recall.
4. Preserve Full Forensic Evidence: Export the original email as an .eml or .msg file (which preserves the complete cryptographic Received:, Authentication-Results:, DKIM-Signature:, and Reply-To: headers—screenshots delete these headers), save the unaltered PDF invoice, and record all transaction IDs.