> ## Documentation Index
> Fetch the complete documentation index at: https://help.usetapp.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Refund an order

> Start a full refund from History and follow its initiated, completed or failed status.

Refund the full order from History only after confirming the order ID, items and total. The current implementation does not offer a partial-refund amount in this dialog.

## Who can do this?

The live refund endpoint currently enforces shop access for **Owners, Managers and Staff**. An older endpoint docstring says Owners and Managers, but the dependency actually authorizes all three roles; this guide follows enforced API behavior. Because refunds are high-risk, your internal policy may be stricter.

## Where to do it

Open the order in **History**. Refund is available for **PAID**, **COMPLETED** and **REFUND\_FAILED** orders.

## Start the refund

1. Check the shop and order ID.
2. Review the line items and total in the refund confirmation.
3. Select **Refund**, then **Confirm refund**.
4. Wait for the request to move to **REFUND\_INITIATED**.
5. Close the dialog if needed and monitor the order in History.
6. Treat **REFUNDED** as complete. If the status becomes **REFUND\_FAILED**, review the failure and use the available retry path.

For cash payments, the backend records the refund in Tapp without an Adyen network refund. For Adyen-backed payments, confirmation is asynchronous, so the initiated state can remain for a while.

History continues polling the canonical status. A timeout message means processing is still unresolved, not that a second refund should begin. Refund failed is explicitly retryable; Refund initiated and Refunded are excluded from the start action.

## Important safeguards

Do not submit another refund while the status is Refund initiated. The UI excludes initiated and already-refunded orders from the start action. Refund changes cannot be undone from this dialog.

## Platform and market notes

Refresh if a payment device or another operator changes the order. The status model is the same in GB and Germany. German fiscal consequences are handled by the underlying platform; do not invent or manually alter fiscal records based on this guide.

## Troubleshooting

If refund submission fails, refresh the order and confirm it is Paid, Completed or Refund failed. For Refund initiated, wait for confirmation. A polling timeout requires checking History later, not immediately submitting a duplicate refund.

## Related guides

* [Understand order details and statuses](/en/history/understand-order-details-and-statuses)
* [Print, email or text a receipt](/en/history/print-email-or-text-receipt)