Description

Returino adds a public 2-step withdrawal / return-request form to your WooCommerce store, built for Romania’s OUG 18/2026 requirements on digitising the withdrawal process (an online-accessible form and a durable-medium confirmation). The withdrawal right itself — the 14-day period, the exceptions and the refund — is governed by OUG 34/2014, which OUG 18/2026 amends rather than replaces.

The customer identifies their own order (order number + billing email), selects exactly which products to return — partial returns, not just the whole order — and receives a durable-medium email confirmation with the exact details of the request.

Key features:

Public 2-step form, without leaving your site — no external platform and no customer account required.
Partial returns: the customer picks exactly which products and quantities to return, not the whole cart.
Strict server-side validation — products and quantities are read straight from the order, not from what the customer’s browser submits.
IBAN requested only when it’s actually needed (cash on delivery, bank transfer) — card payments are refunded automatically to the card, with no IBAN prompt.
The return reason is optional — the customer can submit the request without filling one in.
Rejection reasons: define a list of preset reasons, then on rejection pick one or type it on the spot — the (mandatory) reason is sent in the customer’s email, shown on the request in My Account and on the admin request panel, and added as an order note.
Per-category rules: exclude certain categories from returns (the legal exceptions to the right of withdrawal — art. 16 of OUG 34/2014) or grant them a longer window — never under 14 days. Ineligible products are clearly marked on the form.
One active request per order: while one is in progress the customer can’t open another; after it’s resolved they can come back for the remaining items, and a rejection allows a fresh attempt.
Instant durable-medium email confirmation with the customer’s name, order number, exact products and the exact date/time of the request — useful for any consumer-protection (ANPC) checks.
The form page is created automatically on activation (if one doesn’t already exist) — nothing to set up by hand.
Dedicated “Returino” admin menu with all requests, real columns (Order, Client, Status, Items, Request date) and a status filter.
A clear approve/reject panel on each request — one click, without confusing “Publish”-style terminology.
Optional email notifications: to the admin on a new request, to the customer on approval/rejection — on top of the legal confirmation, which is always active.
Direct integration into the WooCommerce order screen (HPOS-compatible) — see at a glance whether an order has linked return requests.
A “My return requests” tab in the customer’s My Account, for logged-in customers.

Returino helps you implement the technical side of the OUG 18/2026 requirements (form, durable-medium confirmation, partial returns) — it is not legal advice and does not, by itself, guarantee your store’s full legal compliance. We recommend checking the exact requirements that apply to your business.

Requirements

WooCommerce active (declared explicitly via Requires Plugins).

În limba română

Returino adaugă magazinului tău WooCommerce un formular public de retur / cerere de retragere din contract, gândit pentru cerințele OUG 18/2026 privind digitalizarea procesului de retragere (formular accesibil online, confirmare pe suport durabil). Dreptul de retragere în sine — termenul de 14 zile, excepțiile și rambursarea — este reglementat de OUG 34/2014, pe care OUG 18/2026 o modifică, nu o înlocuiește.

Clientul își identifică singur comanda (număr comandă + email de facturare), selectează exact produsele pe care vrea să le returneze — retur parțial, nu doar integral — și primește o confirmare pe email, pe suport durabil, cu detaliile exacte ale cererii.

Funcționalități principale:

