Reference · built on requestOperator by FibricOrders & fulfillment

Delivery Dispute

Reads delivered-not-received contacts against carrier proof of delivery, then proposes a trace, a reship, or a refund with evidence.

Request accessPricing ↗

About

A customer writes that the carrier marked the package delivered but nothing arrived. Delivery Dispute reads that contact from your help desk, pulls the carrier's delivery record for the tracking number on the order, and sets the two side by side: the scan time, the location the driver recorded, the name that signed, and the photo where the carrier took one. It also checks whether the same customer or address has claimed before.

It proposes one remedy with the evidence attached: a trace with the carrier, a reship of the missing lines, or a refund. A person approves. The ticket and the order both keep the proof and the decision.

This is a reference listing. It documents what Fibric would read from Delivery Dispute 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

  • Delivered-but-not-received tickets in Zendesk, Gorgias, or Kustomer, matched to the order by order number or email address
  • UPS delivery details from the Tracking API: deliveryDate, location, receivedBy, signature, deliveryPhoto, and the pod document
  • FedEx scan history from the Track API and the Signature Proof of Delivery document where the service produced one
  • USPS tracking events for the package from the Tracking API v3
  • The shipping address, fulfillment, carrier, and tracking number on the Shopify order
  • Stripe disputes on the same charge with reason product_not_received and their evidence due date
  • Earlier claims and refunds on the same customer or delivery address

Proposed actions

  • Target capability: propose a carrier trace or claim for the package, with the proof of delivery and the customer's statement attached
  • Target capability: propose a reship of the missing lines as a new fulfillment, or a refund through refundCreate, once a person has read the evidence
  • Target capability: propose a reply on the ticket that quotes the delivery scan, the location the carrier recorded, and the next step
  • Target capability: propose filling shipping_carrier, shipping_tracking_number, shipping_date, and shipping_documentation on a Stripe dispute from the same record
  • Target capability: propose pausing further remedies when the address or customer has an open or repeated claim

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

What you can build

  • Answer with the scan, not a guess

    When a Gorgias ticket says the package never arrived, propose a reply that quotes the UPS delivery time, the recorded location, and the receivedBy name, and offers a trace.

    With Gorgias, UPS

  • Reship after the trace comes back empty

    When the FedEx trace closes without the package found, propose a new Shopify fulfillment for the missing lines and an internal note on the Zendesk ticket.

    With FedEx, Shopify, Zendesk

  • Prepare the chargeback evidence once

    When the same order becomes a Stripe dispute with reason product_not_received, propose the evidence fields filled from the USPS tracking record already on file.

    With Stripe, USPS

Requirements

  • A help desk connector where delivered-not-received contacts arrive: Zendesk, Gorgias, or Kustomer
  • A carrier connector for the packages you ship, with tracking access on your account: UPS, FedEx, or USPS
  • A store connector that holds the order, its fulfillment, and its tracking number, such as Shopify
  • Your remedy policy: which claims get a trace first, which get a reship, and who approves refunds above a value you set
  • A Stripe account, if you want dispute evidence prepared from the same record
Authentication
Each connected system keeps its own credential: a help desk API key, a store app token, carrier API client credentials, and a restricted Stripe key, held per deployment.

Limits

  • Proof of delivery is what the carrier returns; many services record no photo or signature, and the proposal says when that is the case
  • A trace or claim runs on the carrier's clock; the operator files the request and reports what the carrier answers
  • It cannot tell whether a package was taken after delivery; it matches the scan against the address and leaves the judgment to a person
  • Reships depend on stock at the fulfilling location; when nothing is available the proposal is a refund or a backorder

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 Delivery Dispute ↗

Questions and answers

What does the approver decide?
One remedy per contact: a carrier trace, a reship, a refund, or a reply asking for more detail. The proposal shows the ticket, the order, the delivery scan with its location and any signature or photo the carrier returned, and the customer's claim history.
What stays on the ticket and the order?
The ticket gets an internal note with the proof of delivery, the remedy chosen, who approved it, and when. The order carries the trace number, the new fulfillment, or the refund. Each entry says how to undo it.
What will it not do without a person?
File a claim, reship, refund, reply to the customer, or submit dispute evidence. It reads and proposes. If the tracking number on the order does not match the carrier's record, it stops and asks a person.
Ask about Delivery Dispute

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