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.
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.
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.
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.
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.
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.
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