← Back to blog
| Wesley Neelen

Abusing iDEAL (Wero): how criminals weaponise legitimate payment links in phishing

Blog

In the Netherlands, iDEAL (now transitioning to iDEAL | Wero) is the default way to pay online. Practically every webshop offers it, and for most consumers it is the most trusted step in a checkout flow: you get bounced to your own bank, you confirm in your own banking app, you are done.

During our security research, we keep running into the same abuse pattern, one that turns exactly this trust into the attack. Criminals do not need to break iDEAL. They only need to put a real, valid iDEAL payment in front of the wrong person.

A quick refresher on how iDEAL works

When a webshop wants to be paid, it asks an iDEAL acquirer/PSP to start a transaction. The acquirer returns a payment URL. The shopper is redirected to that URL, picks their bank, and finishes the payment in their banking app. Whoever opens it can pay it. The URL itself doesn't care which device, browser, or person initiated the purchase. It only cares that someone completes the payment.

That property is what makes the abuse work.

The abuse pattern

The pattern we keep observing is consistent across campaigns:

  1. The attacker picks a merchant that delivers something that's easy to cash out. We have seen banks, crypto exchanges, gift card resellers and debit card services being abused. Anything that converts a paid order into value the attacker can move anonymously within minutes.
  2. The attacker initiates a real, legitimate purchase on that merchant and proceeds all the way to the iDEAL redirect step.
  3. Instead of paying the redirect themselves, they keep the URL.
  4. They deliver that URL to a victim, over chat, in an email, or wrapped inside a phishing site pretending to be a trusted brand.
  5. The victim opens the URL, lands on a perfectly genuine iDEAL bank-selection page, authenticates in their own banking app, and confirms the payment.
  6. The merchant sees the order paid, releases the goods (crypto, gift card codes) to the attacker, and the victim is left with the cost.

Everything downstream of the captured URL is real. Real iDEAL flow, real bank UI, real confirmation screen, real funds movement. The only thing the victim could flag as "fake" is the merchant name shown in their banking app, the crypto exchange, gift card reseller, or other merchant the attacker actually checked out at.

Incorrect Merchant

Phishing sites

A phishing site impersonates a brand. By far the most common one using this technique is the Belastingdienst, framing the iDEAL link as a small tax payment. The phishing page wraps the captured iDEAL URL in branded UI, clicking the "Nu betalen" button drops the victim straight into a real iDEAL flow.

Belastingdienst-style phishing page presenting the iDEAL link as a small tax payment

Or sometimes the link is even shared via a simple chat.

Belastingdienst-style phishing page presenting the iDEAL link as a small tax payment

From the victim's banking app, what arrives is a normal iDEAL transaction, the amount is plausibly small, the flow looks like every other online payment they have ever done.

Why it works

A few properties of the iDEAL flow combine to make this a particularly slippery class of abuse:

  • The amounts are plausible. Attackers tune their cover stories so the iDEAL amount matches what a "Belastingdienst tax payment" or a marketplace item would believably cost. They are really leveraging the scale, obtaining many small payments.
  • The URL is not device bound. It is not bound to the device, browser, session, or IP of the person who initiated the purchase. Anyone who has the link can pay it.
  • The link is long-lived enough to socially engineer with. The window between link creation and expiry is comfortably larger than the time it takes to drop the URL into a chat or onto a phishing page and pressure the victim.

The result: a phishing flow that uses no fake payment page, no fake bank login, no credential capture, and still ends in money moving from victim to attacker.

Is there a fix?

Honestly, we don't know if there is already a solution that completely prevents this. We are publishing this in part because we want to find out.

The flaw is structural rather than technical: a payment URL that anyone can pay is, by design, a payment URL that anyone can be tricked into paying. This technique can be applied to any webshop that uses iDEAL.

There is one partial mitigation already in place: the bank confirmation screen does display the merchant name. That is what would tip off an attentive victim that the "Belastingdienst payment" is actually going to a crypto exchange. However, in practice consumers skim past it.

The simplest structural fix would be to bind the iDEAL link to the device, browser, or IP that initiated the purchase. A stranger receiving that URL through another channel would then be unable to complete the payment. This may have a real usability impact, so it may be best offered as an optional hardening for merchants in regularly-abused categories (crypto exchanges, gift card shops, etc.).

Takeaways

  • If you use iDEAL as a consumer: never pay an iDEAL link that someone else has handed to you, even if the bank screen looks perfectly normal. The bank screen being real is not evidence that the payment is for what you think it is.
  • Always verify what you are paying for, not just that the page is from your bank. Match the merchant name in your banking app against what you actually intended to buy.
  • If you are a merchant in a high-risk category (crypto, gift cards, prepaid services, anything liquid): assume your iDEAL links are being lifted and sideloaded onto unsuspecting victims.

We will keep tracking this pattern at Zolder and welcome pointers to existing work or in-flight mitigations. We expect this to grow, it's cheap to run and trivial to automate.