Formular public în 2 pași, fără să părăsească site-ul tău — nicio platformă externă, niciun cont necesar pentru client.
Retur parțial: clientul alege exact ce produse și ce cantități returnează, nu tot coșul.
Validare strictă pe server — produsele și cantitățile sunt reluate direct din comandă, nu din ce trimite browserul clientului.
IBAN cerut doar când chiar e nevoie de el (ramburs, transfer bancar) — la plata cu cardul, banii se întorc automat pe card, fără să mai ceri IBAN.
Motivul returului e opțional — clientul poate trimite cererea fără să completeze unul.
Motive de respingere: definești o listă de motive prestabilite, iar la respingere alegi unul sau scrii pe loc — motivul (obligatoriu) ajunge în emailul clientului, în contul lui și ca notă pe comandă.
Reguli pe categorii: excluzi anumite categorii de la retur (excepțiile legale de la dreptul de retragere — art. 16 din OUG 34/2014) sau le acorzi un termen mai lung — niciodată sub 14 zile. Produsele neeligibile apar clar marcate în formular.
O singură cerere activă per comandă: cât timp una e în lucru, clientul nu poate deschide alta; după rezolvare poate reveni pentru produsele rămase, iar o respingere permite o nouă încercare.
Confirmare instantanee pe email, pe suport durabil, cu numele clientului, numărul comenzii, produsele exacte și data/ora exactă a cererii — utilă și pentru eventuale verificări ANPC.
Pagina cu formularul se creează automat la activare (dacă nu există deja una) — nimic de configurat manual.
Meniu dedicat „Returino” în admin, cu toate cererile, coloane reale (Comandă, Client, Status, Produse, Data cererii) și filtru de status.
Panou clar de aprobare/respingere pe fiecare cerere — un click, fără termeni confuzi de tipul „Publish”.
Notificări opționale prin email: către admin la cerere nouă, către client la aprobare/respingere — pe lângă confirmarea legală, care rămâne mereu activă.
Integrare directă în ecranul comenzii din WooCommerce (compatibil HPOS) — vezi dintr-o privire dacă o comandă are cereri de retur asociate.
Tab „Cererile mele de retur” în contul clientului (My Account), pentru clienții logați.

Pluginul te ajută să implementezi partea tehnică a cerințelor din OUG 18/2026 (formular, confirmare pe suport durabil, retur parțial) — nu constituie consultanță juridică și nu garantează, prin el însuși, conformitatea legală completă a magazinului tău. Recomandăm verificarea cerințelor exacte aplicabile afacerii tale.

Installation

Instalează și activează pluginul (Plugins Add New, sau upload manual).
Asigură-te că WooCommerce e instalat și activ.
La prima intrare în admin după activare, pluginul creează automat o pagină cu formularul de retur (dacă nu găsește deja una cu shortcode-ul [returino_return_form]) și îți arată un notice cu link către ea — adaug-o în meniul din footer sau altă zonă vizibilă a site-ului.
Dacă preferi altă pagină, o alegi din dropdown-ul „Pagina de retur” din Returino Setări. Shortcode-ul trebuie pus direct în conținutul paginii — nu printr-un widget sau page builder, altfel stilurile/scripturile nu se încarcă automat.
Cererile de retur apar în meniul Returino din admin.

FAQ

Unde trebuie pus shortcode-ul ca să funcționeze corect?

Direct în conținutul unei pagini (bloc Shortcode sau editor clasic). Adăugat prin widget sau page builder, formularul poate tot apărea, dar stilurile/scripturile nu se încarcă automat.

Motivul returului e obligatoriu?

Nu, e opțional. Clientul poate trimite cererea fără să completeze un motiv.

Cere IBAN de la toți clienții?

Nu. IBAN e cerut doar pentru comenzi plătite ramburs sau prin transfer bancar. La plata cu cardul, câmpul nici nu apare — rambursarea se face automat pe card.

Cum aprob sau resping o cerere de retur?

Deschizi cererea din Returino Toate Retururile. În panoul „Stare cerere de retur” din dreapta ai trei butoane: „Marchează în procesare”, „Aprobă cererea”, „Respinge cererea” — un click, fără reîncărcare de pagină. Aprobarea/respingerea trimite automat emailul corespunzător clientului (dacă e activat în Setări) și adaugă o notă pe comandă.

Ce se întâmplă dacă un produs din comandă a fost șters ulterior?

Formularul afișează o imagine placeholder și numele produsului salvat pe linia comenzii — nu depinde de produsul mai existând în catalog.

E compatibil cu High-Performance Order Storage (HPOS)?

Da, compatibilitate declarată explicit; meta box-ul de pe ecranul comenzii funcționează atât cu tabelele custom de comenzi, cât și cu stocarea clasică bazată pe postări.

Site-ul e în spatele unui proxy/CDN (Cloudflare) și formularul se blochează pentru toți vizitatorii?

Limitarea de încercări la căutarea comenzii (10 căutări eșuate / 15 minute) se bazează implicit pe adresa IP a conexiunii (REMOTE_ADDR). În spatele unui proxy invers sau CDN precum Cloudflare, această adresă poate fi cea a proxy-ului, nu a vizitatorului — caz în care toți vizitatorii ajung să împartă aceeași limită.

