;
};
Fini (usefini.com) handles refunds and returns end to end inside a deterministic Intent Rule: it identifies the customer, looks up the order or charge in your system through an Action, checks eligibility against your policy, submits the refund or creates the return through a second Action, and replies with the real amount, reference and timeline your API returned. Anything outside policy, above the amount you allow the agent to approve, or marked as sensitive goes to your team as an internal note or an escalation with the conversation history, and the AI Steps trace in the Inbox shows every step the rule ran.
The agent never decides on its own whether a refund is allowed. Your API and the Checks in your rule make that decision, the agent collects what's needed and explains the outcome. Policy questions that aren't requests (*"what's your return window?"*) are answered from your Knowledge articles without running the rule at all.
```mermaid theme={null}
sequenceDiagram
autonumber
actor C as Customer
participant F as Fini
participant API as Your system via Actions
actor T as Your team
C->>F: Asks for a refund on an order
Note over F: Intent Check, customer Check, Read order_id and reason
F->>API: Check Refund Eligibility
API-->>F: eligible, refund_amount, blocker_reason
alt Eligible and within your auto-approve limit
F->>API: Submit Refund with an idempotency key
API-->>F: refund_id, refund_eta_days
F->>C: Confirms the amount, reference and timeline
else Eligible, above the limit
F->>C: The request is with the team, who will follow up
F->>T: Escalated, with the conversation history
else Not eligible
F->>C: Explains blocker_reason and links the refund policy
end
```
## What Fini handles and what it hands to your team
| Fini handles | Your team handles |
| - | - |
| Refund and return policy questions, answered from your Knowledge articles. | Exceptions to policy and goodwill refunds outside your rules. |
| Identifying the customer and the order or charge (User Attributes, plus a Read for the order id). | Refunds above the auto-approve limit you set in the rule. |
| Checking eligibility by calling your eligibility logic through an Action. | Refunds you've routed to review with Reply Rules (for example, Enterprise customers). |
| Submitting the refund, or creating a return and returning the label or instructions, through an Action. | Cases where the customer disputes a charge they don't recognize (see [Disputes and chargebacks](/en/use-cases/disputes)). |
| Confirming the refund amount, reference and expected timeline, using the values your API returned. | Anything your Planning Prompt's Escalation Topics send to a human, such as legal threats. |
| Explaining why a request isn't eligible, using the reason your API returned. | Conversations where an Action failed and the agent escalated. |
## How it works in Fini
A refund flow is the same four-piece shape as the [Cancellation flow walkthrough](/en/walkthroughs/cancellation-flow): a User Attribute for context, Actions for the work, an Intent Rule for orchestration, and Reply Rules for overrides. Returns add a branch, which is the multi-intent pattern from the [Order status and changes walkthrough](/en/walkthroughs/order-status-and-changes).
| Building block | What it does for refunds and returns | Where |
| - | - | - |
| **Tags** | A Rulebook-enabled tag group with tags such as `refund_request` and `return_request`. The example uses a custom `Topic` group: turn on **Tag Group available in Rulebooks**, set **Tag Selection** to "Exactly one tag is selected", and assign the group to your agent. (Default groups such as **Type of Issue** have their tag list and Rulebook availability locked.) Use each tag's "when not to apply" section to separate a refund *request* from a refund *policy question*. | [Tags](/en/configuration/tags) |
| **User Attributes** | A `Customer Identity` attribute that exposes `customer_id`, `plan` and any flags you route on (for example `is_vip`). Turn on **Use in Rulebooks** for fields Checks and Reply Rules read; keep internal ids off **Visible to AI**. | [Attributes](/en/api-reference/attributes) |
| **Actions** | A read-only `Check Refund Eligibility` (or `Lookup Order`) Action, then a `Submit Refund` or `Create Return` Action. Each declares typed inputs and outputs, so Checks downstream can compare amounts with numeric operators. | [Actions](/en/api-reference/actions) |
| **Intent Rule** | The behavior tree: an intent Check, a customer Check, a Read for the order id and reason, the eligibility Tool, then a Fallback that either submits the refund or explains why not. | [Intent Rules](/en/automations/rulebook) |
| **Reply Rules** | Optional overrides. The documented pattern is **Internal Comment** with `Type of Issue Equals refunds`, so the agent drafts the reply for your team instead of sending it. Scope it with a User Attribute (for example `plan Equals enterprise`) if you only want review for some customers. | [Reply Rules](/en/automations/reply-behavior) |
| **Knowledge** | Articles for the refund and return policy, timelines, and the fall-through paths (order not found, outside the return window). These answer policy questions and back up every path where the rule stops. | [Knowledge](/en/knowledge/overview) |
| **Guardrails** | Reply checks before delivery, for example a **Custom rule** that fails replies promising a refund the rule didn't confirm, or a **URL allowlist** limited to your own and your carrier's domains for return labels. | [Guardrails](/en/configuration/guardrails) |
### Example behavior tree
The tree below is an example to adapt, not a template that ships with Fini. Rename tags, fields and Actions to match your system, and set the auto-approve limit to your own policy (`100` is a placeholder).
```text theme={null}
Steps (root)
├── Check: Topic Equals refund_request
├── Check: customer_id Is Not Null
├── Read: extract `order_id` (String) and `reason` (String)
├── Tool: Check Refund Eligibility (read-only)
│ in: customer_id, order_id
│ out: eligible, refund_amount, blocker_reason
└── Fallback
├── Steps (auto-approve path)
│ ├── Check: eligible Equals True
│ ├── Check: refund_amount Less Than or Equal To 100
│ ├── Tool: Submit Refund
│ │ in: order_id, refund_amount, reason
│ │ out: refund_id, refund_eta_days
│ └── Reply: confirm refund_amount, refund_id and refund_eta_days
├── Steps (eligible, above the auto-approve limit)
│ ├── Check: eligible Equals True
│ └── Reply: tell the customer the request is with the team,
│ who will follow up directly
└── Reply: explain blocker_reason and link the refund policy article
```
How it runs:
1. The intent Check is a deterministic backstop on the planner's routing. If the conversation isn't tagged `refund_request`, the Steps short-circuits, the rule does nothing on this message, and the agent falls through to its default reply from Knowledge.
2. The customer Check stops the rule cleanly if the customer couldn't be identified. To ask for the account email instead, wrap the rule in a Fallback whose second child is a Reply, the graceful-recovery pattern in [Intent Rules](/en/automations/rulebook#a-worked-example-cancellation-flow).
3. The eligibility Tool runs before anything with side effects. Its outputs sit outside the inner Fallback, so every branch below can use `blocker_reason` and `refund_amount`.
4. The Fallback tries the auto-approve path first. If the refund is eligible but above your limit, the second branch escalates through its handoff **Reply**, which tells the customer a teammate will follow up. [Conversation Status](/en/configuration/tags#mandatory-groups-conversation-status) records the conversation as **Escalated to Human Agent**. If the refund isn't eligible, the last Reply explains why using the reason your API returned.
For returns, make the root a Fallback with one Steps branch per intent: the refund branch above, and a return branch with its own intent Check (`Topic Equals return_request`) that calls a `Create Return` Action and replies with the return label or drop-off instructions it returns. One rule with a Fallback root handling several related intents is the shape the [Order status and changes walkthrough](/en/walkthroughs/order-status-and-changes) builds step by step.
**Make the submit Action idempotent.** A customer can send the same message twice before the first reply arrives, and each message re-runs the rule from the root. Pass a deterministic idempotency key in the `Submit Refund` body (for example `${order_id}-refund`) so a duplicate Tool call doesn't refund twice.
## What you need
| What | Why | Where |
| - | - | - |
| **A way to identify the customer** | The rule needs `customer_id` before it calls anything. Use a signed JWT in the widget, UI metadata, or the connected helpdesk's user identifier as the attribute **Source**. | [Widget](/en/deploy/widget), [Attributes](/en/api-reference/attributes) |
| **An eligibility endpoint** | Read-only. Returns whether the order is refundable or returnable, the amount, and a human-readable reason when it isn't. Keep the policy logic in your system so it has one source of truth. | Your order, billing or payments system |
| **A refund or return endpoint** | The write call. Returns a reference id and timeline (and a label URL for returns). Should accept an idempotency key. | Your order, billing or payments system |
| **API credentials scoped to these endpoints** | Credentials go in the Data Step **Headers** JSON (for example an `Authorization` header). Scope the key to refund and lookup operations only. Endpoints you build should follow the [API contract](/en/api-reference/api-contract). | [Actions](/en/api-reference/actions) |
| **A Rulebook-enabled tag group** | The intent Check and any Reply Rules read it. | [Tags](/en/configuration/tags) |
| **Policy articles** | Answer policy questions and back up the paths where the rule stops. | [Knowledge](/en/knowledge/overview) |
| **A sandbox for testing** | Test Suite runs use recorded or mock Action responses and never call your systems. For a live end-to-end check, point the Actions at a sandbox environment or run a controlled pilot. | [Test Suite](/en/testing/test-suite) |
## Guardrails and escalation
Decide up front which refunds the agent may complete on its own, and encode each boundary in the layer built for it.
| Situation | Recommended behavior | How to configure it |
| - | - | - |
| Refund above your auto-approve limit | Don't submit; tell the customer the team will follow up. | A numeric Check on the eligibility output inside the rule, as in the example tree. |
| High-value or Enterprise customers | Run the rule, but post the reply as an internal note for review. | **Internal Comment** card in [Reply Rules](/en/automations/reply-behavior) with `plan Equals enterprise` (or `is_vip Equals True`) AND your refund tag. Note that the Tools in the rule still run. |
| Customer doesn't recognize the charge | Route to your dispute or fraud process, not the refund rule. | Add the pattern to the Planning Prompt's *Escalation Topics*, or a separate dispute rule. See [Prompts](/en/configuration/prompts). |
| Refund policy is changing | Escalate instead of quoting the old policy. | A time-bound instruction in **Incident Info** in Main Guidelines. |
| A human is already on the ticket | The agent stays silent. | **No Reply** with `Human Agent Assigned Equals True`. |
| The reply promises something the rule didn't confirm | Rewrite, or escalate if the rewrite still fails. | A **Custom rule** in [Guardrails](/en/configuration/guardrails), plus a "no fabricated commitments" rule in Main Guidelines **Guardrails**. |
**Reply Rules gate the reply, not the Tools.** When an Internal Comment rule matches, the rule still runs and `Submit Refund` still fires; only the customer-facing confirmation is held. If a human must approve before money moves, stop the tree before the submit Tool (as the above-limit branch does) and let your team complete the refund in your own system.
## What to measure
Open [Analytics](/en/analytics) after a week of production traffic and scope it to this use case with the **Tags** filter (your refund and return tags) or the **Intent rule** filter.
| Metric | Where | What it tells you |
| - | - | - |
| AI resolution rate for the intent | **Conversation Status** doughnut, share **Resolved by AI**, with the Tags filter applied | How many refund conversations the agent fully resolved. Deflection also counts conversations still waiting on the customer, so read resolution first. |
| AI Resolve Rate and Escalated Rate per rule | **Intent rule breakdown** row for your refund rule | Whether the rule is leaking conversations to humans. |
| Human escalation rate | KPI card, with the filter applied | The share your team picks up. Expect a floor from the above-limit branch. |
| Escalation reasons | **Escalation reason** filter and doughnut | **API or System Failure** points at an Action; **Escalation Constraint** is your own policy at work; the **Customer requested human** reasons show where customers lost confidence. |
| CSAT | **Average CSAT** card and the **CSAT** filter | Whether customers are satisfied with the outcome, including denials. |
When a number moves, open the conversations behind it in [Inbox](/en/testing/inbox) and read the AI Steps trace. The first red dot shows where the rule stopped.
## Related
Step-by-step build of a multi-intent order rule with eligibility checks, a cancel Action and blocked-path replies.
The canonical intent, identify, act, confirm walkthrough that refund flows share.
Node types, Fallback patterns and chaining Tools, including a refund chain.
Internal Comment, No Reply and Direct Reply, and how priority works.
Typed inputs and outputs, Data Steps and testing with Play.
When the customer contests a charge instead of requesting a refund.
For a comparison of refund automation tools, see the guide on [usefini.com](https://www.usefini.com/guides/best-ai-tools-refund-automation).
## Related topics
- [Fini for billing and invoices](/en/use-cases/billing-and-invoices.md)
- [End-to-end: order status and changes](/en/walkthroughs/order-status-and-changes.md)
- [Fini FAQ](/en/faq.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.