Reference · built on requestOperator by FibricCustomer support

Concession Review

Reads a refund or credit request beside the order, its payment, and prior concessions. Proposes approve, counter, or decline.

About

A concession is money you give back: a refund, a partial credit, a replacement, or store credit. Requests arrive in a support ticket and are usually decided from memory. Concession Review reads the ticket beside the order it concerns, the payment behind it, and every concession that customer has already received, then checks the request against the limits you set.

It proposes one of three outcomes: approve as asked, counter with a smaller amount or a different form, or decline with a drafted reply. A person approves the outcome before anything is issued. The record shows the order value, the prior concessions counted, the limit applied, and who approved.

This is a reference listing. It documents what Fibric would read from Concession Review 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 and credit requests in support tickets, read from the ticket and its messages in Kustomer, Zendesk, or Gorgias
  • The order the request concerns: line items, net payment, and amount already refunded, read from Shopify, Magento, or BigCommerce
  • Charges, prior refunds, and open disputes on the payment, read from Stripe, Adyen, or PayPal
  • Prior concessions on the same customer across orders, so a second request is judged with the first in view
  • Return status when a return exists in Loop Returns, so a refund is not proposed twice for the same items
  • Your concession policy: caps by order value, by customer, and by period, plus who may approve above each cap

Proposed actions

  • Target capability: propose approving the refund or credit as requested, with the amount, the form, and the policy line it fits
  • Target capability: propose a counter: a partial refund, store credit in place of cash, or a replacement, with the reason
  • Target capability: propose a decline with a drafted reply to the customer and an internal note on the ticket
  • Target capability: propose escalation to a named approver when the request exceeds the cap you set
  • Target capability: propose the refund itself through the store or the payment platform once a person has approved it, with a note on the order

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

What you can build

  • Approve small refunds in one click

    A request under your cap arrives in Gorgias. The operator reads the Shopify order and the Stripe charge, confirms no prior concession, and proposes approval. A lead approves; the refund is issued once and noted on the ticket.

    With Gorgias, Shopify, Stripe

  • Counter a second request from the same customer

    A customer already credited on a prior order asks again. The operator surfaces both orders from Magento and the earlier credit, and proposes store credit instead of cash, with the reply drafted in Zendesk.

    With Zendesk, Magento

  • Hold a refund that overlaps a return

    The request names items already inside a Loop Returns return. The operator proposes waiting for the return to close rather than refunding twice, and leaves a note on the Kustomer conversation.

    With Loop Returns, Kustomer

  • Route the large ones to the right approver

    A request above the cap goes to the named approver with the order value, the Adyen payment, and the customer's history attached. Nothing is issued until that person approves.

    With Shopify, Adyen

Requirements

  • A support connector for the request: Kustomer, Zendesk, or Gorgias
  • A commerce connector for order value and refund history: Shopify, Magento, or BigCommerce
  • A payments connector for charges and prior refunds: Stripe, Adyen, or PayPal
  • A written concession policy: caps, who may approve above them, and which forms of credit you offer
Authentication
Runs on the credentials of the connectors you attach. It holds no key of its own and issues nothing without a person's approval.

Limits

  • It judges a request against the records it can read. A concession issued outside those systems is invisible to it
  • Shopify returns the last 60 days of orders by default; older orders need the read_all_orders scope
  • Stripe refuses a refund on a fully refunded charge and any amount above what remains, so a proposal is capped to what the processor allows
  • It does not decide fraud. A charge with an open dispute is flagged for a person, not refunded

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 Concession Review ↗

Questions and answers

What does a person approve?
One outcome per request: approve, counter, or decline. The proposal shows the amount, the form (cash, store credit, or replacement), the policy line it fits, and the reply draft. Approval is a single action. Until then nothing is refunded, credited, or sent.
What record is left after a decision?
A receipt on the ticket and the order: the request, the order value, the prior concessions counted, the limit applied, the decision, who approved it, and when. If a refund was issued, the receipt carries the refund id from the store or the payment platform.
Will it ever issue a refund on its own?
No. It proposes; a person approves. An approved refund is sent once. Shopify requires a unique request key on refundCreate so a retried request cannot refund twice, and Stripe rejects any amount beyond what remains on the charge.
Ask about Concession Review

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.