Dacă site-ul tău chiar rulează în spatele unui astfel de proxy, poți suprascrie sursa IP-ului cu un filtru (ex. într-un plugin de site sau functions.php):

add_filter( 'returino_rate_limit_ip', function ( $ip, $server ) {
    return $server['HTTP_CF_CONNECTING_IP'] ?? $ip;
}, 10, 2 );

Folosește acest filtru doar dacă site-ul chiar e în spatele acelui proxy — altfel, orice vizitator îl poate ocoli trimițând el însuși acel antet.

Reviews

There are no reviews for this plugin.

Contributors & Developers

“Returino – Formular de retur for WooCommerce” is open source software. The following people have contributed to this plugin.

nord95

Translate “Returino – Formular de retur for WooCommerce” into your language.

Interested in development?

Browse the code, check out the SVN repository, or subscribe to the development log by RSS.

Changelog

1.2.5

New: rejection reasons. Merchants can define a list of preset reasons in
Settings, and rejecting a request now requires a reason — pick a preset
or type one on the spot. The reason is sent in the customer’s rejection
email, shown on the request in My Account and on the admin request panel,
and added to the linked order note. Works from both the request edit
screen and the quick actions on the WooCommerce order screen.
New: per-category withdrawal rules. Exclude specific product categories
from returns (the legal exceptions to the right of withdrawal — art. 16
of OUG 34/2014: personalised, sealed-then-unsealed, perishable goods,
etc.) or grant them a longer
window than the standard one (never shorter than 14 days). Ineligible
products are shown disabled with an explanation on the form, and the
rule is re-enforced server-side so it can’t be bypassed.
New: one active request per order. While a request is pending or being
processed, the customer can’t open a second one for the same order — they
see its status in My Account instead. Once it’s resolved they can submit
again: approved quantities are deducted (a line can’t be returned more
times than it was purchased), while a rejection frees the item up for
another attempt.
Change: the minimum configurable withdrawal period is now 14 days, the
statutory minimum under OUG 34/2014 — a longer window can still be set,
a shorter one can’t.
Change: the “Powered by Returino” credit in the confirmation email and on
the public form now links to returino.com (UTM-tagged), so store owners
can attribute the traffic. The email keeps its raster mark, which remains
the most reliable choice across email clients.
Fixed a legal-source error: the withdrawal exceptions (personalised,
sealed-then-unsealed, perishable goods, etc.) are defined in OUG 34/2014,
art. 16 — not OUG 18/2026, which only mandates the digital process
(button, form, durable-medium confirmation). Corrected throughout the
description and any user-facing text that misattributed them.

1.2.4

Admin menu icon is now the Returino mark instead of a generic dashicon.

1.2.3

Updated the plugin directory banner artwork. No code changes.

1.2.2

Updated the readme’s Description/Installation/FAQ to match the 1.2.0/
1.2.1 changes — Installation no longer tells you to create the return
page by hand (it’s created automatically), and there’s a new FAQ entry
on how to approve/reject a request.
Renamed the “Credit Returino” setting to “Logo Returino” with a clearer
description of what the checkbox does.

1.2.1

Replaced the classic editor’s native “Publish” box for return requests
with a dedicated “Stare cerere de retur” panel — no more “Publish”/
“Published” terminology that meant nothing here. Shows the current
status plainly and three one-click actions (Mark as processing /
Approve / Reject), applied instantly over AJAX. Approving or
rejecting still triggers the existing order note and customer email
automatically, same as before.

1.2.0

Admin return-request list reworked: real columns (Order, Client,
Status, Items, Confirmation email, Request date) instead of the
generic title/date WordPress gives a CPT by default. Removed the
“Add New” button (requests only ever come from the customer form),
the “Mine” view and the “All dates” dropdown (neither meaningful
here), and added a Status filter dropdown.
New request titles no longer include the customer’s name (now meta +
its own column only) — keeps it out of revisions and global admin
search. Existing request titles are left as they are.
A return-form page is now created automatically if one doesn’t
already exist (searches for a page already using the shortcode
first, so nothing is duplicated). Configurable from Returino
Settings; shows a one-time notice pointing at the page so it can be
linked from the site’s navigation, as OUG 18/2026 requires the
process to be clearly visible, not just technically present.
Added optional (on by default) email notifications: to the store
admin on a new request, and to the customer when a request is
approved or rejected. These are in addition to the mandatory
durable-medium confirmation, which still cannot be disabled. Each
tracks its own sent/failed delivery status via wp_mail_failed, same
as the confirmation email.

