Payment routes: card, wallet and transfer fees compared

There are four routes in practice, and they differ in who charges you rather than only in how much. The first is a card, where your issuer, the processor and the recipient's acquiring bank each take a slice, and the slice you actually notice is usually buried in the exchange rate rather than printed as a fee. The second is a wallet balance held on the platform, funded once and spent across several orders. The third is a bank transfer, priced as a fixed fee per transfer with an exchange spread applied on top. The fourth is a third-party payment account, priced as a percentage of the amount sent with a smaller fixed component.

The reason to separate them carefully is that only two of the four show you a number at the moment of paying. A card cost and a wallet funding cost both tend to appear as a rate differential rather than as a line item, and a bank transfer fee appears as a line while its spread does not. Comparing what is visible across routes therefore compares a visible figure against a partly invisible one, which is exactly how buyers conclude that a route is free when it is not.

The comparison that works is the amount the seller or agent actually receives against the amount that left your account. That single ratio captures every fee and every spread regardless of how it is presented, and it is computable from two numbers you already have: the line on your statement and the confirmation on the platform. We suggest computing it once per route on a real order rather than trusting a fee schedule, because the schedule describes the published fee and not your effective one.

One further distinction is worth fixing before the comparison. A fee is a cost you can see and budget, while a spread is a cost embedded in a price you did not set. They behave differently when an order is refunded, they behave differently when the exchange rate moves between payment and settlement, and they behave differently when you try to dispute a charge. Treating the two as one number is convenient for ranking and inadequate for deciding.

The card row is a percentage plus a small fixed amount, with an additional conversion margin whenever the transaction currency differs from your card currency. In the published terms we have read and the invoices readers described during 2026 Q3, the all-in cost of this route sat in a band rather than at a point, and the widest part of that band came from the conversion margin rather than from the transaction fee itself. That is why two buyers using the same card on the same platform can report different effective costs.

The wallet row is charged when you fund the balance rather than when you spend it, so a single funding event can cover several orders and the effective cost per order falls as you consolidate. Its weakness is not a fee at all: the balance is a claim on a platform rather than money in your account, which is a different risk question and should be decided separately from the fee comparison. A cheap route to a balance you cannot withdraw is not a cheap route.

The bank transfer row is a fixed fee plus a conversion spread, which makes it the cheapest route per unit on a large payment and the most expensive on a small one. The third-party account row is a percentage with a small fixed component and a dispute mechanism attached, and it is that mechanism rather than the price that you are buying. Full rate detail on each route lives on the provider pages, and the fee comparator places them side by side on your own order value.

Two rows sit outside the table because they are not routes but decisions. The first is the currency you hold, since converting before paying and letting the platform convert at checkout produce different effective rates on the same order. The second is the timing of a top-up, because funding a balance in advance locks in a rate while paying directly at checkout takes the rate on the day. Neither is a fee, and both change the number at the bottom.

Speed matters at two moments and for different reasons. The first is at checkout, where a slow route can leave an order unpaid while a seller holds stock, which is a risk rather than an inconvenience and occasionally ends in the item being sold to somebody else. The second is at the shipping desk, where a slow funding route delays the release of a consolidated parcel and can push it past a storage deadline that was already close.

Balance-funded payments are the fastest in both cases, because the money is already on the platform and no external leg has to complete before the order can be actioned. Card payments are close behind in normal operation and slower when a fraud check triggers, which is disproportionately common on a first transaction to a new recipient. Bank transfers are the slowest of the four and are the route most likely to straddle a weekend or a public holiday in either country.

There is a settlement nuance that surprises people the first time it matters: a refund reverses along the original route, or it does not reverse in the way you expect. On a card, a reversal is relatively fast and lands as a credit on the same statement. On a bank transfer, the return leg is a second transfer with its own fee and spread, so a refund can cost money. On a platform balance, the refund is usually a credit inside the platform rather than a withdrawal to your bank.

The practical implication is that settlement speed is a property you should choose deliberately for the leg you are about to use rather than optimise globally. A buyer who funds a balance a day before a shipping deadline is buying speed at the moment it matters, while a buyer who keeps every payment on a transfer is optimising cost at the moment it matters less. Both are reasonable, and mixing them across a haul is usually better than committing to one.

Cards fail on declines and on holds. A first payment to an overseas recipient is a common trigger for a fraud review, and the failure usually appears as a decline rather than as a hold, so the buyer retries and creates two authorisations for one order. The other card failure is a chargeback that the buyer initiates correctly and that the platform disputes, which freezes the order while the dispute runs and can leave a shipping deadline unattended for weeks.

Transfers fail on details. A single wrong character in a beneficiary name can send a payment into a manual review that takes days, and the money is neither with you nor with the recipient while that happens. Transfers also fail quietly on the spread: the fee was correct, the transfer completed, and the amount received was smaller than expected, leaving no error to point at and no obvious party to complain to.

Wallet balances fail on funding and on withdrawal. A funding payment can be declined like any other card payment, which leaves the order unpaid while you wait, and a withdrawal can require verification steps a buyer has never completed. Third-party accounts fail on disputes that take longer than the parcel, and on account limitations that appear without warning at the worst possible moment. Every route fails in a way specific to it, which is the practical argument for having a funded fallback before you need one.

The common thread across all four is that the failure arrives at the moment of maximum urgency, because that is when most buyers are paying. The mitigation is unglamorous: keep a funded balance or a working card as a fallback, verify any account you intend to rely on before you need it, and never begin a payment you cannot afford to see fail twice. None of that reduces fees, and all of it reduces the chance of losing a haul to a payment problem.

For a small order, pick on reversibility rather than on price. Below a couple of hundred dollars the absolute difference between routes is small, while the cost of an unresolved problem is not, and a route with a dispute mechanism is worth a small premium at that size. This is also the size at which a fixed transfer fee is at its most disproportionate, since the fee does not scale down with the order and the spread applies regardless.

For a mid-size order, fund a balance in one movement and spend it across the haul. That is the shape which captures the wallet advantage properly: one funding event, several orders, one set of fees, and speed available whenever a deadline approaches. The discipline it requires is real, because a funded balance is easy to spend on items you did not plan to buy, and a haul assembled that way is a budget problem that no fee comparison can solve.

For a large order, the ranking inverts and the fixed-fee route usually wins on cost, provided you accept the settlement delay and the reduced recourse. If the order is large enough that the difference matters, it is also large enough that splitting the payment across two routes is sensible: fund the bulk by transfer and keep a card available for the top-up that the balance cannot cover at the moment the shipping desk asks for it.

Whatever the size, one habit is worth building. Write the received amount next to the debited amount for every payment you make for three orders, and you will have your own effective cost per route from your own transactions. That record takes a minute per order, it survives every revision of every published schedule, and it is the only fee data you can be certain applies to you rather than to somebody with a different card, a different currency and a different order size.