Reference · built on requestOperator by FibricOrders & fulfillment

Duplicate Order

Reads each new order against recent orders from the same customer, address, or cart and the payment state, then proposes a hold or a cancel.

Request accessPricing ↗

About

A customer refreshes the checkout, or a retry fires twice, and two orders land minutes apart. Duplicate Order reads each new order against recent ones from the same customer, shipping address, or cart identifier, compares the lines and the totals, and checks whether the payment is still an authorization or already captured.

It proposes a hold with a confirmation message to the customer, or a cancellation once the customer confirms, and picks the payment action that fits: cancel the authorization before capture, refund after it. A person approves. Both orders carry a note naming the other.

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

  • New Shopify orders with cartToken, checkoutToken, customer, shippingAddress, and billingAddress, compared with orders from the same customer inside the window you set
  • BigCommerce orders with customer_id, billing_address, and shipping_addresses, and WooCommerce orders with cart_hash
  • Payment state: Stripe PaymentIntents in requires_capture under capture_method manual, or Adyen payments authorised and not yet captured
  • Line-level agreement: the same items and quantities, the same total, minutes apart
  • Support contacts that mention a double charge or two confirmation emails
  • Fulfillment order status, so a duplicate is caught before it reaches IN_PROGRESS

Proposed actions

  • Target capability: propose a fulfillment hold on the suspected duplicate and a confirmation message to the customer
  • Target capability: propose orderCancel with reason CUSTOMER or STAFF_ERROR, restock true, and a staffNote naming the order that stays
  • Target capability: propose cancelling the uncaptured authorization in Stripe or Adyen instead of refunding a captured charge
  • Target capability: propose a refund through the store when the duplicate was already captured
  • Target capability: propose a help desk reply stating which order stays and which was cancelled

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

What you can build

  • Hold the second order and ask

    Two Shopify orders with the same cartToken minutes apart: propose fulfillmentOrderHold on the later one and a Gorgias message asking the customer which they meant.

    With Shopify, Gorgias

  • Release the card, not a refund

    When the duplicate BigCommerce order's Stripe PaymentIntent is still in requires_capture, propose cancelling it so the customer never sees a charge followed by a refund.

    With Stripe, BigCommerce

  • Cancel and restock with the reason on file

    Once the customer confirms the duplicate, propose orderCancel with restock true and a staffNote citing the kept order, and the Adyen cancel on the authorisation.

    With Shopify, Adyen

Requirements

  • A store connector that exposes order, customer, address, and cart or checkout identifiers: Shopify, BigCommerce, or WooCommerce
  • A payment connector that shows whether a charge is authorized or captured: Stripe or Adyen
  • Your match rule: which fields must agree, within how many minutes, and which order types are exempt, such as subscriptions or split shipments
  • A help desk connector for the confirmation message and the reply
Authentication
A store app token with order and fulfillment order write scopes, a restricted Stripe key or an Adyen API credential, and a help desk API key, each held per deployment.

Limits

  • Two orders that agree on every field can still be intended; the default proposal is hold-and-confirm, not cancel
  • A Stripe or Adyen authorization can be cancelled only before capture; after capture the only path is a refund
  • An order already IN_PROGRESS at the warehouse is flagged, not held; stopping it is a cancellation request to the warehouse
  • Guest checkouts match on address and cart identifiers only, because there is no customer_id to compare

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 Duplicate Order ↗

Questions and answers

What is the approver shown?
A hold-and-confirm or a cancel for one order. The proposal shows both orders side by side, the fields that agreed, the minutes between them, the payment state, and the message the customer would receive.
What note do the two orders keep?
The kept order and the cancelled one each carry a staffNote naming the other, the fields that matched, the payment action taken, the approver, and the time. The help desk ticket holds the customer's confirmation.
What does it never do alone?
Hold, cancel, void an authorization, refund, or message the customer. Those are proposals until a person approves them, and an approved step is applied a single time. If the customer says both orders are wanted, the hold release is proposed the same way.
Ask about Duplicate Order

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