Wizard zwrotu — UX klienta

Klient inicjuje zwrot przez wizard 3-krokowy na stronie /returns/?order=ID (klient zalogowany) lub /returns/ z weryfikacją email + order_key (gość). Wzorowane na flow Zalando — per-item granularność, strukturyzowane powody, czytelne podsumowanie.

Krok 1 — Items (wybór produktów)

Lista wszystkich pozycji z zamówienia (każdy WC_Order_Item_Product). Per-row:

• Thumbnail produktu
• Nazwa produktu + atrybuty wariantu
• Ilość zamówiona + cena jednostkowa
• Checkbox „Return this item”
• Input qty (max = ordered qty, default = ordered qty)

„Next: Reasons” wymaga zaznaczenia co najmniej jednej pozycji. Klient może zwrócić 1 z 3 sztuk tego samego produktu (per-item granularność).

Krok 2 — Reasons (powody zwrotu)

Renderowane są tylko pozycje wybrane w Kroku 1. Per-item:

• Dropdown z 8 reason codes (zobacz niżej)
• Textarea „Add a note” (opcjonalna, wymagana dla powodu „other”)

8 reason codes

• too_small — Item too small
• too_large — Item too large
• quality_mismatch — Quality not as expected
• description_mismatch — Item does not match the description
• damaged — Item damaged or defective
• wrong_item — Wrong item received
• dont_like — I do not like it / changed my mind
• other — Other (free text required)

Krok 3 — Summary (podsumowanie)

• Read-only tabela: produkt, ilość, powód (label)
• Obowiązkowy checkbox „I understand this initiates a return request and that I will receive a confirmation by email”
• Przycisk „Submit return request” → REST POST /submit

Po submicie

1. Tworzona jest parent-row w wpnest_rfw_requests + N item-rows w wpnest_rfw_request_items
2. Status zamówienia WC zmieniany na wc-rfw-pending
3. Generowany jest PDF potwierdzenia (token 32-hex w nazwie) i zapisywany w wp-content/uploads/wpnest-rfw/
4. Klient i sklep dostają plaintext maila z PDF + modelowym formularzem odstąpienia (PL lub EN wg locale klienta)
5. Fires akcja wpnest_rfw_request_submitted (Pro nasłuchuje dla SMS, etykiety, webhook)

Gość flow (bez konta)

1. Klient wchodzi na /returns/
2. Wpisuje email + order_key (z maila potwierdzającego zamówienie)
3. POST /verify-guest → walidacja (rate-limit 5/h per IP-hash)
4. Po sukcesie: tworzony 15-min token transient + renderowany wizard inline z tokenem jako hidden input
5. Submit działa identycznie jak dla zalogowanego (token zamiast cookie auth)