Why some payment methods cannot receive funds

"Why do you not support iDEAL? Everyone uses it in the Netherlands." The question is fair, and the answer is not commercial. iDEAL cannot receive funds. It is not a limitation we have yet to lift: it is what the rail is.

The distinction between a rail that collects and a rail that disburses shapes the whole payments landscape. Once you see it, the list of payout methods on any service stops looking arbitrary.

Push and pull: two directions, two infrastructures

A push rail moves money from the sender's account to the beneficiary's, on the sender's instruction. A SEPA transfer, a PIX, a Nigerian NIP are push rails. The sender triggers it, and the beneficiary does nothing.

A pull rail works the other way: the beneficiary — typically a merchant — presents a payment request and the payer authorises it. A SEPA direct debit, a card payment, an iDEAL payment are pull rails. Money flows from payer to merchant, but the initiative belongs to the merchant.

A service that must pay you needs a push rail. A pull rail, by construction, cannot do that: there is no "send funds" message in its protocol.

The concrete cases, one by one

iDEAL, Netherlands

iDEAL initiates a transfer from your bank to a merchant, authenticated in your banking app. The protocol has no reverse operation.

What we do instead: your iDEAL account sits on a Dutch IBAN. We credit that IBAN over SEPA Instant, usually in under ten seconds. The effect on your balance is identical; only the path differs.

Bizum, Spain

Bizum enables transfers between Spanish individuals through a phone number. The scheme does not accept disbursement from a foreign company: that is not a technical question, it is a rule of the service.

Instead, we credit the Spanish IBAN your Bizum is attached to, over SEPA Instant.

BLIK, Poland

BLIK generates one-time codes for paying. The code authorises a debit; it does not receive a credit.

Instead: your Polish bank's IBAN, credited over SEPA — or, through our partner, on the Polish domestic instant rail.

TWINT, Switzerland

TWINT is an application layer on top of your Swiss bank account. Receiving a disbursement from a foreign third party is not part of the scheme.

Instead: the matching Swiss IBAN, credited by transfer in CHF or EUR.

Zelle, United States

The most misunderstood case. Zelle technically works between US bank accounts and settles in minutes. But its terms of use restrict the service to transfers between people who know each other and contractually forbid third-party commercial disbursement.

In other words: a provider could technically push funds there, and cannot do so compliantly. A service offering you a "Zelle payout" is either using a structure that breaks the network's rules, or doing something else and calling it Zelle. Either way, the account closure risk is yours.

Instead: ACH for a one to two business day timing at minimal cost, or a wire for same-day settlement at a higher cost.

Satispay, MB WAY, QRIS

Same logic. Satispay and MB WAY are layers on an Italian or Portuguese account: we credit the underlying IBAN over SEPA Instant. QRIS is a QR-code merchant payment scheme in Indonesia; disbursing to an Indonesian wallet needs a local partner, which we have not opened.

What about cards?

The card is the perfect example of a pull instrument that eventually acquired a push capability, and it deserves explaining because the confusion is general.

A card payment is a pull: the merchant asks, your bank authorises. But the card networks added a reverse operation, the original credit transaction, sold under the names Visa Direct and Mastercard Send. It pushes funds to the account behind a card, in minutes.

Three reasons we do not use it as a primary rail:

• Cost. A credit to a card is priced well above a domestic transfer, and the price varies by issuer and country. On a corridor where the local transfer costs a fraction of a cent, the difference is not defensible.
• Failure rate. Not every card is eligible. Prepaid cards, single-use virtual cards and some corporate cards refuse credits. A failure is discovered after sending.
• Lifespan. A card expires every three or four years and changes number. An IBAN, a PIX key or a NUBAN does not.

In other words, card credits exist and work. They solve an accessibility problem in countries where domestic transfers are weak, not a cost problem where they are not.

Why this is not "a matter of partnerships"

One objection recurs: "others manage it, you are just short on integrations".

Three answers, in increasing solidity.

1. The protocol has no such operation. For iDEAL or BLIK, no commercial agreement creates a disbursement message that does not exist in the specification.
2. The scheme rules forbid it. For Zelle the obstacle is contractual. You do not negotiate an agreement against the network's own rulebook.
3. The local partner is missing. For QRIS the obstacle is real but surmountable. It is the only case in this list where "not yet" is the right answer.

We show these seven cases on the payout methods page with the reason for each, rather than making them disappear from the interface. A payment method missing without explanation looks like an oversight; a payment method missing with its reason is information.

What this means for you

In nearly every European case the replacement rail is the same: your IBAN, credited over SEPA Instant. That is often faster than the rail you were looking for, because SEPA Instant settles in seconds around the clock.

What changes is what you have to supply. A pull rail asks for a phone number or an authentication inside an app; a push rail asks for an IBAN and an exact account holder name. It is slightly more typing, and it is the price of being able to receive.

The PayPal exception

PayPal sits in a category of its own and is worth a paragraph, because it looks like a counter-example.

PayPal is a payment account, not a rail. You can be paid into it, which makes it a valid payout destination, and it reaches countries where no local rail is available to us. That is why it appears in our catalogue.

But it behaves like an account, not like an instant rail. The balance credited is an amount held by PayPal, and its withdrawal to your bank has its own timing, its own conditions and sometimes its own fee. A credit that lands in seconds does not mean money in your bank account in seconds. And PayPal applies its own risk rules to incoming funds, including holds, which we neither see nor control.

Our position is to offer it where it genuinely adds coverage, and to state plainly that a local bank rail, where one exists, is faster end to end and costs less. The comparison per method, at a fixed amount, is on the compare rails page.

How to spot a rail that cannot receive

Three clues are enough, with no technical knowledge:

• It exists mainly to pay a merchant. Card, QR code, one-time code: these are payment instruments, not receiving accounts.
• It has no stable, shareable account identifier. An IBAN, a NUBAN, a PIX key can be handed to a third party so they can pay you. A one-time BLIK code cannot.
• Its terms talk about "transfers between people you know". That is the standard wording of a scheme that forbids commercial use.

When all three signals are present, no service will be able to pay you there. If one claims otherwise, the question to ask is: through exactly what mechanism?

For the full list of rails we actually operate, with measured timings and ceilings, see the payout methods page and Understanding payout rails.