Auto-Approval
Part of Pro Version. Seven features come bundled with Pro — this is one of them.
What this does for you
Most withdrawal requests are routine: a customer changes their mind, the order is well inside the 14-day window, nothing about it is unusual. Approving those by hand is repetitive work that adds nothing — and every hour a request sits waiting is an hour closer to the reimbursement deadline.
Auto-Approval lets you write down the rules you already apply in your head — "if it's a normal domestic order under €200 and the seal question doesn't apply, just approve it" — and have the module apply them for you, around the clock, on a schedule. Your team only ever looks at the requests that actually need a human.
The one Pro feature that waits for you
Every other Pro feature switches on the moment you install Pro and starts working quietly in the background. Auto-Approval is deliberately different. Because it takes real actions on real orders, it ships switched off and does absolutely nothing until you:
- Turn it on in the settings, and
- Write at least one rule and activate it.
Until both are done, not a single request is touched. This is by design — you decide exactly what may be automated, and everything else keeps going to your team exactly as before.
How it works
On a schedule (every minute), the engine looks at requests that are still pending — the ones waiting for a decision — and checks each one against your rules:
Pending request → Does it match one of your rules?
├─ Yes → do what that rule says (approve / refund / send to staff)
└─ No → leave it for your team, untouched
Rules are checked top to bottom, first match wins — so you can put a specific rule ("orders over €500 always go to staff") above a general one ("everything else, approve"). Only clean, straightforward requests are ever acted on: if anything about an order looks unusual — it's on hold, flagged for fraud review, the required receipt hasn't gone out yet, or the request simply doesn't match any rule — the engine steps back and leaves it for a person.
What a rule can do
Each rule ends in exactly one action:
| Action | What happens |
|---|---|
| Approve | The request moves from pending to approved, and the normal approval email goes to the customer — exactly as if a member of staff had clicked Approve. No money moves, and the order itself is never cancelled or changed. |
| Approve and issue a credit memo | The request is approved and a Magento credit memo is raised for the withdrawn items — exactly the credit memo a staff member would create by hand. By default it's an offline credit memo: a refund record your finance team settles, so no money moves automatically. If your store is already set up for online refunds, the credit memo triggers the same payment-gateway refund you'd get by issuing it manually. Either way the engine only ever does what issuing a credit memo in Magento does — it never cancels the order. Orders paid by a method that can't be refunded this way are sent to your team instead, never guessed at. |
| Send to staff | The request is left pending and flagged for manual review. Use this to carve out the cases you never want automated (high-value orders, specific countries, particular reasons), placed above your general approve rule. You can have the engine email a staff recipient each time this happens. |
Building a rule
Open Sales → EU Withdrawal → Auto-Approval Rules and add a rule. A rule has three parts:
- When it applies — the conditions. Build them from the details of the order and request: the refund amount, the country, the customer group, the reason the customer gave, whether any seal or digital-waiver flag is involved, and more. Combine conditions with ALL (every condition must be true) or ANY (at least one), and you can nest one level for cases like "amount under €200 and (reason is 'changed my mind' or 'wrong size')".
- Where it applies — the websites. A rule can be limited to one or more of your websites, so a policy that's fine for your domestic store need not touch your cross-border one.
- What to do — one of the three actions above.
A threshold like "refund amount under 200" is compared in the currency of each order — 200 EUR on a euro order, 200 SEK on a krona order. You don't set a currency on the rule; there's nothing to keep in sync when you add a new store currency.
Rules are versioned and activated explicitly. Editing a live rule creates a new revision; you publish it when you're ready. Nothing you type takes effect until you activate it.
Try it safely first — Dry-Run
Before you let a rule act for real, turn on Dry-Run. In dry-run the engine does everything except the last step: it reviews pending requests and records what it would have done — which rule matched, what action it chose — without changing a single request or creating any credit memo.
Let it run for a day, open Auto-Approval History, and check that its decisions match yours. When you're happy, switch Dry-Run off and the same rules start acting for real.
A safe first run, step by step:
- Write one narrow rule — the most obvious "just approve it" case — and activate it.
- Turn on Enable Auto-Approval and Dry-Run together. Nothing is acted on yet; the engine only records what it would do.
- Leave it a day, then open Auto-Approval History and confirm the previewed decisions match what you'd have done by hand.
- Widen or adjust the rule until the previews look right.
- Only then switch Dry-Run off. The requests it already previewed are now eligible to be processed for real — so check that pending backlog first, and widen your rules gradually from there.
Safety controls
Auto-Approval is built to fail safe. Alongside Dry-Run, three limits keep it from ever running away:
| Control | What it protects against |
|---|---|
| Daily Auto-Action Cap | The most requests the engine will auto-process per day (default 50). Anything over the cap waits for your team, so a surprise spike can never be approved wholesale overnight. |
| Error Brake | If several automatic actions fail in a short window (default 10 failures in 15 minutes), the engine pauses itself for that store until the failures age out — or until you clear it with Reset Error Brake. A misconfiguration stops early instead of repeating. |
| Enable switch | A single per-store on/off. Turn it off and all automation stops immediately; pending requests simply go back to being handled by hand. |
Reviewing what it did — Auto-Approval History
Every decision the engine makes — real or dry-run — is recorded and browsable under Sales → EU Withdrawal → Auto-Approval History: which request, which rule matched, what action was taken, and whether it was a live action or a preview. Dry-run entries are clearly badged so you never confuse a preview with a real approval.
Because Auto-Approval builds on Audit, each automatic action also lands in the same tamper-evident audit log as your team's manual actions, attributed to the automation rather than a person. Months later you can show exactly which requests were handled automatically, under which rule, and when.
What it never does
- It never invents a way to move money. The most it does is raise a Magento credit memo, exactly as a staff member would — offline (a record) by default, or an online gateway refund only if your store is already set up for that. The payout itself stays with your normal finance and payment process.
- It never cancels orders or touches fulfilment.
- It never overrides your eligibility rules. Anything the module would exclude from withdrawal by law is still excluded; the engine only ever acts within what's already allowed.
- It never acts on anything unclear. Unusual, held, flagged, or unmatched requests are left for a person — always.
When you'd use this
- You process a steady stream of routine cancellations and most of them are obvious approvals.
- You want refunds started well inside the 14-day deadline without a person watching the queue.
- Your policy for "just approve it" is simple and consistent enough to write down.
When you can leave it off
- Your withdrawal volume is low and each request is worth a human glance.
- Your approvals depend on judgement that doesn't reduce to rules.
- You'd simply rather keep every decision manual — which is exactly what happens while Auto-Approval stays off.
Settings
Find these under Stores → Configuration → MageMe Extensions → EU Withdrawal → Auto-Approval.
| Setting | Default | What it does |
|---|---|---|
| Enable Auto-Approval | No | Master switch. While off, no request is ever touched. |
| Dry-Run (preview only) | No | Record what the engine would do without changing any request or creating credit memos. Use this to trial your rules. |
| Daily Auto-Action Cap | 50 | The most requests this store auto-processes per day; the rest wait for manual review. 0 = no limit. |
| Error Brake Threshold | 10 | If this many automatic actions fail within 15 minutes, auto-approval pauses for that store until the failures age out. |
| Reset Error Brake | — | Clears a pause now instead of waiting 15 minutes. Takes effect immediately — no Save Config needed. |
| Notify staff on Send-to-staff | No | Email a staff recipient whenever a rule routes a request to manual review. |
| Staff Recipient Email(s) | (blank) | Comma-separated addresses for the send-to-staff notification. Invalid addresses are dropped. |
| Email Template | (default) | The template used for the send-to-staff notification. |
All settings are per store view, so you can automate aggressively on one store and conservatively — or not at all — on another.
Need help?
Write to support@mageme.com if you'd like a hand translating your current approval habits into a first safe rule, or deciding sensible caps for your volume.