By: Money Navigator Research Team
Last Reviewed: 29/01/2026
FACT CHECKED
Quick Summary
Tide Payment Links are hosted checkout links you send to a customer so they can pay remotely (typically by card, and sometimes via pay-by-bank/Open Banking depending on the setup).
The payer sees a secure payment page with the amount and merchant context, then completes authentication if their bank or card provider requires it.
From the payer’s side, the most common “surprises” are the statement descriptor (what the payment is labelled as on their card/bank statement), and the timing differences between authorisation, settlement, refunds, and chargebacks.
This article is educational and not financial advice.
What Tide Payment Links are
A payment link is a unique URL that opens a hosted payment page. Tide describes Tide Payment Links as a way to collect customer card payments remotely and share the link through channels like email, SMS, social media, or inside invoices (Tide: what Tide Payment Links are and how they work).
Conceptually, it works like an online checkout page without needing a website: you generate the link, the customer opens it, and they enter payment details (or follow a bank-auth flow if pay-by-bank is offered).
What matters for the payer is that they are paying through a hosted flow, not transferring money directly to a sort code/account number they typed in manually.
What the payer sees when they open a Tide Payment Link
Most payers experience a short sequence:
A payment page opens in a browser (mobile or desktop).
They see the payment context (amount and merchant cues) before entering details.
They choose a method and complete authentication if required (for example, a one-time passcode, in-app approval, or a bank/card security step).
They get a confirmation screen after the payment is accepted for processing.
The statement description is part of the “payer experience”
Even when a payer recognises you, they may not recognise the descriptor wording if it differs from your trading name. Tide notes that payment-link transactions can appear on statements with descriptors such as “Tide Payout”, and invoice-payment-link activity can appear as “Tide Platform Ltd Tide Member’s Name”, and it explicitly warns that unfamiliar descriptors can lead to chargebacks (Tide: how Payment Link transactions appear in statements).
That descriptor point is central: many payer disputes start as “I don’t recognise this merchant” rather than “the goods were wrong”.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Payer recognises you but not the statement descriptor | Payer contacts their card provider or raises a dispute | Disputes can escalate into chargebacks, which can reverse funds after the original payment |
| Payer completes payment but sees “pending” | Authorisation may be visible before final settlement | Timing gaps can create confusion if goods/services are delivered immediately |
| Payer selects pay-by-bank (if offered) | Payer is redirected into a bank authentication journey | The payer experience is “bank-first” (approve in app / online banking), not “card-first” |
| Payer requests a refund | Refund timing differs from initial payment timing | Refunds can take materially longer than the original payment to appear back with the payer |
| Payer disputes the transaction | Chargeback process may start | Evidence and timelines become important, and funds may be debited during the dispute process |
How the payment moves behind the scenes (and why it affects the payer)
Payment links sit on top of established payment rails. Tide’s Payment Links terms describe a structure where a payment processor facilitates collection and processing, funds move via a merchant-account mechanism, and payout timing is subject to processing schedules (Tide: Payment Links Terms and Conditions).
From a payer perspective, this explains three common realities:
A “paid” screen isn’t the same as irrevocable settlement. Card payments can later be disputed and reversed via chargeback processes.
Timing is layered. There is a payer-side authorisation moment, and there is a later merchant-side payout/settlement timeline.
The “merchant” on the statement may reflect platform/processor descriptors. This is normal in many facilitated payment setups, but it can confuse payers.
Authentication (SCA) can add a step at checkout
In the UK, Strong Customer Authentication (SCA) rules can require additional verification for certain electronic payments, with exemptions in some cases (FCA: Strong Customer Authentication). For payers, that’s why a payment link may sometimes feel like “enter details, then approve via bank/app”.
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| “Why did I have to approve this in my banking app?” | SCA triggers a bank/card authentication step during checkout | Payment completes only after successful authentication |
| “Why does the statement name look unfamiliar?” | Descriptor/label is set by the payment acceptance setup and may reference the platform/payout wording | Payer may query or dispute the payment if they don’t recognise it |
| “Why does a refund take longer than the payment?” | Refunds follow scheme/bank processing cycles and may be handled separately from initial authorisation | Payer sees the refund later than expected, even when initiated promptly |
| “Why can a payment be reversed after it looked successful?” | Card rules allow disputes/chargebacks under certain conditions | Funds can be debited back during a dispute window |
| “Why can’t I use pay-by-bank for every invoice?” | Pay-by-bank availability depends on payer bank coverage, transaction parameters, and configuration | Payer may only see card options in some cases |
Fees, refunds, and disputes: what changes for the payer
Fees: usually invisible to the payer, but relevant to expectations
Tide’s help centre describes Payment Link fees as a percentage based on factors like whether the payer’s card is domestic/international and consumer/commercial, with higher rates for certain card types (Tide: fees for Payment Links). Those fees are typically taken from the merchant side, so the payer usually sees the amount they agreed to pay (not a separate “Payment Link fee” line item).
Refunds: payer timing can be slower than merchant intent
Refunds often take longer to show up on the payer’s statement than the original payment took to authorise. Tide states that refunds “normally take 14 business days” and that the original amount plus related transaction fees are deducted from the merchant account when a refund is issued (Tide: refund charges and typical refund timing).
From the payer side, that can look like: “the payment left quickly, but the refund is slow”. That’s a normal asymmetry in many card-based flows.
Disputes and chargebacks: what “chargeback” actually means
UK Finance explains chargeback as a mechanism that may allow a card provider to reclaim money from the retailer’s bank under scheme rules, and notes it is not a legal right (unlike Section 75 in certain credit card cases) (UK Finance: Chargeback and Section 75).
Tide’s Payment Links terms also describe chargebacks as disputes/reversals that can occur where a payer believes a transaction was not authorised or was made in error, and outlines that chargebacks can be deducted as part of the overall settlement mechanics (Tide: Payment Links Terms and Conditions).
Pay by bank (Open Banking) option: what the payer experiences
Tide’s pay-by-bank guidance describes an Open Banking journey where the payer chooses their bank and authorises the payment, with processing described as instant once completed.
It also notes practical constraints (for example, invoice totals must fall within stated ranges and international accounts are not supported in that flow), and that refunds are handled manually (not via a one-click “card refund” mechanism) (Tide: pay by bank for invoices).
For payers, the “feel” is different from card payment links:
The payer is pushed into a bank-auth flow.
The confirmation is more like a bank transfer approval than a card checkout.
Refund expectations differ because the rail is different.
Security and fraud: what the payer should understand about links
Payment links are convenient, but they are still links – which means payers may be cautious about phishing and impersonation.
Payment link acceptance and card-data handling sits within established card-security frameworks. For example, PCI DSS is the industry standard for protecting payment card data in card payment environments (PCI SSC: PCI DSS).
Authentication requirements may be enforced under SCA, depending on the transaction and exemptions (FCA: Strong Customer Authentication).
General anti-scam guidance consistently emphasises scrutiny of unexpected messages and links, particularly where urgency or unusual payment requests are involved (Take Five: Online scams).
This is not unique to Tide; it’s a property of “pay by link” patterns across the market.
Tide Business Bank Account
Tide Payment Links sit alongside Tide’s broader business account and payments tooling. For a neutral overview of Tide’s account positioning, typical features, and what’s included at different levels, see our Tide business account overview.
Frequently Asked Questions
Not usually. A payment link most often behaves like an online checkout: the payer enters card details or uses a wallet option, and the payment runs through card rails. That means payer protections, disputes, and timing tend to follow card-network patterns rather than Faster Payments patterns.
If a pay-by-bank/Open Banking option is offered, the payer experience is closer to a bank-authorised transfer, but it is still initiated through a hosted flow rather than the payer manually typing account details into their own banking app from scratch. The practical impact is that refund handling and dispute expectations can differ depending on whether the payer chose card vs pay-by-bank.
In a card-style flow, the payer typically enters card details (or uses a device wallet), and then completes any authentication step their card provider or bank requires. The merchant generally does not receive the payer’s full card details.
In pay-by-bank flows, the payer typically selects their bank and approves inside their bank’s authentication journey. From the payer’s perspective, that often feels like “approve this payment in the bank app” rather than “type card details into a web form”.
Statement descriptors can reflect the payment acceptance setup rather than the merchant’s trading name exactly. That’s common in facilitated payment arrangements and platform-led checkouts.
The practical risk is that unfamiliar descriptors can trigger payer confusion and “I don’t recognise this” disputes. In real-world operations, these disputes can happen even where the underlying purchase was legitimate, simply because the payer does not connect the descriptor wording to the merchant they dealt with.
In many card-payment setups, the payer sees only the transaction amount they agreed to pay. Fees are typically charged to (or absorbed by) the merchant side as part of payment acceptance costs.
However, a payer’s own bank or card provider may apply separate charges outside the merchant’s control in some circumstances (for example, certain foreign currency or card usage fees). Those charges, where they exist, are imposed by the payer’s provider rather than being a “Payment Link fee” line item from the merchant.
With card payments, “authorised” does not always mean “irrevocable”. Card rules allow disputes and chargebacks in defined circumstances, and reversals can occur after the initial payment appears successful.
This matters operationally when goods or services are delivered quickly. The payer may feel the transaction is complete once they see a success screen, while the merchant-side reality includes later settlement cycles and the possibility of disputes.
Refunds typically follow different processing cycles than the original authorisation. Even if a merchant triggers a refund promptly, the payer may not see the credit immediately because it passes through scheme/bank processing steps.
That timing mismatch is a frequent source of confusion: the payer remembers “the money left instantly,” but the refund appears days later. The gap is usually a processing reality rather than proof that the refund was not initiated.
Yes, it can happen. A payer may contact their card provider and attempt a chargeback if they believe the transaction was not authorised or something went wrong. Card providers often ask for evidence and will assess eligibility under scheme rules.
Where a merchant has already refunded, card processes typically aim to prevent “double recovery” (the payer being refunded twice). But administrative confusion can still arise if the payer pursues a chargeback while a refund is already in progress.
Declines can happen for many reasons: insufficient funds, bank risk controls, incorrect details, authentication failure, or card usage restrictions. From the payer side, the experience is often just “payment failed”, without a detailed reason.
Operationally, this is why two payers attempting identical payments can see different outcomes. The decisioning often sits with the payer’s bank/card issuer, and the merchant may have limited visibility into the exact decline reason.
From the payer perspective, a part-payment looks like any other card or bank-authorised payment: they approve an amount and expect the merchant to apply it to an agreed purpose. The key is clarity: the payer needs to recognise what the payment is for and how it will be used.
Where deposits are involved, payer disputes often turn on communication and evidence: what was agreed, what was delivered, and what the refund/cancellation terms were. These are contractual/consumer-law questions rather than purely “payments tech” questions.
In most dispute frameworks, evidence that links the payer to the transaction and the transaction to the delivered goods/services is the crux. Common examples include invoices, contracts, delivery confirmation, correspondence, and proof that the payer understood what they were paying for.
Edge cases tend to involve descriptor confusion, third-party payers (someone paying on behalf of someone else), delayed delivery, or mismatched amounts. In those cases, the dispute can be more about identity and expectation management than about whether the payment system “worked”.
Payment links compress “invoice > checkout > settlement” into a single hosted experience, but they do not remove the underlying rails.
Card-based payment links still inherit card-network features (authentication steps, issuer decline logic, refunds that settle later than authorisations, and disputes/chargebacks). Pay-by-bank options inherit bank-auth flows and different refund/dispute mechanics.
For payers, the experience is shaped less by the word “link” and more by three things: (1) whether they are paying by card or bank-auth flow, (2) how clearly the merchant context is presented (including statement descriptors), and (3) how well timing expectations are aligned between authorisation, settlement, refunds, and dispute windows.
Related Content
