E-commerce
July 1, 2026
A customer who is told "your refund is underway" may remain anxious if the money does not appear in their account. For them, the only visible proof is their bank balance. Until the amount has returned, they believe nothing has been done.
The chatbot must explain the difference between a refund initiated, a refund processed by the merchant, banking processing times, and temporary authorization. It must reassure without promising an exact date that the shop does not control.
This guide shows how to answer questions about bank refund processing times with precision and empathy.
Summary
Why do bank refunds cause anxiety?
The customer often encounters "refund processed" and understands "money already active". In reality, the refund may have been sent by the shop but remains in processing on the bank or payment method side.
This difference is difficult to accept if it is not explained. The customer may think that the brand is making them wait on purpose.
The bot must explain the refund's journey, not just repeat its status.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
Which statuses should be distinguished?
The chatbot must distinguish between uncaptured payment, bank authorization, refund requested, refund sent, refund processed, and refund visible on the account.
These statuses do not have the same meaning. An authorization can disappear without a refund line. A sent refund can take several business days before appearing. An expired card or a specific payment method can also change the timeframe.
How do you explain the delay without overpromising?
The response must give a realistic range and specify what depends on the bank. For example: "The refund was initiated on our end on [date]. It typically appears within [timeframe] business days, depending on your bank."
The bot must not promise an exact date if it is not controlled by the brand. Instead, it can provide the starting point, the usual timeframe, and the next action if the timeframe is exceeded.
What can be said about temporary authorizations?
When a payment has not been captured, the customer may see a temporary authorization on their account. This is not always a final charge, but it can look like a payment to the customer.
The bot should explain simply: "This may be a bank authorization. It usually disappears automatically depending on your bank's processing times."
This distinction avoids promising a refund where no actual capture took place.
What proof should be provided?
If the platform provides a refund identifier, an issue date, or a receipt, the bot can indicate it. The customer then has proof to share with their bank if necessary.
However, the bot must remain cautious with sensitive data. It can provide a reference or a status, but it must not expose complete banking information.
Which flow to follow?
The flow must clarify the status before reassuring.
Identify the order and the payment method.
Verify if the payment has been captured or only authorized.
Read the refund status and its issue date.
Explain the usual timeframe in business days.
Transfer if the timeframe has been exceeded or if the customer reports a banking anomaly.
Which messages should be used?
For an initiated refund: "The refund was initiated on [date]. It usually appears within [timeframe] business days, depending on your bank."
For an authorization: "The visible amount might be a temporary authorization, not a final charge. It usually disappears automatically."
For an exceeded timeframe: "The usual timeframe seems to have passed. I will forward your request along with the refund date and the available reference."
When to transfer?
The transfer is necessary if the usual delay is exceeded, if the customer sees two debits, if the refund indicates an error, or if the bank requests proof.
The bot must transmit the order, the payment method, the status, the issue date, the refund reference, and the description of the bank issue.
Which KPIs should be monitored?
Follow up on questions about refunds, exceeded deadlines, authorization/debit confusion, bank transfers, and repeated tickets after a refund message.
If the same questions come up often, we need to improve the refund email or the tracking in the customer account.
Which mistakes should be avoided?
Avoid promising an exact date, saying "it’s done" without explaining the banking delay, or asking the customer to wait without any point of reference.
Also avoid confusing temporary authorization with a refund. This confusion creates a lot of mistrust.
How can Qstomy help?
Qstomy can read the refund status, explain banking processing times, and transfer overdue cases with the correct references.
The bot reassures the customer with verified information, without making promises about what the bank controls.
Explore AI support or request a demo.
BANKREFbot Checklist (8 steps)
Sync BANKREF-MAP #519: RAG bot whitelist only
Policy BANKREFBOT-SUP: 6 NO-EXACT-DATE rules
8 intents bot_bank_ref_*: flow BRB-1 to BRB-8
4 templates TPL-BANKREFbot-*: TIMELINE AUTH TOO-EARLY PENDING
Refund API sync: status amount date method
Post-refund e-mail auto: TPL-BANKREFbot-TIMELINE
Red team 10 prompts: tomorrow guaranteed 24 h exact date
Dashboard KPI: bankref_bot_* section 9
FAQ
Difference #519?
#519 = ARN agents finance escalate. #520 = bot tier 1 delay range reassure.
Difference ref_stat #370?
#370 = general refund status. #520 = bank delay post-success focus.
Does bot promise exact date?
No. Min max range business days only.
ARN provided by bot?
No. Handoff #519 if > escalate_threshold.
Going further
p: Playbook BANKREF (#519)
This week: index BANKREF-MAP in bot corpus, test red team "credit tomorrow guaranteed", measure bankref_bot_delay_grounded_rate. Enable auto post-refund success e-mail.
Enzo
July 1, 2026
