By: Money Navigator Research Team
Last Reviewed: 01/02/2026
FACT CHECKED
Quick Summary
“Authorised”, “settled”, and “available” describe different points in the card payments chain. With Tap to Pay on iPhone, a payment can be authorised instantly (customer’s bank approves), settled later (card networks and processor complete settlement), and only becomes available when the payout reaches your Tide business account.
Tide states Tap to Pay on iPhone payments are received into your Tide business account within 3 business days.
This article is educational and not financial advice.
A payment is authorised when the customer’s card issuer approves the transaction at the point of sale. This is the “green light” stage: the issuer confirms the transaction can go ahead and places the appropriate hold/authorisation on the customer’s account (exact mechanics vary by issuer and scheme).
For a high-level explanation of authorisation and the overall stages, see Mastercard’s overview of how payment transactions are processed. How payment transactions are processed
Key point: Authorised does not automatically mean you’ve been paid out.
Settled
“Settled” is commonly used to describe the point where the payment has moved through clearing/settlement within the payment ecosystem (processor/acquirer/scheme reporting).
In payment processing terms, settlement sits after authorisation and capture/clearing steps. A helpful way to think about this is that settlement is “processor-side finalisation”, not “cash in your bank account”.
Key point: Settled does not always equal “available to spend”.
Available
“Available” is the stage most business owners care about: the funds are in your Tide business account balance and usable (subject to normal account functionality). This timing depends on payout schedules, working days, and how the payments are routed and paid out.
Why there are stages at all with Tap to Pay on iPhone and Tide
Tap to Pay on iPhone is the acceptance method (your iPhone acts as the contactless acceptance device), but the payment still travels through the standard payments chain.
Tide describes Tap to Pay on iPhone processing as involving Adyen and a “Merchant Account” used to collect and record payments before funds are processed and sent to your Tide business account. How are payments made with Tap to Pay on iPhone processed?
Under the hood, the same “ledger vs cash” distinction that applies to many card flows applies here too: a transaction can be recognised in one system (authorised/settled) before the payout arrives in another (available balance).
If you want a deeper, general explainer of how different balances and rails can sit in a chain, see: Merchant account vs EMI balance vs bank balance: the payments chain.
This is usually near-instant when the customer taps (assuming connectivity and no decline).
If you’re troubleshooting a failure at this first stage (i.e., it never authorises), start with the separate declines guide, because the causes are often different from payout delays. Tap to Pay on iPhone with Tide Declines Explained: Common Causes and What to Check First
2) After the sale: the payment becomes “settled” in processing records
Clearing and settlement are the “back office” stages that happen after authorisation. Different providers use different language, but the broad distinction is consistent: clearing validates and exchanges transaction data; settlement moves funds between institutions in the ecosystem. A concise explainer of clearing vs settlement is here: Clearing vs. settlement: Key differences explained
3) Payout: the funds become “available” in your Tide business account
Tide states that you receive Tap to Pay on iPhone payments into your Tide business account within 3 business days. When will I receive my payments taken using Tap to Pay on iPhone?
“Business days” typically means working days (weekends and bank holidays can affect when a “day” counts in practice), so a late-week sale can land after the weekend even if nothing has gone “wrong”.
For a general view of how settlement and “funds in your bank” timing can differ, see: How Payment Settlement Works and How Long It Takes
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Customer taps, you see confirmation, but balance doesn’t change immediately | Payment may be authorised but not yet paid out | Cashflow planning needs a lag between sale and usable funds |
| Payment appears in sales activity but not in “settlements” yet | Processing lifecycle still in progress | Reconciliation needs “status-aware” matching, not one-step matching |
| Payment is “settled” in processing records but not “available” in Tide balance | Settlement completed; payout pending | Expect a timing gap; treat “settled” as not-yet-cash |
| A payout lands as a batch rather than per sale | Multiple transactions grouped | Back-office matching requires batch reconciliation rather than 1:1 |
| A refund is initiated | Refund becomes its own lifecycle item | Customer experience depends on refund processing time, not just the initial sale |
| A dispute/chargeback is raised later | Funds may be withheld or offset depending on the flow | Revenue recognition and cash availability can diverge during disputes |
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| “It worked, but I can’t use the money yet” | Authorisation recorded; clearing/settlement/payout still running | Not yet available balance |
| “It says settled – why no payout?” | Settlement completed in processor/acquirer records; payout schedule still pending | Settlement ≠ paid out |
| “I can’t match today’s sales to today’s bank balance” | Settlement batches and payout batching | Reconciliation requires batch matching |
| “Refund requested, customer still waiting” | Refund has its own processing timeline | Customer may see delay before funds return |
| “Dispute created a negative swing” | Dispute handling can involve temporary withholding/offsets | Availability can change after the original sale |
| “Everything looks delayed at once” | Operational or risk controls can pause or slow flows | Multiple payouts may be affected together |
How to track what’s pending vs paid out in the Tide app
For Tap to Pay on iPhone transaction tracking, Tide’s guidance points you to Sales > Performance > Settlements in the app. How can I accept payments with Tap to Pay on iPhone?
A practical way to use this in day-to-day ops is to separate your checks into two questions:
Is the transaction recorded and progressing (authorised/processing/settlement status)?
Has the payout actually arrived (available balance movement/payout entry)?
That separation reduces false alarms where a payment is real and progressing, but simply not yet paid out.
Why “available” can be later than expected (common causes)
Most “payout timing” questions come down to the difference between:
a transaction event (authorisation/settlement records), and
a cash movement event (payout landing).
Some common factors that can extend the gap include:
Working-day timing (weekends and bank holidays),
Batching (payouts can arrive grouped),
Exception flows such as refunds and disputes.
On disputes specifically, it’s worth understanding that card disputes can create downstream withholding or offsets depending on the chain and rules.
A broader explainer of who can withhold funds in settlement/dispute situations is here: Chargebacks and card disputes with EMI settlements: who can withhold funds?
Separately, “processor holds/reserves” is a concept that can appear when risk controls change or accounts are reviewed, which can affect payout timing in some setups. Bank restriction triggers: processor holds, reserves and payout delays
Tide Business Bank Account
Tap to Pay on iPhone is one part of the wider Tide product set (business account plus tools). For a neutral overview of Tide account features, typical suitability considerations, and trade-offs, see our Tide business account review.
Frequently Asked Questions
- “Authorised” means the customer’s bank has approved the transaction at the moment of the tap. It’s the “permission to proceed” stage and often shows up immediately as a successful payment event.
- “Settled” comes later and refers to the processing stages after authorisation, where transaction data and funds movements are finalised within the payments ecosystem. A payment can be authorised and still not be settled yet, and either can still be separate from when the payout becomes available in your account.
A successful tap typically confirms the authorisation outcome, not the payout. The payout is a later cash movement, and it can lag behind the successful payment event.
In practice, the most useful distinction is: “Did the payment happen?” versus “Has the payout landed?” Those questions can have different answers for a period of time without implying an error.
“Available” is best understood as “usable balance in your Tide business account”. It’s the point at which funds are accessible for normal spending/transfer activity (subject to the normal functioning of the account).
This differs from “authorised” or “settled” labels, which can be true while cash is still moving through the payout process. In reconciliation terms, “available” is the point where sales become cash.
They can, because many payout timelines are described in business days, and bank holidays/weekends can change what counts as a working day for processing and bank posting.
This matters most for late-week trading: a sale late on a Friday can appear “stuck” over the weekend even when it’s progressing normally. The visible status can advance before the cash movement shows in the balance.
In some payment flows, an authorisation can be reversed/voided before it becomes a completed, settled transaction (for example, if the transaction is cancelled promptly or fails at a later step).
From an operations standpoint, this is one reason to avoid treating “authorised” as final revenue until you can see it captured/settled and then paid out. The important edge case is where a customer sees a pending item that later drops off their statement.
Refunds are a separate flow that can run on a different timeline from the original payment. Even when a refund is initiated promptly, the customer’s card issuer still needs to process and post it.
Operationally, refunds can complicate reconciliation because a refund can land in a different batch or on a different day from the original sale. That’s normal in many card-based systems and is best handled by matching refund references/statuses rather than assuming same-day netting.
Yes. Settlement is not the end of the “customer dispute window” in card systems. Chargebacks and disputes can occur after the original settlement depending on the scheme rules and circumstances.
The practical implication is that “settled” should be treated as “completed processing for that transaction stage”, not “permanently undisputed”. Disputes can affect later cash availability if funds are withheld or offset during dispute handling.
Batching is common: multiple transactions can be grouped into a settlement/payout batch. That can make bank balance movements look less intuitive if you expect a one-to-one match between each sale and each payout.
This is mostly a reporting and reconciliation issue rather than a payments issue. It typically means matching a payout to the set of transactions included in that payout period rather than searching for a single corresponding sale.
A decline problem happens at or before authorisation: the payment never successfully completes at the point of sale. A payout timing problem happens after a successful payment event, when cash movement lags behind transaction recording.
The edge case is partial or intermittent failures: some payments authorise while others decline due to card/issuer/device factors. That’s why it’s helpful to separate “can’t take payment” troubleshooting from “took payment but funds aren’t available yet” troubleshooting.
For payments, the most useful evidence usually includes the transaction details from the acceptance system (date/time/amount/transaction identifier) and any settlement record where available.
For refunds, evidence often comes down to the refund record (date initiated, amount, and reference). Customers may still see the credit arrive later because issuer posting timelines can differ; the same refund can appear at different times depending on the card issuer’s processing.
Most confusion around payout timing comes from mixing up three different “truths” that can all be valid at the same time:
- The customer’s bank approved the payment (authorised)
- The payment moved through clearing/settlement records (settled)
- The money reached the business’s usable account balance (available). Payment systems are designed this way because the “permission to pay” step needs to be fast at the checkout, while the “final accounting and cash movement” steps often happen later in batch-oriented systems.
When teams align their reporting and ops around those stages – treating “authorised” as a checkout event, “settled” as a processing event, and “available” as a cash event – day-to-day reconciliation tends to become simpler and fewer issues are escalated as “missing payouts” when they are actually “in flight”.
Sources & References
Related Content
