By: Money Navigator Research Team
Last Reviewed: 06/02/2026
FACT CHECKED
Quick Summary
If you get a refund for a non-GBP card purchase on Tide, the GBP amount credited can legitimately differ from what you originally paid.
The key reason is that the refund normally reverses the original foreign-currency amount, then converts back to GBP using the exchange rate on the refund processing day, not the original purchase day.
Any FX-related fees (where applicable) may also be treated differently from the purchase amount depending on how the transaction was structured.
This article is educational and not financial advice.
What a “non-GBP refund” is in the card system
A non-GBP card purchase usually starts life in the merchant’s currency (for example, EUR, USD, PLN). Your Tide card transaction is then converted into GBP as part of the card payment flow.
That conversion is not a “single moment” in the way it feels in-app; it is a process involving the merchant, their acquirer, the card scheme and the card issuer.
A refund runs through a similar chain, but it is not guaranteed to mirror the original GBP figure. Tide explicitly notes that non-GBP card refunds are processed at Mastercard’s exchange rate on the day the refund is processed, and the refund is for the original non-GBP amount, so the GBP outcome can differ from the purchase. See Tide’s help-centre explanation: How do refunds work for non-GBP transactions?
Why the GBP refund can differ from what you originally paid
1) The exchange rate can move between purchase day and refund day
Even small FX moves can produce a visible difference in GBP on larger purchases. If a purchase was made when GBP was stronger and refunded when GBP is weaker (or vice versa), the “same” foreign-currency refund can translate into a different GBP credit.
If you want to sanity-check the scheme rate used in many card flows, Mastercard publishes a rate tool here: Mastercard currency exchange rate converter. (Other schemes have their own tools, such as Visa’s: Visa exchange rate calculator.)
2) The refund usually reverses the foreign-currency amount, not the GBP amount
In many cases, the merchant refunds the same foreign-currency figure that was originally charged (for example, a €120 refund for a €120 purchase). The card scheme conversion back into GBP then happens using the applicable rate at the time the refund is processed, which can differ from the original purchase-day conversion.
This is why two statements can both be true at once: the merchant refunded “the full amount” in their currency, and the GBP credited is not identical to the original GBP debit.
3) DCC can change the “original currency” that gets refunded
Dynamic Currency Conversion (DCC) is where a checkout or terminal offers a choice to pay in GBP rather than the local currency. If the original transaction was processed in GBP via DCC, then the refund may follow that GBP path rather than refunding a foreign-currency amount and converting.
If you want the mechanics of DCC without focusing on any single provider, see: Dynamic currency conversion explained: why terminals offer it.
4) Fees and FX mark-ups can be treated differently from the principal amount
Depending on plan and transaction structure, an FX-related fee can be applied at purchase time. Tide’s help-centre note on non-GBP refunds states that currency exchange fees are not refunded. That means the merchant can refund the full foreign-currency purchase amount, but the net GBP outcome may still look “short” versus the original debit once fees are accounted for. See: How do refunds work for non-GBP transactions?
A card payment can be authorised first and settled later. Similarly, a merchant can “issue” a refund in their system before it is processed and posted through the card rails. If you are comparing screenshots, receipts and statement lines, make sure you are comparing like-for-like (authorisation date vs posted date).
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Full refund issued days later (same currency as purchase) | GBP credit differs from original GBP debit | Differences may appear as FX variation rather than “missing money” |
| Full refund issued weeks later (same currency as purchase) | Difference is larger due to bigger FX movement | Reconciliation may require matching both the foreign amount and GBP amount |
| Partial refund (same currency as purchase) | Multiple GBP credits that don’t map neatly to original GBP | Each refund leg converts at its own processing-day rate |
| Merchant refunds a different amount in foreign currency (restocking, amended bill) | GBP credit differs and foreign amount differs | Needs checking against the merchant’s refund confirmation in their currency |
| Original purchase used DCC and was processed in GBP | Refund may post as GBP without FX reconversion | Statement narrative may look “domestic” despite being abroad/foreign merchant |
| Original purchase in foreign currency; refund processed at a different rate | GBP credit is higher or lower than expected | Expectation-setting: refund is correct in foreign currency, GBP is rate-dependent |
| Currency exchange fee applied at purchase time | Principal refunded but fee may not be reversed | Net GBP received may look lower even when the merchant refunded “in full” |
| Refund “issued” by merchant but not yet posted | No GBP credit visible yet | The delay is operational (processing), not necessarily refusal or dispute |
Scenario Table
| Scenario-level | Process-level (what happens in the rails) | Outcome-level (what you see) |
|---|---|---|
| Purchase made in EUR, account is GBP | Transaction amount is EUR; conversion happens during card processing | Statement shows EUR spend plus GBP debit derived from that day’s conversion |
| Refund made in EUR for the original EUR amount | Refund amount is EUR; conversion back to GBP uses the refund-day rate | GBP credit differs from original GBP debit even when EUR refund is identical |
| Refund is split across two dates | Each refund is processed separately | Two GBP credits, each with its own conversion outcome |
| DCC used at checkout (GBP chosen) | Merchant/acquirer processes the transaction in GBP rather than local currency | GBP debit and GBP refund may align more closely, but rates/fees are “baked in” at point of sale |
| Merchant refunds less than the original foreign amount | The rails process the amended foreign-currency refund | GBP credit differs and the foreign-currency figure is the main truth source |
| Fee exists outside the refundable principal | A fee can be posted separately from the purchase principal | Purchase may look larger than the later refund even when the merchant refunded the full principal |
How FX works on Tide for cards vs international payments (don’t mix the two)
It helps to separate card FX from international transfer FX, because they can use different rate sources and timing rules. For a deeper dive on card conversion and how mark-ups are framed, see: Tide card FX pricing explained: exchange rates & mark-ups.
International payments (bank transfers) can have their own conversion logic and may show different behaviour when a transfer is returned or rejected. For the transfer side of the house, see: Tide FX rate for international payments: how the conversion rate is determined. The key point for this article: a card refund is typically anchored to the merchant currency amount, not to the original GBP debit.
What your Tide timeline and statement may show
On many non-GBP card transactions, there are effectively two “truths” you may need for reconciliation:
The foreign-currency amount (what the merchant charged/refunded).
The GBP posted amount (what your account was debited/credited after conversion).
When the GBP credit differs from the original GBP debit, it does not automatically imply an error. A common cause is simply that the conversion applied on the refund processing date was different from the conversion applied on the purchase processing date.
Accounting and VAT: why FX differences matter
From an accounting perspective, a refund that is “correct” in foreign currency can still generate a GBP difference versus the original debit. That difference is often treated as an FX difference arising from timing, rather than as a pricing discrepancy by the merchant.
For VAT reporting contexts where foreign-currency invoices must be converted to GBP using acceptable methods, HMRC sets out approaches and requirements here: Transactions in foreign currencies and VAT. That guidance is about tax reporting mechanics rather than card scheme processing, but it explains why “rate source” and “rate date” matter when converting non-GBP amounts into GBP.
Tide Business Bank Account
Tide provides business account products with app-based management and card spending features, alongside options for transfers and other business tooling. Plan structures and transaction types can affect how fees are presented and how transactions appear in the timeline, so it can help to distinguish card spending from bank transfer activity when reviewing a refund outcome.
For a consolidated overview of Tide’s business account proposition and how it compares within the wider market, see: Tide business bank account overview.
Frequently Asked Questions
Not necessarily. A common pattern is that the refund reverses the original foreign-currency amount, and the GBP credit is calculated using the exchange rate that applies when the refund is processed. Tide explicitly flags that the final amount may not match what was originally paid when the purchase was non-GBP. See: How do refunds work for non-GBP transactions?
Edge cases can add more variation. If the original transaction was authorised on one day but settled later, the posted GBP debit may reflect settlement timing rather than authorisation timing. The refund can also be delayed operationally, meaning the applied rate may be from a different day again.
“In full” often means “in the merchant currency”. If a €100 purchase is refunded as €100, that can still land as a different GBP value if the FX rate moved between the time the purchase was processed and the time the refund was processed.
A second contributor can be fees that sit outside the refundable principal. Tide’s non-GBP refund guidance notes that currency exchange fees are not refunded, which can make the net GBP outcome look lower even when the merchant refunded the full non-GBP amount.
Tide’s help-centre guidance on non-GBP card refunds states that currency exchange fees are not refunded. See: How do refunds work for non-GBP transactions?
In practice, the way a fee shows up can vary by how the transaction is presented (for example, whether it is embedded in a single posted amount or shown as a distinct line). That’s why comparing the foreign-currency amount and the total GBP posted amount can be more informative than comparing only the headline GBP debit versus credit.
A partial refund typically processes as a separate non-GBP amount (for example, €25 refunded against a €100 purchase). That non-GBP refund amount is then converted into GBP at the rate applying when each refund is processed.
If there are multiple partial refunds, each one can land at a different GBP value even if the foreign-currency amounts are clean and round. This can make “matching” in bookkeeping look odd unless the reconciliation uses both the foreign-currency figures and the posted GBP figures.
A merchant completion status can reflect their own system, not the point at which the refund has been processed and posted through the card rails. Card refunds can take time to propagate from merchant to acquirer to scheme to issuer, and that lag can be longer across weekends or where the merchant batches refunds.
Another timing nuance is that some providers show intermediate states (such as pending) differently, or only show the posted credit once the refund is fully processed. The key is that the posting date drives the FX rate used for conversion in many card refund flows.
It can be. DCC changes the currency in which the transaction is processed at the point of sale. If the original purchase was processed in GBP via DCC, the refund may follow that GBP path rather than refunding a foreign-currency amount and converting back.
DCC can also introduce confusion because the receipt can show multiple currencies (local currency, GBP amount, margin information), and the “refund currency” that the merchant uses may follow the processed currency rather than the sticker price currency. For background, see: Dynamic currency conversion explained: why terminals offer it.
Visa and Mastercard publish separate exchange rate tools, and they can differ because they are different schemes using different reference methodologies and timing. Visa provides a public calculator here: Visa exchange rate calculator.
For Mastercard, the equivalent tool is here: Mastercard currency exchange rate converter. Comparing tools can help explain why two cards can produce different GBP outcomes for the same foreign-currency refund on the same day, even before any provider-specific fees are considered.
“Same day” in human terms is not always the same as “same processing window” in payments. A purchase might be processed late in a day (or in one time zone), while the refund is processed at a different point in the scheme’s processing cycle, which can mean a different applicable daily rate.
Operational batching also matters. Merchants often batch refunds, and the “effective date” for processing can land a day later than the date shown on the merchant’s confirmation email, which can produce a different conversion result even when the refund was initiated quickly.
Card payments can involve an authorisation amount and a later clearing/settlement amount. In some scenarios (for example, where the final bill is confirmed later), the settled amount can differ from the authorisation, and the FX conversion can reflect the settlement timing.
This is separate from refunds, but it affects the baseline you are comparing against. If the original posted debit already differed from an earlier authorisation estimate, then a refund processed later adds another conversion point, which can compound confusion unless the comparison uses posted (settled) figures.
Bookkeeping often treats the difference between the GBP debit and the GBP refund (where the foreign-currency amounts match) as an FX difference caused by rate movement and timing. That is an accounting presentation issue rather than a statement about whether the merchant “did the refund correctly” in their currency.
For VAT conversion rules and acceptable ways to convert foreign-currency amounts into GBP, HMRC explains requirements and approaches here: Transactions in foreign currencies and VAT. This is relevant because it underscores that “rate source” and “conversion date” are compliance-sensitive topics in reporting contexts, even though card schemes have their own operational timing.
The recurring misunderstanding with non-GBP refunds is assuming the system is designed to “undo” a GBP debit precisely.
In reality, the card rails commonly treat the foreign-currency amount as the primary value that is reversed, and GBP is the by-product of a conversion step that can occur at a different time and therefore at a different rate.
Once that constraint is understood, most “mystery shortfalls” reduce to three buckets:
- FX moved between purchase and refund processing
- The transaction currency changed (often via DCC)
- Something outside the principal amount (such as a fee) was not reversed
The practical impact is not that refunds are inherently unreliable, but that the “refund correctness” test needs to start with the foreign-currency refund amount and the posting dates, not only the two GBP figures.
Related Content
