Fake merchant over-charge refund-claim lure — "We over-charged you €47, click for refund" reciprocity-bypass that bypasses urgency-lexicon FP control because the framing is positive (refund coming TO user, not demand FROM user). Sender NOT on the merchant canonical-allowlist (stripe.com, paypal.com, amazon.com/.co.uk/.de, apple.com, icloud.com, visa.com, mastercard.com, americanexpress.com, discover.com, klarna.com, adyen.com, square.com / squareup.com, shopify.com, ebay.com, etsy.com, wise.com, revolut.com). Real merchant refunds credit the original payment method automatically — never require the user to click an inbound link and verify bank / card details. Distinct from R6/R8 generic merchant-spoof — this signal is specifically the refund / over-charge / reciprocity variant. Source: Red-Team R7 multi-agent council S2 (social-engineering specialist).

Fake merchant over-charge refund-claim lure targeting consumers across the merchant-payment ecosystem (Stripe / PayPal / Amazon / Apple / Visa / Mastercard / Klarna / Adyen / Square / Shopify / eBay / Etsy / Wise / Revolut). The phish narrative arrives as: "A recent payment processing error caused us to over-charge your account by €47.32. To receive your refund, click the link below and verify your bank details. Refund will be processed within 24 hours," or "Our review of your Amazon order found an overcharge of $89. Click below to claim your refund and verify your card details for credit. Refund processing in progress." Reciprocity-bypass framing — the lure inverts the urgency-lexicon FP control because the framing is positive (refund coming TO user, not demand FROM user), so the user's instinct is to "act fast to receive money" rather than "scrutinise an unexpected demand." Lookalike merchant-refund portals harvest credit / debit card details + bank-account numbers + routing / IBAN + sort-code / SEPA + (in over-charge variants targeting Apple / Amazon) Apple ID / Amazon credentials, enabling subsequent ACH / SEPA / card-fraud and account takeover. Real merchant refunds credit the original payment method automatically — never require the user to click an inbound link and verify bank / card details. Sender NOT on the merchant canonical-allowlist (stripe.com, paypal.com, amazon.com / .co.uk / .de, apple.com, icloud.com, visa.com, mastercard.com, americanexpress.com, discover.com, klarna.com, adyen.com, square.com / squareup.com, shopify.com, ebay.com, etsy.com, wise.com, revolut.com). Distinct from R6 / R8 generic merchant-spoof (account-suspension / payment-decline pretexts) — this signal is specifically the refund / over-charge / reciprocity variant where the framing is positive rather than coercive. Fires when body contains "we over-charged you" / "over-charged you" / "we over-charged" / "overcharge (detected/found/reported/of $X)" / "found an overcharge" / "duplicate charge" / "billing error" / "charged twice" / "wrong amount charged" / "charged in error" / "payment processing error" AND "claim (your) refund" / "click (here) for refund" / "refund (pending/processing/will be processed-credited/of $N/€N/£N)" / "verify (your) bank-card-payment-account details" / "verify your bank account-details" / "update your bank details" CTA AND merchant-context (Stripe / PayPal / Amazon / Apple / Visa / Mastercard / Amex / order / invoice / payment / merchant / bank / charge). Excludes the canonical merchant-issuer domains. Auto-classified as danger via the `-lure` suffix. Source: Red-Team R7 multi-agent council S2 (social-engineering specialist).