Delivery Payment Skimming: How Hackers Hijack Restaurant Payment Links

Delivery platform payment flows look seamless, but a short post that appeared on Hacker News reveals a troubling reality: attackers are systematically hijacking restaurants' payment links and quietly diverting delivery revenue that should land in merchant accounts.

An underrated attack surface

The post, titled "Restaurant Delivery Payment-Skimming Campaign," received 11 points on Hacker News—hardly a heated discussion. But the issue it points to deserves the attention of every consumer who orders through delivery platforms and every restaurant that relies on delivery revenue.

Payment skimming refers to attackers tampering with the payment path so that funds flow into accounts they control—without breaking the payment itself. Unlike traditional card skimming, this type of attack exploits trust gaps between platform and restaurant in link generation, redirection, and settlement.

From the original information, attackers have turned this into a "campaign"—not sporadic attempts, but organized, repeatable operations. That implies reusable techniques and tooling behind it, rather than one-off opportunistic fraud.

Payment skimming (payment-skimming) derives from traditional credit card skimming, which originally referred to attackers installing skimming devices on POS terminals or ATMs to steal card information. As payments moved online, the concept expanded to mean altering the flow of funds by tampering with payment paths, swapping payment links, or hijacking settlement parameters—without touching card data. Compared with directly stealing card numbers, payment skimming does not trigger the cardholder's transaction verification step, making it harder for end users to notice; it often only surfaces during reconciliation cycles.

Where link hijacking can happen

A delivery payment chain typically involves four stages: the user side, the platform order system, the payment gateway, and the restaurant's receiving account. If a link is replaced or a parameter is tampered with at any stage, the flow of funds can change.

Positions attackers may target include dedicated payment links generated in the restaurant back office, settlement entry points the platform sends to merchants, and payment configurations that can be modified in third-party delivery or ordering systems. Because these links are often distributed as URLs or QR codes, once attackers gain edit permissions or find a predictable generation pattern, they can replace them in bulk with their own receiving addresses.

For restaurants, the most dangerous part is the silence: orders complete as usual, customers pay as usual, the platform shows settlement as usual—and only during reconciliation does the amount fail to match.

A payment gateway is an intermediary system connecting merchants, acquirers, and card networks/clearing networks, responsible for encrypted transmission of transactions, authorization requests, and funds clearing. Delivery platforms typically embed payment gateways into the order flow as APIs or hosted checkout pages, with the merchant's receiving account identifiers (such as merchant ID and settlement account) passed as key parameters along the chain. Once these parameters are tampered with during generation, storage, or redirection, the payment gateway will still complete authorization normally, but cleared funds will flow into the account specified by the attacker—creating a silent skimming scenario of "transaction successful, funds misdirected."

Why the delivery scenario is especially fragile

The high-frequency, small-ticket, multi-merchant nature of delivery operations naturally amplifies the harm of this risk. Individual amounts are small, so anomalous transactions struggle to trigger risk-control thresholds; the number of merchants is large, making it hard for platforms to deeply verify each one; and because the delivery process involves integration across multiple systems, permission boundaries easily become blurred.

From the attacker's perspective, this is a volume business: the amount stolen per attempt is limited, but it can cover many merchants and orders simultaneously. The original post calls this a campaign, which precisely indicates that attackers are pursuing scale rather than single-point breakthroughs.

Risk-control thresholds are boundaries for amounts, frequency, or behavioral rules set by payment and anti-fraud systems to identify anomalous transactions. Traditional card risk control often triggers alerts based on dimensions such as single-transaction amount or multiple transactions within a short period. Delivery orders themselves are high-frequency, small-ticket, and multi-merchant, so the distribution of normal transactions heavily overlaps with attack behavior, making threshold-based rules hard to distinguish. Attackers exploit this gray area by keeping each theft below the threshold and relying on volume.

What restaurants and platforms can do

For restaurant operators, the most basic line of defense is to establish independent reconciliation habits: don't just look at aggregate numbers in the platform back office—verify actual deposits into the receiving account transaction by transaction. If a link or payment configuration is found to have been modified, relevant entry points should be frozen immediately and the platform contacted.

On the platform side, the generation and modification of payment links need stricter permission management and audit logs. Changes to receiving accounts should require secondary confirmation and a delayed activation mechanism, giving anomalous replacements a chance to be detected.

For consumers, this information is also worth noting: when ordering, if you encounter a payment page that redirects to a non-platform domain, or if the payee name clearly does not match the actual restaurant, be on your guard.

Audit logs are tamper-resistant records of who performed what change to which configuration, when, and from where—the foundation for post-incident tracing and accountability. For sensitive configurations such as receiving accounts and payment links, platforms should record pre- and post-change values, operator identity, source IP, and timestamps, and set alerting rules. A delayed activation mechanism keeps a cooling-off period after a change is submitted, during which it can be reviewed or revoked, providing a discovery window for anomalous replacements.

Limited information, but a clear signal

It must be acknowledged that the original post provides only a title and minimal engagement data, without disclosing the specific platform, details of the attack method, or scale of impact. Therefore, this article discusses the general mechanics and defensive approaches for this type of attack rather than a retrospective of a specific incident.

But the word "campaign" itself is a clear signal: payment skimming has evolved from single-point fraud into organized industrial activity, and the delivery payment chain needs to be treated as a serious security issue.

FAQ

What is delivery payment skimming?

It refers to attackers tampering with a restaurant's payment links or account configuration to redirect delivery fees paid by customers into accounts they control, rather than directly stealing card information.

Will consumers bear the losses?

Usually the financial losses fall first on restaurants and platforms, but consumers may face knock-on effects such as order anomalies and refund delays. It is worth paying attention to the domain of the payment page and the payee information.

How can restaurants quickly self-check?

Regularly verify actual deposits into the receiving account transaction by transaction, compare them with aggregate data in the platform back office, and check whether payment links and QR codes have been replaced.

One-line Summary

Delivery payment chains are being targeted by organized payment-link hijacking, with funds silently flowing into attacker accounts.

Paragraph Summary

A Hacker News post about a "Restaurant Delivery Payment-Skimming Campaign" reveals that attackers are tampering in an organized way with restaurants' payment links or account configurations on delivery platforms, diverting delivery revenue into accounts they control. This type of payment skimming does not directly steal card information; instead, it exploits trust gaps between platform and restaurant in link generation, redirection, and settlement, and is silent in nature. The high-frequency, small-ticket, multi-merchant nature of delivery makes anomalous transactions hard to trigger risk-control thresholds, and attackers use this to pursue scale effects. The article recommends that restaurants verify actual deposits transaction by transaction, that platforms implement permission audits and delayed activation for receiving-account changes, and that consumers be wary of payment pages on non-platform domains. The original information is limited, and the discussion focuses on general mechanics.