--- title: "Withdrawal in Ingrid Returns and Tracking" canonical: "https://ingrid-support.refined.site/space/KB/608763909/Withdrawal%20in%20Ingrid%20Returns%20and%20Tracking" format: markdown --- 🚧 **In delivery — feature ships in phases.** The Ingrid API, the Back-office indicators, and the withdrawal confirmation email are available today. The customer-facing UI and the withdrawal-window countdown are still in design or development. This article describes the **intent** of the full feature so you can plan your integration. Talk to your Ingrid CSM about timing for the pieces relevant to your setup. ## What is it? In the EU, consumers have a legal **right of withdrawal** — the ability to cancel an online purchase within a set window without giving a reason. Until now, merchants have implemented this on their own — typically with custom forms, custom emails, and a custom way of marking the order as withdrawn in their systems. Ingrid's Withdrawal feature brings this flow into the products merchants already use — **Tracking** and **Returns** — so the experience for the shopper, the data flow for the merchant, and the integration with downstream systems all work the same way as the rest of the Ingrid platform. The result: one customer-facing withdrawal flow, one consistent data model in the Back-office, and one stable API surface — replacing per-merchant custom builds. --- ## Why we're building it this way Merchants come to Ingrid with different combinations of products — some use Tracking, some use Returns, some both, some neither. Withdrawal is designed to fit into what you already have. The button can live where you already have Ingrid surfaces, and the flow behind it adapts to whether you have Ingrid Returns or not. --- ## How it works (high level) 1. **Eligibility check** — Ingrid's backend determines whether withdrawal is available for a given order (based on delivery state, merchant configuration, and withdrawal window) 2. **Entry point** — if eligible, a Withdrawal CTA appears in a customer-facing surface (Tracking Widget, Tracking Portal, or the Returns Widget). A tracking notification can link the customer to one of these surfaces, where the CTA is shown. 3. **Form** — the customer continues to a withdrawal form. If you have Ingrid Returns, the form is hosted in the Ingrid Returns Widget. Otherwise, the customer is redirected to your own withdrawal form. 4. **Confirmation** — after the form is submitted, an asynchronous event confirms the withdrawal in Ingrid's backend 5. **Communication** — a confirmation email is sent to the customer (by Ingrid if you use the Returns Widget; by you in the redirect setup) 6. **Data surfaces** — the order or return is flagged as a withdrawal across Ingrid's API, webhooks, and Back-office --- ## Where the withdrawal button can live The Withdrawal CTA can be placed in any of the following surfaces, depending on which Ingrid products you have: - **Tracking Widget** — embedded in your storefront or order confirmation page - **Tracking Portal** — Ingrid's hosted tracking page - **Returns Widget** — Ingrid's hosted returns flow The button only appears when Ingrid's backend confirms the order is eligible for withdrawal. 💡 **About tracking notifications:** Ingrid's tracking emails and SMS don't embed the Withdrawal button itself — they include a link to your Tracking Widget or Portal, where the customer sees the CTA. --- ## Configuration patterns Withdrawal supports two end-to-end configuration patterns. The right one depends on whether you have Ingrid Returns. ### Pattern A — Redirect (for Tracking-only merchants) | Step | Owner | | --- | --- | | Withdrawal button in Tracking surface | Ingrid | | Withdrawal form | **Merchant** (your own system) | | Confirmation email to customer | **Merchant** | Use when you have Ingrid Tracking but not Ingrid Returns. Ingrid handles the entry point — the Withdrawal CTA in your Tracking surface — and redirects the customer to your existing withdrawal form. You stay in control of the rest of the flow. ### Pattern B — Full Ingrid flow (requires Ingrid Returns) | Step | Owner | | --- | --- | | Withdrawal entry point | Ingrid Tracking surface (if you also have Tracking) or your own customer UI | | Withdrawal flow | **Ingrid Returns Widget** (in withdrawal mode) | | Confirmation email to customer | **Ingrid** | Use when you have Ingrid Returns. Ingrid handles the entire customer-facing flow — form, confirmation, and email — using the Returns Widget in withdrawal mode. If you also have Ingrid Tracking, the Tracking surface can host the entry point. 💡 **An Ingrid-hosted withdrawal form for Tracking-only merchants is not in scope for this iteration.** It may be added later if there's enough merchant interest — talk to your CSM if this would be valuable for you. --- ## Which pattern fits you? | You have today | Suggested pattern | | --- | --- | | Ingrid Tracking only | Pattern A — redirect to your own withdrawal form | | Ingrid Returns | Pattern B — full Ingrid flow via Returns Widget | | Ingrid Tracking + Returns | Pattern B — use the Returns Widget; the Tracking surface hosts the entry point | | Ingrid Checkout only | Adding Tracking or Returns unlocks withdrawal — talk to your CSM | --- ## What you'll see in your systems today The following parts of withdrawal are available **today**: ### Returns API The `withdrawal` flag is a top-level boolean on the return object. It's exposed on: - The [Ingrid Returns Partner API](https://api.ingrid.com/returns/partner-api-docs.html) - The legacy Merchant API - All outbound return webhooks ### Filtering `GET /returns` accepts a filter parameter so integrators can fetch only withdrawals (or exclude them) without scanning the full list. ### Returns Back-office - A **WITHDRAWAL** chip appears on the return detail page and in the returns list - Filters in the returns table and statistics dashboards let merchants include, exclude, or isolate withdrawals - Withdrawals can be processed like ordinary returns when needed ### Returns Widget plumbing The Returns Widget already accepts `withdrawal=true` as a URL query parameter — when set, the session is flagged as a withdrawal and the flag flows through to the return object. ### Withdrawal confirmation email A **Withdrawal registered** email template is available in Returns Back-office under `Settings → Email Templates`, in the Withdrawal group. It is sent when a return is registered with the withdrawal flag set, and tells the customer the withdrawal was recorded and that return instructions may follow depending on the status of the order. You can edit its subject, preheader, and body, per language, and it carries the order ID and the time the withdrawal was submitted. See [Email templates in Ingrid Returns](https://support.ingrid.com/space/KB/726859778/Email+templates+in+Ingrid+Returns). --- ## What's planned next The following pieces are in design or development: - **Withdrawal-specific UI** in the Returns Widget — copy, banners, disabled exchanges and complaints, a "no return reason" option, and an email-confirmation step at the end of the flow - **Withdrawal-window countdown** — the Tracking App and Returns Widget will show how many days are left to withdraw - **Tracking Widget and Portal CTA** — the actual Withdrawal button surfaced in Tracking, with eligibility-driven enable or disable behavior - **Outbound webhook for withdrawals** — a dedicated withdrawal event (name to be finalized) for CRM, analytics, and compliance pipelines (optional, for merchants who want a system-of-record signal) --- ## Integrator notes This section is for developers wiring withdrawal into merchant systems. ### Return object The `withdrawal` flag lives at the return level — not the line-item level. A return is either a withdrawal in full or it isn't. ### State semantics Withdrawal state transitions are **monotonic** — once a withdrawal is confirmed, it cannot be "unconfirmed." Ingrid's backend processes confirmation events asynchronously, so a short delay between the customer's action and the visible state change in the UI is expected. ### Idempotency If you're sending confirmation events to Ingrid (Pattern A redirect with Ingrid-handled confirmation, or Pattern B entry from your own UI), follow these principles: - Duplicate event IDs are treated as no-ops - Older events do not overwrite newer state (Ingrid uses `occurred_at` timestamps and event IDs to enforce ordering) - Required event payload includes a mandatory `occurred_at` timestamp; an optional list of items can be included ### Outbound webhook (planned) 🚧 The event name and payload below are **indicative and subject to change** — the dedicated withdrawal webhook is still in design. Confirm the final contract with your CSM before building against it. When live, a dedicated withdrawal webhook will fire after Ingrid has persisted the confirmation. Indicative payload shape: - Event type: a dedicated withdrawal-confirmed event (name to be finalized) - Identifiers: `site_id`, `order_external_id` - Timestamps: `occurred_at` (from the source) and `acknowledged_at` (when Ingrid persisted it) - Optional `items[]` - `event_id`, `version`, and `source` fields for downstream traceability HTTPS-only delivery; endpoints are customer-configurable per site and environment. --- ## FAQ **Q: Can my customers use this today?** A: Parts of the flow are live: the API, the Back-office indicators, the Returns Widget's `withdrawal=true` URL parameter, and the withdrawal confirmation email. The customer-facing Withdrawal button in Tracking and the countdown UI are still in development. Talk to your CSM about timing for the pieces relevant to your setup. **Q: How will my customers know they can withdraw an order?** A: Once the customer-facing UI is live, an eligible order will show a Withdrawal CTA in the surface(s) you've configured (Tracking Widget, Tracking Portal, or Returns Widget). A tracking notification can link the customer to one of these surfaces. The CTA appears only when Ingrid's backend confirms the order is eligible. **Q: What about exchanges and complaints during a withdrawal flow?** A: When the Returns Widget is in withdrawal mode, exchanges and complaints are disabled — withdrawal is a clean "cancel this purchase" intent, not a returns or exchanges decision. **Q: Can I customize the withdrawal confirmation email?** A: Yes. The **Withdrawal registered** template is in Returns Back-office under `Settings → Email Templates`, and you can edit its subject, preheader, and body per language. Note that complete default templates currently exist in English, Swedish, Norwegian, German, Spanish, French, and Danish for this email. See [Email templates in Ingrid Returns](https://support.ingrid.com/space/KB/726859778/Email+templates+in+Ingrid+Returns). **Q: Can I customize the withdrawal form?** A: In Pattern A (redirect), you host the form yourself and have full control. In Pattern B, Ingrid hosts the form via the Returns Widget — with the same customization options as the rest of the Returns Widget. An Ingrid-hosted form for Tracking-only merchants is not planned in this iteration. **Q: What happens after the withdrawal window expires?** A: The CTA no longer appears. Internally, Ingrid moves the state to "withdrawal window expired" — customer-facing surfaces show appropriate copy ("Withdrawal is no longer available"). **Q: Will Ingrid handle the refund for a withdrawal?** A: No. Withdrawal in Ingrid is the customer-facing flow and the data model. The refund itself is processed in your e-commerce or payment system based on the withdrawal signal Ingrid passes via API or webhook. **Q: Does adding withdrawal change anything in my checkout flow?** A: No. Withdrawal is post-purchase. Your Ingrid Checkout integration is unaffected. --- ## More information Withdrawal is being delivered in phases. For timing on the pieces relevant to your setup, talk to your Ingrid CSM. --- ## Related documentation - [Ingrid Returns](https://support.ingrid.com/space/KB/104628230) — how returns work in Ingrid, end to end - [Email templates in Ingrid Returns](https://support.ingrid.com/space/KB/726859778/Email+templates+in+Ingrid+Returns) — the full set of return emails, including the withdrawal confirmation - [Ingrid Returns Partner API reference](https://api.ingrid.com/returns/partner-api-docs.html) — for developers building custom returns flows - **Setting up returns on your platform** — [Centra: refunds, exchanges & payments](https://support.ingrid.com/space/KB/583827461)