Tide Instant Checkout Refunds Explained: How Refunds Are Processed and Tracked

Tide’s Instant Checkout refund flow begins by selecting the relevant transaction inside the Tide app and requesting a customer refund.

Tide’s own support article outlines this path (Sales > Performance > select the transaction > request customer refund) and indicates follow-up support via in-app messaging in its Instant Checkout refund guidance: How do I refund an Instant Checkout payment?.

Operationally, that request is the start of a card-refund process rather than an immediate “credit to customer”. The refund instruction still needs to move through card processing and then be applied by the card issuer.

“Request Customer Refund” is best understood as initiating a refund workflow that will be processed through card payment rails.

Tide’s support content explains that the request triggers follow-up assistance in-app (for example, messaging within a stated window) in How do I refund an Instant Checkout payment?.

From there, the refund moves into processing steps that may include confirmation/authorisation and bank-side handling.

Tide’s broader refund help guidance describes that the recipient’s bank can have a decisive role in whether the refund is processed and that timelines can extend (including references to “up to 14 business days” in its help centre article): Refund a payment back.

Refund timelines vary because they include multiple organisations’ processing steps. Tide’s help centre material states that, once authorised, a refund may take time to be processed – including “up to 14 business days” in its refund guidance: Refund a payment back.

Tide also references “up to 14 business days” in its refund FAQ for card-reader payments, which can be a useful comparison point for expectations: How do I refund a payment to my customer?.

A key practical implication is that “refund started” and “refund received by customer” can fall on different dates. The customer’s bank/card provider controls when the credit posts to the account, and posting can be influenced by internal issuer batching and statement cycles.

Merchant-side visibility can precede issuer-side posting. The Tide app can show that a refund has been initiated or is progressing while the customer’s bank has not yet applied the credit. Tide explicitly acknowledges that refunds can take time to complete in Refund a payment back.

In practice, this becomes a tracking problem rather than a “missing refund” problem. The issuer may not locate the refund using a merchant order number, because issuer systems typically work with card-rail identifiers rather than your internal references.

That is where tracing references (like ARN) can become relevant (see the tracking FAQ below).

In card payments, partial refunds are generally possible in many setups, and multiple refunds can sometimes be created against the same original payment (for example, refunding one item today and another later).

The important operational detail is that multiple refunds can post as separate credit entries on the customer’s statement rather than one combined line.

This creates a reconciliation edge case: your merchant records may show “order refunded” at an item level, while the customer sees several separate credits. That’s not necessarily a contradiction – it’s a difference in how merchant systems and issuer statements represent the same underlying flow.

If your business uses multiple Tide payment tools, keeping Instant Checkout distinct from Payment Links can also reduce confusion; see Tide Instant Checkout vs Payment Links: Key Differences.

ARN stands for Acquirer Reference Number. Banks and payment platforms use it as a way to identify and trace card transactions across the acquiring and issuing sides.

• NatWest describes ARN as an identifier generated to identify debit card payments for goods or services: What is an ARN (Acquirer Reference Number)?.
• Adyen describes ARN as a unique number assigned to credit card transactions and notes it can be used to check transaction status (including refunds), and that banks can use it to track a refund: Where can I find the Acquirer Reference Number (ARN)?.

The practical implication is that, if a customer’s bank is looking for a refund and can’t locate it using merchant-side descriptors, an ARN can be a more usable tracing handle within issuer workflows.

Whether an ARN is available to you depends on the systems and reporting available in your payment chain.

International refunds can produce “same currency, different GBP amount” effects. Tide’s refund guidance states that refunds on non-GBP card transactions are processed at Mastercard’s exchange rate on the day and that exchange rates can differ from the original purchase day; it also states that currency exchange fees are not refunded: Refund a payment back.

This creates a predictable edge case: a customer might compare the original GBP amount they saw on their statement with the later GBP amount they receive on refund and conclude something is wrong. In many cases, the difference is simply the mechanics of FX conversion and fee treatment at the time the refund is processed.

Card systems can treat “undoing” a transaction differently depending on timing and scheme/processor behaviour. In everyday language, people say “refund”, but the underlying event may be recorded as a reversal/void in some contexts, or as a refund event in others.

From a tracking standpoint, this matters because reversals and refunds can look different on statements and in merchant reporting. Even when the commercial intent is identical (“customer gets their money back”), the identifier used for tracing and the way it posts can vary by issuer and timing.

A refund and a chargeback are different processes. A refund is merchant-initiated and runs through the card rails to the issuer. A chargeback is a bank-initiated dispute route and is subject to scheme rules and evidence handling.

Visa’s guidance explains the difference and notes that chargeback is not a legal right and is not guaranteed: Chargeback: debit and credit card purchase disputes.

Where both are in play, the practical complication is usually administrative rather than “two payouts”. Issuers and schemes aim to avoid double recovery.

The Financial Ombudsman Service’s guidance is focused on how banks handle disputes and time limits, but it also reflects that outcomes depend on evidence and the rules in force: FOS guidance on goods/services bought with credit.

Account restrictions and closures can change which functions work normally and which require manual handling or support intervention. The reason is that payment and refund rails involve risk controls, compliance checks, and operational constraints that can pause or limit certain activities.

If you’re trying to understand the “what still works” question during restrictions, this is treated separately in Tide account locked or frozen: what usually still works. That context can help explain why refund processing and timelines may look different during a restriction period compared with routine operations.