Reference · built on requestOperator by FibricFinance & billing

Refund Policy

Each refund request checked against the return window, prior refunds, and shipment status, with approve, partial, or decline proposed.

Request accessPricing ↗

About

A refund request lands in the help desk. The facts that decide it live elsewhere: the order date and items in the store, the delivery scan at the carrier, the refunds already issued on that order, and the policy you wrote. This operator reads all of them for each request and applies the policy as written.

It proposes one of three outcomes with the reason attached: a full refund, a partial refund with the amount computed by the store, or a decline citing the clause. It also drafts the reply. An agent approves the outcome and the reply together. The refund runs once through the store's own refund path, and the receipt records the clause that decided it.

This is a reference listing. It documents what Fibric would read from Refund Policy and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Refund requests in Gorgias, Zendesk, or Kustomer conversations, tagged or detected by intent, with the order number quoted
  • The order in Shopify: processed_at, financial_status, fulfillment_status, line items, and the refunds array with earlier refund_line_items
  • Orders and credit memos in Magento or BigCommerce, with the customer's order history
  • Delivery and return-to-sender events for the shipment from AfterShip, UPS, or ShipStation
  • Refunds already issued on the payment in Stripe or PayPal, and any open dispute on the same charge
  • Your policy as data: window in days from delivery, final-sale categories, restocking rule, and exceptions

Proposed actions

  • Target capability: propose a full refund, using Shopify's refund calculate result so the amount matches what the store would charge back
  • Target capability: propose a partial refund with the line items, quantities, and restock_type stated, and shipping included or not
  • Target capability: propose a decline with the clause quoted, the delivery date, and the days elapsed
  • Target capability: propose a reply to the customer in the help desk, saying the outcome and why, for the agent to send
  • Target capability: propose a return before refund where the policy requires the goods back, with the tracking to watch

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Approve inside the window, decline outside it

    A Gorgias ticket quoting a Shopify order is checked against the delivery scan from AfterShip. Inside the window, a full refund is proposed; outside it, a decline with the clause and a drafted reply.

    With Gorgias, Shopify, AfterShip

  • Second refund on the same order

    When Stripe already shows a refund on the charge, the proposal is limited to what remains and the earlier refund is displayed to the Zendesk agent.

    With Stripe, Zendesk

  • Goods back first

    For categories your policy marks return-required, it proposes a return instruction and watches the UPS return scan before proposing the Magento credit memo.

    With Magento, UPS

  • Partial for a damaged item

    A Kustomer conversation reporting one damaged item of three yields a partial refund for that line, restock_type no_restock, with shipping left unrefunded.

    With Kustomer, Shopify

Requirements

  • A commerce connector that can calculate and create refunds: Shopify, Magento, BigCommerce, or WooCommerce
  • A help desk connector where requests arrive and replies are sent: Gorgias, Zendesk, Kustomer, or Freshdesk
  • A tracking source for delivery and return scans: AfterShip, UPS, FedEx, or ShipStation
  • Your refund policy written as rules: window, basis date, categories excluded, and who can override
  • An order number in the request, or an email address that resolves to one order
Authentication
It holds no store or processor keys itself. Orders, tracking, refunds, and conversations pass through the connectors you attach, each with the scopes you set.

Limits

  • A refund cannot exceed the amount captured on the original payment. The store enforces this; the operator shows it.
  • The return window is counted from the carrier's delivery scan. With no scan, it falls back to the ship date and says so.
  • It applies the policy you wrote. A request the rules do not cover is sent to a person without a proposed outcome.
  • Shopify trial and development stores accept five refund creations per minute. Batches are paced to that.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Refund Policy ↗

Questions and answers

What does the agent see and approve?
The outcome and the reply together. The agent sees the order, the delivery date, prior refunds, the clause applied, and the exact amount. They can change the amount, switch the outcome, or edit the reply before approving.
What is written back to the order?
A receipt naming the request, the clause that decided it, the amount, the refund id the store returned, who approved, and when. Declines keep the reply that was sent.
Does it refund anyone on its own?
No. No refund is created and no reply is sent until an agent approves. An approved refund is created once, through the store, and never repeated for the same request.
Ask about Refund Policy

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy