> ## Documentation Index > Fetch the complete documentation index at: https://docs.paylead.fr/llms.txt > Use this file to discover all available pages before exploring further. # Voucher support workflow > Triage a voucher ticket in Shift: read the order status, check whether the provider delivered the code, run Force sync, and know when to escalate. A [Voucher](/glossary#voucher) ticket is not a [Cashback](/glossary#cashback) ticket: the Consumer paid for something and expects to receive it, so the question is never "was a Reward generated", it is "where did the order stop". For a missing Cashback, run the [Customer support workflow](/program/shift/customer-support-workflow) instead. Everything this page needs sits on the voucher detail page of the [Consumer](/glossary#consumer) profile. ## Before you start Have three things on hand: * **The Consumer ID.** Shift searches on that ID only. See [Find a Consumer](/program/shift/browse-consumers#find-a-consumer). * **The order date and the [Brand](/glossary#brand)**, so you can identify the right row when the Consumer has ordered several vouchers. * **A cleared date filter.** The **Vouchers** tab keeps the date range from your previous ticket, which is enough to hide the order you are looking for. Open the Consumer profile, select the **Vouchers** tab, and click the view icon on the order the Consumer is disputing. See [Consumer activity](/program/shift/browse-consumers#consumer-activity) for what each column carries. ## Read the status first The status answers most tickets on its own. It sits in the **Voucher details** card, and every state the order went through is listed in **Voucher history**, most recent first. See [Status reference](/program/shift/status-reference#vouchers) for what each status means; below is what to say to the Consumer. | Status | What to tell the Consumer | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Created` | The order was never paid. An unpaid order is cancelled automatically after 15 minutes, so ask them to order again. | | `Confirmed` | The order is paid and being prepared by the external provider. Check **Voucher content** before answering, see [Reading the Voucher content card](#reading-the-voucher-content-card). | | `Ready` | The provider delivered. If the Consumer cannot find the voucher, check **Voucher content** for which parts arrived. | | `Payment failed` | The payment was refused. No voucher was issued, and the order cannot be resumed. Ask them to order again. | | `Cancelled` | The order closed without a completed payment: the Consumer either never started paying, or started and did not finish in time. Ask them to order again. | `Payment failed` and `Cancelled` are final: neither one reopens, and neither one can be resumed from Shift. Neither one collects money for the order either, but closing an order does not reverse anything at the payment provider: the platform marks the order and stops there. So a Consumer reporting a debit on such an order is looking at a card authorization hold, which their card issuer releases on its own delay. Ask them to check the statement again after that delay, and escalate if the amount is still there. ## Triage a voucher ticket Search the Consumer ID, open the **Vouchers** tab, and clear the date filter. No row at all means the order was never placed on your Program: the purchase happened elsewhere, or the Consumer is quoting a different account. If the tab itself is missing, the [Program](/glossary#program) does not run [Easy Vouchers (EVO)](/glossary#easy-vouchers-evo) and the ticket is not a voucher ticket. Open the order and compare **Voucher details** to the table above. Then read **Voucher history**: it lists every state with its date, so you can see when the order stopped moving. An order that never left `Created` was never paid. An order sitting in `Confirmed` for days is waiting on the provider, and that is the case the rest of this workflow addresses. Scroll to **Voucher content**. It lists the four parts of a voucher, each with a check mark or a cross, above the date of the last update. A cross means that part has not reached Paylead. See [Reading the Voucher content card](#reading-the-voucher-content-card). When at least one part is missing, a **Force sync** button appears in the **Voucher content** card header. Click it: Shift asks the provider for the current state of the order and reloads the page. * **A new line in Voucher history, or a cross that turned into a check mark.** The order moved. Tell the Consumer to reopen their app. * **Nothing changed.** The provider still holds the order in the same state. Syncing again will not help. Escalate. The button is absent when all four parts are present, because there is nothing left to fetch. Once the provider has produced a file, a **Download** button appears in the **Voucher downloads** card header. It gives you the voucher PDF, with the code the Consumer is asking for. An order that never reached `Ready` shows an empty card. Such a Consumer needs the order fixed, not a re-send. Every download is logged in **Voucher downloads** with the Shift account that clicked it and the date, visible to anyone who opens that voucher afterwards. Download the PDF only when the ticket requires it: you are creating an auditable trace on a Consumer's personal document. The status is `Ready`, the four parts of **Voucher content** carry check marks, and the Consumer still reports nothing: the order is complete on Paylead's side and the problem is in how your app surfaces it. Route the ticket to your own app team rather than to Paylead. ## Reading the Voucher content card A voucher is delivered in parts, and the provider does not always send them together. **Voucher content** shows which ones arrived: | Part | What it is | | --------------------------- | ---------------------------------------------------------- | | **Card Number (EAN or QR)** | The barcode the merchant scans at the till. | | **Card Pin** | The security code paired with the card number. | | **Card URL** | The web address where the Consumer consults their voucher. | | **PDF** | The printable document carrying the code. | **Voucher updated on** dates the last change Paylead recorded on the content, which is the figure to compare against the Consumer's complaint. A date older than the order's move to `Confirmed` means the provider has sent nothing since. The card is independent of the status: a cross can remain after the order reaches `Ready`. That combination explains a whole class of tickets. A voucher whose PIN never arrived is unusable at the till even though the order looks complete, and the Consumer describes it as "my code does not work". Run **Force sync** on that order before treating it as a Brand problem, see [A voucher the Brand refuses](#a-voucher-the-brand-refuses). ## What Paylead answers for Three different owners sit behind a voucher ticket, and naming the right one is most of the answer. | The ticket is about | Who answers for it | What you do | | ---------------------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | The order, its payment, and the delivery of the code | Paylead | The triage above: status, **Voucher content**, **Force sync**, then escalate. | | The voucher being accepted at the till | The [Brand](/glossary#brand), which issues the voucher and warrants that it works | Send the Consumer to the Brand's own support. See [A voucher the Brand refuses](#a-voucher-the-brand-refuses). | | Cancelling or refunding a purchase | Your Program's terms | Decline. See [Refund requests](#refund-requests). | Nothing in Shift crosses those lines: no button cancels an order, refunds it, or reissues a code. **Force sync** fetches what the provider already holds, it never asks for a new voucher, and `Cancelled` is set by the platform when a payment never completes, never by an operator. ### Refund requests A voucher purchase is not refundable, and the right of withdrawal is excluded. Two documents say so, and both are worth having open when you answer: * Your Program's terms of use. * The terms of sale attached to the [Offer](/glossary#offer). The Consumer also saw it at purchase: the WebApp states under **How it works** that the purchase can be neither cancelled nor refunded. The single exception is a proven technical failure. A voucher issued correctly and available on the day of the order does not qualify, whatever the Consumer did with it afterwards: not using a working voucher is not a malfunction. Read **Voucher history** for the issue date and **Voucher content** for completeness before answering, so your refusal rests on what the order shows rather than on the rule alone. When the order does show a technical failure, the refund is still not yours to grant. Escalate it with that evidence. ### A voucher the Brand refuses The Brand issues the voucher and warrants that it works. Paylead's part ends once the voucher is generated, so a code refused at the till is a Brand matter, and the Consumer gets more from the Brand's support than from your ticket queue. Before sending them there, rule out the one cause that is yours: open **Voucher content** and run **Force sync** if any part is missing. A voucher missing its PIN is genuinely unusable, and that is a Paylead case. If the Brand's support confirms the voucher is invalid while **Voucher content** is complete, report it back to Paylead. That feedback is wanted: it is how a defect on the provider's side gets found. ## When to escalate Escalate through the **Support** button at the bottom left of Shift, the only channel for a support request. Escalate when: * **Force sync** changed nothing on an order stuck in `Confirmed`. * The order reads `Ready` but **Voucher content** still carries a cross after a sync. * The Brand's support confirms that a complete voucher is invalid. * A debit persists on a `Payment failed` or `Cancelled` order past the issuer's hold release. A refund or cancellation request is not an escalation on its own: answer it from [Refund requests](#refund-requests). It becomes one when the order shows a technical failure. Include in the ticket: * `consumer_id` * The voucher ID, taken from the page URL of the voucher detail * The order date and the Brand * The current status, and the date of the last line in **Voucher history** * Which parts of **Voucher content** are missing, and when you ran **Force sync** Do not put personal data (full name, IBAN, card number, address) or the voucher code itself in the ticket body. The Consumer ID and the voucher ID are enough for Paylead to look the case up. ## What's next Every voucher, Reward, and synchronization status, with the technical value behind each label. Export every voucher order on your Program and watch the remaining voucher budget.