# Returns

The inbox of customer return requests: confirm physical reception, reject a request with a reason, or trigger a return the customer will still have to sign.

Source: https://docs.sealtrust.io/en/console/retours/

---

This screen lists a brand's return requests and is where they get settled. Confirming reception executes the transfer of the token to the brand vault, and the operation cannot be undone. A request can also be rejected. Finally, the brand can trigger a return itself, which the customer still has to sign.

![The console returns screen, with its status filter and its table of requests](/console/retours.en.webp)

## What the screen shows

A brand selector and a "Trigger return" button, whose label, dialog title and "Product ID" field were left in English.

A "Status" filter with "All statuses", then the seven states: Requested, Signed by customer, Received, Completed, Rejected, Expired, Cancelled.

A table with eight columns: ID, "Product", "Token", "Status", "Reason", "Requested", "Expires", "Actions". The badge is green for "Completed", orange for "Signed by customer", red for "Rejected", neutral for "Expired" and "Cancelled". The free-text reason is stripped of any markup before display. Each row links to the detail page of the product concerned.

An orange banner when returns are not enabled for the brand, with an "Open brand settings" link. It only appears on a negative certainty. With no request: "No return requests".

## What you can do here

Filter the requests by status and by brand. The list returns 100 requests by default, 500 at most.

Confirm the reception of a signed return, after a browser confirmation reminding you that the transfer cannot be undone. The full transfer validation is replayed at that moment. The movement is recorded in the name of the customer who made the request; if that account no longer exists, it is recorded in the name of the signed-in administrator.

Reject a request with an optional reason passed on to the customer, capped at 2000 characters. Trigger a return by entering a product identifier and an optional reason: this only creates the request, at the "Requested" status, valid for 30 days.

## What governs access

A signed-in administrator account, otherwise the screen only shows "Loading returns…". The "Returns" sidebar entry is visible for every brand profile, and no plan is required.

"Confirm reception" stays inactive as long as the request is not at the "Signed by customer" status, with the "Only a consumer-signed return can be received." tooltip. It is inactive too when the brand is known not to have enabled returns; as long as that flag is unknown, the button stays active and the server settles it. "Reject" disappears on a request that is completed, rejected, cancelled or expired. The trigger button stays inactive with no product identifier.

Reception and triggering require the brand to have enabled returns, and triggering is only possible on an item still held by a customer.

## What the screen refuses

Confirming the reception of a return that is not signed by the customer: 409, "Return not receivable", the guardrail against unilateral repossession. For a brand that does not accept returns: 403, "This brand does not accept returns". After the expiry date: 409, "Return request has expired". With no validated transfer payload: 409. When a transfer is already running on that token: 409, "Return already in progress for this token. Retry shortly.". When the lock service is unavailable: 503, reception failing closed on purpose rather than risking a double transfer.

Rejecting a request that is completed, rejected, cancelled or expired: 409, "Return not rejectable". Triggering a return on a product with no holder, on an item already in the brand vault, on a product that already has an open request, or whose holder is not a registered customer: 409 in all four cases. An unauthorised brand: 403.