By: Money Navigator Research Team
Last Reviewed: 11/02/2026
FACT CHECKED
Quick Summary
“Payment approval” in Tide usually means two different controls working together:
- Permissions (what your role is allowed to do, such as adding payees or sending transfers)
- Authorisation steps (confirming a payment in-app, especially when it’s initiated on the web)
If someone can’t send money, the cause is typically either insufficient access level or an incomplete authorisation step, rather than the payment “failing” on the banking rails.
This article is educational and not financial advice.
What “payment approval” means in Tide
In Tide, “approval” commonly gets used to describe three separate experiences:
Permission-based access (who is allowed to send money)
If a user’s access level doesn’t include sending payments (or managing payees), the payment flow may not appear for them at all, or certain steps may be blocked.In-app authorisation (confirming a payment you’ve just created)
Tide’s own payment flow describes an explicit “approve in the app” step when a payment is set up on the web. In practice, this functions like a security control: the payment is initiated in one place, then confirmed in the app.Optional verification prompts for card payments
Some “approval-like” prompts relate to card transactions rather than bank transfers (for example, a “Verify Payment” notification).
Understanding which of these is happening is the key to diagnosing what’s actually blocking a payment.
The permissions layer: roles, access levels and what they enable
Tide’s team access model is permission-led: a person can only do what their access level allows. At a high level, that means:
Some access levels are designed for visibility (seeing activity without changing anything).
Some are designed for operational actions (drafting, sending, setting up recurring items, and managing payees).
Some are designed for taking payments (for example, cashier-style access) rather than sending bank transfers.
For a role-by-role breakdown (without repeating it here), see Tide roles: Admin, Team Member, Cashier.
Why permissions affect “sending money” more than anything else
Sending money isn’t one single action. It normally includes multiple permission points, such as:
Creating or editing a payee (the recipient details)
Setting the payment type (one-off, scheduled, recurring)
Submitting the payment
Completing any required authorisation step
A user might be able to see balances and transactions, but still be unable to send because one permission point is missing.
Tide’s payments guidance describes a two-step web flow: you submit the payment on the web, then you “approve your payment in your app”. See Make a payment with your Tide account.
That wording matters because it implies a practical distinction:
Payment created/submitted (details entered on web)
Payment authorised (confirmed in-app)
So if a payment looks “stuck” after being created on the web, the cause can be as simple as the final authorisation step not being completed yet.
Where the banking rails fit in
Once a payment is properly authorised, the next factor is the rail it runs on. Tide describes GBP transfers from Tide accounts as Faster Payments, and the Faster Payment System itself operates 365 days a year. See Faster Payment System.
For a wider explanation of UK payment rails (and what can make timings differ), see EMI business accounts and payment rails.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| User can view transactions but can’t see “Send money” features | Payment can’t be initiated by that user | Operational delays if the person who needs to pay suppliers cannot access payment tools |
| Payment is created on web but not confirmed in app | Payment remains unauthorised until the app step is completed | Can look like a “stuck” or “pending” payment even though bank rails haven’t been engaged yet |
| User can send a one-off transfer but can’t set recurring items | Only one-off payments can be made | Manual repeat work for routine bills |
| User can send payments but cannot add/remove payees | Payments limited to existing payees | Any new supplier setup needs a user with payee permissions |
| Confusion between card “verification” prompts and bank transfer approval | The wrong control is being investigated | Time lost troubleshooting permissions when the prompt relates to a card transaction flow |
What specific permissions commonly affect bank transfers in Tide
The most common permission-driven blockers for outbound payments are:
Payee management permissions
Some access levels include adding/removing payees; some do not.Bank transfer permissions
A user may be allowed to make bank transfers (and manage payees) at certain access levels. Tide describes “View, Draft, Send & Pay” access as including bank transfers and payee management. See What can team members with “View, Draft, Send & Pay” access do?.Recurring payment permissions
Scheduled payments and Direct Debits introduce additional set-up and management actions that may not be included at every access level.Visibility vs action permissions
“View-only” access is designed around seeing activity rather than changing it; the practical outcome is that sending money is generally outside scope. For the visibility boundary, see Tide view-only access.
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Role mismatch | The user can’t reach the steps required to create or submit a payment | Payment never gets initiated from that login |
| Split initiation and authorisation | Payment is entered on web, then requires app confirmation | Payment is not treated as authorised until the in-app step is completed |
| Payee control restrictions | User can enter amounts but can’t create/edit recipient details | Payments limited to pre-existing recipients |
| Recurring control restrictions | User can send a one-off but can’t create/stop recurring items | More manual work; higher chance of missed timing on repeat obligations |
| Card-flow prompts mistaken for transfer approvals | “Verify Payment” notifications relate to card purchase controls | Troubleshooting focuses on the wrong “approval” concept |
Why the same “approval” language appears across different Tide features
The word “approval” can describe:
Access control (permissions)
Security confirmation (in-app authorisation)
Card transaction verification prompts
For example, Tide describes a “Verify Payment” notification model for some team member online purchases, where the account holder can approve or decline before or instead of the team member, but it is described as optional. See Why do I still receive a notification to verify online purchases from my Team Members?.
That is a different mechanism from authorising a bank transfer initiated on the web, and different again from granting permission to send money.
Tide Business Bank Account
Tide’s product set can include different account structures depending on the specific product a business is using. Tide also states that it designs and operates the app and website and is not itself a bank, while offering bank accounts provided by partner banks for certain products.
For a neutral overview of Tide’s business account positioning in the wider market, see our Tide business bank account page.
Frequently Asked Questions
Not necessarily. Tide’s web payment flow describes submitting the payment on the web and then approving it in the app, which reads as a same-user (or same-account) authorisation step rather than an inherent “four-eyes” workflow. See Make a payment with your Tide account.
A second-person sign-off is a different concept: it’s about splitting duties across two separate users with different permissions. Whether that is possible depends on how the business sets up access levels and who is given which permissions, rather than being guaranteed by the existence of an in-app approval step.
Payee management is commonly a distinct permission from “seeing transactions”. Tide’s description of “View, Draft, Send & Pay” access explicitly includes adding or removing payees, alongside making bank transfers. See What can team members with “View, Draft, Send & Pay” access do?.
Where payee permissions are not included, the practical impact is that new supplier setup can’t be completed from that login. That can look like a payment problem, even though the block is earlier in the process (recipient creation).
Tide’s own steps for web payments indicate a deliberate split: enter and submit the payment on web, then approve it in the app. See Make a payment with your Tide account.
In practical terms, that creates an additional confirmation point before the payment is treated as authorised. If the app step is not completed, it can appear as if the payment has not moved, because the instruction may not yet be fully authorised.
Based on Tide’s described flow, the payment is not fully authorised until the in-app approval step is completed. See Make a payment with your Tide account.
That can create a “false positive” payment issue: the banking rail (such as Faster Payments) may not even be engaged yet, because authorisation hasn’t occurred. In teams, this can be misread as “the bank is slow”, when it’s actually a workflow step waiting on completion.
They often rely on additional actions beyond a one-off transfer: creating a schedule, setting frequency, and managing or stopping the recurring item. Tide’s payment guidance groups scheduled payments and Direct Debits as distinct payment types in its overview. See Make a payment with your Tide account.
The practical implication is that a user might be able to send a one-off payment but not be able to manage recurring obligations, depending on how access is configured. Where recurring controls aren’t available, workarounds typically become more manual, which changes operational risk rather than banking risk.
View-only access is designed around visibility rather than action. In practice, that means it is aimed at reading transactional data rather than initiating transfers or changing recipient details. For the detailed boundary of what can be seen versus changed, see Tide view-only access.
This can matter in real workflows because “I can see the account” is not the same as “I can send money”. If a colleague reports they “have access” but can’t pay a supplier, the access type may be visibility-only.
That prompt relates to card transaction verification, not bank transfer permissioning. Tide describes a model where team members can approve their own online payments, while the account holder can also receive a “Verify Payment” notification and can approve or decline before or instead of the team member, described as optional. See Why do I still receive a notification to verify online purchases from my Team Members?.
Operationally, this can look like “payment approval” even though it’s part of card controls. Mixing this up with bank transfer approval can send troubleshooting in the wrong direction.
Tide’s payment guidance states that GBP transfers sent from Tide accounts are made as Faster Payments. See Make a payment with your Tide account.
Faster Payments as a system is designed for near real-time payments and operates 365 days a year. See Faster Payment System. Even so, the timing a recipient experiences can vary by receiving bank processing, and that is distinct from permissions or authorisation steps within Tide.
Tide states that it designs and operates the app and website and is not a bank, and that certain Tide products involve bank accounts provided by partner banks, while some members may hold e-money accounts provided by an electronic money institution.
Where regulatory status needs to be checked, the UK’s public register of authorised/registered firms is maintained by the regulator. See Financial Services Register. This is relevant to understanding who the regulated firm is behind the specific product a business is using.
Not always. The most common “not permissions” causes are data issues (incorrect recipient details), rail constraints (recipient bank handling), or the payment not being fully authorised yet if an in-app step is outstanding. Tide’s own web flow makes that split explicit. See Make a payment with your Tide account.
It can also be a category mistake: a user might be reacting to a card “verify” prompt and assuming it affects bank transfers. Tide separates these concepts in its support materials. See Why do I still receive a notification to verify online purchases from my Team Members?.
Payment “approvals” in app-based business accounts are best understood as a chain of gates rather than a single yes/no event.
The first gate is permission (whether the user can even reach the action), the second is authorisation (whether the payment instruction is confirmed in the required channel), and only then does the payment move into rail execution (for example Faster Payments).
When teams collapse these into one word – “approval” – it becomes harder to diagnose delays and blocks. Separating the concepts restores clarity: permission is about access design, authorisation is about confirming intent, and rail execution is about how money actually moves once instruction is valid.
Related Content