1.1.2

Fixed a critical bug (WordPress core #24415): custom post statuses need
both show_in_admin_all_list and protected set to appear in the
admin list’s “All” view — only the first was set, so the list table’s
“All (N)” count and the actual rows shown disagreed, and return
requests could go unnoticed. Added protected => true (kept
public => false — requests are still never queryable from the
front end).
One-time migration moves any request still stuck on the native
“Published” status (residue from the bug fixed in 1.0.9) back to
Pending, and logs a note on its linked order. Runs on admin_init and
self-disables after running once; trashed requests are left untouched.

1.1.1

Fixed the order-lookup rate limiter to key off a validated IP address
instead of trusting REMOTE_ADDR blindly — sites behind a reverse
proxy/CDN (e.g. Cloudflare) could otherwise have every visitor share
one throttling bucket, turning the anti-enumeration protection into an
accidental site-wide lockout. Added a returino_rate_limit_ip filter
for sites that need to supply the real visitor IP (see FAQ). A
successful lookup now also clears that visitor’s failed-attempt count.
Renamed the wp_ajax_oug18_* AJAX action/nonce names to
wp_ajax_returino_* (code only, no stored data affected — the
oug18* post meta keys are unchanged).

1.1.0

Renamed the plugin to “Returino – Formular de retur for WooCommerce”
(previously “Returino for WooCommerce”) for better discoverability
when searching in wp-admin.
The “Powered by Returino” credit on the public form is now opt-in and
disabled by default (Returino Settings) — previously it showed
automatically. Existing installs will stop showing it until enabled.
Added per-IP throttling on order lookup (max 10 failed attempts / 15
minutes) against order-number enumeration.
Unified the order-lookup error message so it no longer reveals whether
the order number or the email was the wrong part.
Renamed the internal “oug18-” prefix (markup/CSS/JS) to “returino-“.

1.0.10

Added a server-side guard (wp_insert_post_data) so a return request can
never be saved with a status other than our own four, regardless of
which admin UI path is used (Quick Edit, bulk edit, REST API, etc.) —
the previous fix only covered the classic per-post editor.

1.0.9

Fixed a bug where opening/saving a return request in wp-admin silently
reset its status to “Published” (the classic edit screen didn’t
recognize our custom statuses), making it disappear from the order
screen and the customer’s My Account tab. The custom statuses are now
registered in that screen’s status dropdown.

1.0.8

Small performance improvements.
Added subtle Returino branding to the email footer and the form.

1.0.7

IBAN is now only required for payment methods that can’t be refunded
automatically (cash on delivery, bank transfer). Card/wallet payments
skip the IBAN field entirely, both in the form and in validation.

1.0.5

Track each confirmation email’s delivery status (sent/failed), captured
via wp_mail_failed, and show it on every return request in admin.
“Resend confirmation” button — resends the exact original content, not
a rebuilt one.
“Send test email” tool on the settings screen.
Confirmation content is now saved in the database independent of email
delivery, and shown to the logged-in customer under My Account
“Cererile mele de retur” — a durable-medium safety net that doesn’t
depend on the email actually arriving.
Dashboard/list notice and an admin-menu count bubble for failed
confirmation emails, so failures surface without relying on email.

1.0.4

Renamed to Returino for WooCommerce to avoid confusion with an
unrelated, unaffiliated existing company of the previous name.
Replaced generic “woo”/”wc” prefixes (namespace, constants, CPT slug,
statuses, shortcode tag) with a distinct “returino” prefix.

1.0.2

Removed the GitHub-based update checker in favor of native
wordpress.org updates.
Text domain aligned with the plugin slug.

1.0.1

Meta box on the WooCommerce order screen showing linked return requests.
Automatic order note whenever a request’s status changes.
Explicit HPOS compatibility declaration.

1.0.0

Initial release: custom post type + statuses, 2-step front-end form,
AJAX validation, confirmation email, admin meta box, Returino menu.