By: Money Navigator Research Team
Last Reviewed: 29/01/2026
FACT CHECKED
Quick Summary
Tide Payment Links refunds are structured as full refunds only (not partial), and Tide states refunds normally take 14 business days to reach the customer.
The key operational detail is that when a refund is issued, the refund amount plus related transaction fees are deducted from your Tide account, and the customer’s bank may still take time to post the credit after it moves through card-network processes.
This article is educational and not financial advice.
What a “refund” means with Tide Payment Links
A Tide Payment Link payment is a card-based transaction (even if the payer uses a digital wallet). When a refund is created, it isn’t the same thing as “reversing” the original payment in the moment. In most cases, it becomes a separate credit that flows back through the card ecosystem and is then posted by the customer’s bank.
That’s why it’s possible for a customer to receive a “refund issued” confirmation while their bank balance does not update immediately. The payment and the refund are related, but they do not always settle on the same timeline.
Full vs partial refunds: what’s possible
For completed and settled Payment Link transactions, Tide’s support guidance is explicit: partial refunds are not supported (“not possible under any circumstances”).
That rule matters because many real-world “refund” scenarios are actually price adjustments (e.g., one item returned from a multi-item order, a partial service cancellation, or a goodwill discount).
In practical terms, that means any “partial” outcome usually has to be handled outside the refund feature (for example, via invoicing adjustments, separate payments, or other commercial arrangements).
The correct approach depends on the underlying contract and what both parties agree, but the system-level constraint remains: the in-product refund function is built for full refunds only, as described in Tide’s own Payment Links support content via the Payment Links refund timing guidance and the Payment Links partial refund guidance.
What happens to fees when you refund
A common surprise is that a refund can reduce your available balance by more than the original settlement you saw, depending on how fees are applied.
Tide states that when you issue a refund, “the total payment amount, plus any related transaction fees, will be deducted” from your account, as set out in Tide’s refund fee and timeline guidance for Payment Links. Operationally, this creates two important implications:
You need sufficient available balance at the moment the refund is processed, because the refund amount and related fees are taken from your account.
A refund can change the net economics of that sale even if the customer receives the full amount back, because the fee treatment is separate from the customer’s experience.
This is not unique to Tide; it’s a feature of how many card acceptance and settlement models reconcile fees versus gross payment value.
Typical refund timelines: why “14 business days” is not the whole story
Tide’s support guidance states refunds normally take 14 business days. That is the best single reference point for expectations from the Tide side of the chain, and it’s the number most relevant for planning operational communications.
However, the end-to-end customer experience can still vary because the customer’s bank posts credits on its own systems and may not show an incoming refund until it appears on the account.
For example, NatWest notes that there are “no set timescales” for how long a refund will take and that they may need to allow up to 15 days for a refund to show, as explained in NatWest’s debit card payments guide, which is one reason different customers can see different outcomes even when the refund was initiated on the same day.
A simple “Refund Journey”
Merchant (you)
1) Refund requested/created (full amount only)
Tide / Payments processing layer
2) Refund message routed through card payment networks
Card scheme rails + issuer processing
3) Customer’s bank posts the credit to the account
Customer sees funds (timing can vary by bank)
The practical takeaway is that “refund created” and “refund visible to the payer” are different checkpoints in the same journey.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| You attempt a part-refund for a settled Payment Link | Partial refunds aren’t supported | The refund feature won’t match “partial return” workflows; alternative commercial handling may be required |
| You issue a full refund immediately after settlement | Refund can be created, then processed | Customer may still wait before it appears on their statement |
| You issue a refund but your Tide balance is low | Refund may fail or be delayed operationally | Refund processing is constrained by available funds and how the deduction is applied |
| Customer says “refund issued” but no funds yet | Posting delay at the customer’s bank is possible | Support conversations often hinge on bank posting timelines rather than the refund being “missing” |
| Customer paid via Pay by Bank rather than card | The “return path” can differ from card refunds | The refund method may be a separate transfer rather than a card credit, depending on how it was paid |
| Refund created during weekends/holidays | Business-day clock matters | “14 business days” can span longer in calendar days |
| Customer closes/replaces their card | Refund can route based on issuer handling | The customer’s bank may still accept and post the credit, but visibility may vary |
| Customer disputes instead of waiting | Dispute route differs from a refund | Disputes can introduce holds and evidence requests rather than a straightforward refund flow |
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Refund initiated in app/support | Refund request logged and validated against the original payment | Refund proceeds only if it matches allowed parameters (e.g., full amount) |
| Refund passes merchant side checks | Refund routed for processing through payment rails | Processing happens in stages; “issued” does not guarantee immediate visibility |
| Card-based payment | Credit flows back through card ecosystem | Customer sees a card credit once issuer posts it |
| Bank-to-bank payment (Pay by Bank) | Credit may be a separate bank transfer | Timing resembles bank transfer posting rather than card credit posting |
| Customer checks immediately after “refund issued” | Bank ledger may not yet show the credit | Customer-facing delay is often “posting time”, not “refund not done” |
| Customer escalates to dispute | Dispute/chargeback path triggered instead of refund path | Evidence and timelines can change materially compared with a refund |
Tide Business Bank Account
Managing refunds is often easier when your payment tools and your business account live in the same app, because the balance impact, transaction references, and support trail sit together.
Tide structures this by combining business account functionality with payment collection features so the money-in and money-out entries can be reviewed in one place, particularly when refunds deduct the refund amount and related fees from the same available balance.
For a broader, neutral overview of Tide’s business account positioning and features (separate from refunds), see our Tide business account review.
Frequently Asked Questions
No – partial refunds aren’t supported for completed and settled Payment Link transactions. Tide states that partial refunds are not possible, which means the refund function is designed around a full reversal of the original payment amount.
In practice, partial-return situations (like one item returned from a bundle) become an accounting and commercial handling problem rather than a “refund button” problem.
The operational constraint is that the refund tool itself won’t produce a smaller refund amount than the original payment, so any partial outcome depends on a separate arrangement outside the refund feature.
Tide states refunds normally take 14 business days. That figure is the clearest published expectation for the refund journey from initiation through to completion on Tide’s side of the process, as described in Tide’s refund fee and timeline guidance.
“Business days” matters here. A refund initiated just before a weekend or bank holiday can still be within the stated window, but it may span more calendar days. The same business-day concept also explains why two refunds created on different days of the week can “feel” like they move at different speeds.
Because the customer’s bank may take time to post the credit, even after the refund is issued. Card credits often move through processing steps before the issuer (the customer’s bank) shows the credit on the account.
Banks may also explain that they cannot provide exact posting times for refunds. For example, NatWest notes there are no set timescales and that they may need to allow up to 15 days for a refund to show, as set out in its debit card payments guide. That variability is one reason refund timelines can differ from customer to customer.
Tide says the refund amount plus related transaction fees are deducted from your account when you issue a refund. This is an important operational detail because it affects available balance and the net economics of the original sale, as described in Tide’s refund fee and timeline guidance.
From a reconciliation perspective, this means the customer experience (receiving the refunded amount) and the merchant ledger outcome (refund amount plus fee treatment) are not the same thing. The fee treatment impacts the business account balance immediately, while the customer’s refund visibility depends on bank posting.
Not always – the “return path” depends on the payment rail used. If the customer paid by card, the refund is typically a card credit that the customer’s bank posts when processed.
If the customer paid via Pay by Bank, the return leg can resemble a bank transfer rather than a card credit. The FCA explains that payment initiation services let people pay directly from their bank account rather than using a card, in its consumer guidance on account information and payment initiation services, which is why the mechanics can differ from card refunds.
Usually not – digital wallets still typically ride on the underlying card rails for refunds. From the merchant side, the payment looks like a card transaction, and refunds follow the card-credit pathway.
The variability still tends to come from issuer posting and bank processing, rather than the wallet itself. The wallet can influence what the customer sees in the wallet interface, but the account-credit timeline is primarily controlled by the issuing bank’s posting processes.
There isn’t a universal “instant” switch, because multiple organisations process different stages. Once a refund enters processing, the customer’s bank ultimately controls when the credit becomes visible on the account.
This is also why published guidance tends to use ranges and business-day language rather than minute-by-minute commitments. The practical reality is that a refund is a chain, and no single party controls every link in that chain end-to-end.
They can be fast, but not guaranteed, because bank transfers have their own rules and exceptions. In the Faster Payments system, funds are “usually available almost immediately,” but can sometimes take up to two hours, according to Pay.UK’s explanation of how Faster Payments work, which illustrates why bank-to-bank credits can look different from card credits.
That said, a refund is not always the same as “sending a new Faster Payment”, and individual banks still apply fraud controls, posting rules, and exception handling. So while bank transfers often feel quicker, there can still be delays in edge cases.
A refund is a voluntary return of funds by the merchant, while a chargeback is a dispute process run through card networks and issuers. Refunds are generally simpler when they’re straightforward full reversals, whereas disputes can involve evidence, timelines, and decisioning by parties beyond the merchant.
If a customer escalates to a chargeback path, the process can be governed by card-network rules and issuer requirements rather than the merchant’s refund workflow.
UK Finance provides an overview of the process and timing concepts in its guide on chargeback and Section 75, and for a settlement-chain perspective on withholding/holds, see our internal explainer on who can withhold funds in settlement chains.
The clearest explanation is that refunds can take business days and posting time varies by bank.
Tide’s published expectation is 14 business days for refunds to complete, and banks may separately describe their own visibility timelines, which helps frame why a refund can be “in progress” without being visible yet.
It’s also helpful to separate two questions: “Was the refund initiated?” and “Has the bank posted it?” Those are different stages, and the second stage is not fully controlled by the merchant.
Keeping the conversation anchored to the published business-day expectations avoids over-promising exact dates that depend on the customer’s bank.
Refunds feel “slow” because a refund is not a single event; it’s a multi-party state change. A payment is an authorisation and settlement to the merchant side, but a refund is a separate credit that has to be accepted, processed, and then posted by the issuer’s systems.
The constraint that matters most is control: merchants can initiate refunds (within product rules like “full refund only”), but they do not control issuer posting.
The practical implication is that refund expectations need two clocks:
- The provider’s published processing window
- The customer bank’s posting behaviour
Confusion happens when those two clocks are treated as one, or when “refund issued” is interpreted as “funds already available”.
Related Content
