Skip to content

OrderResume

The page a buyer lands on when they come back to an order they did not pay for. It offers at most paying and changing; anything else is another thing to read first.

import { OrderResume } from "@evolve-storefront/feature-order/order-resume";

Renders inside OrderProvider.

Design notes

Change my order is orderRevise — one action for both halves, since doing one without the other duplicates the order or strands the buyer. Omit onRevise where the engine cannot revise. Revising survives an approval hold and a Pending payment.

Preview

Both ActionsOpen in Storybook ↗

Usage

Both choices: pay it now, or put it back in a basket and change it. The root carries data-payment-state, so a brand tones a failed payment apart from one never started: [data-component="order-resume"][data-payment-state="FAILED"].

const { data: order } = useOrder(orderNumber);
const pay = usePayOrder();
const revise = useReviseOrder();
// Two separate mutations; the view offers whichever the order allows.
<OrderResume
order={order}
methods={methods}
onPay={(paymentMethod) => pay.mutate({ order, paymentMethod })}
onRevise={() => revise.mutate({ order })}
/>;

Props

PropTypeDescription
orderOrder

The unpaid order the buyer came back to.

methodsreadonly OrderPaymentMethod[]

The methods offered for this order. An empty list is a real answer.

onPay(method: OrderPaymentMethodInput) => void
children?ReactNode

What the buyer is deciding about, between the order's details and its amounts — typically <OrderLineItems>, since neither paying nor changing can be judged against a total alone.

vatDisplay?VatDisplay
renderPaymentMethodIcon?((method: OrderPaymentMethod) => ReactNode)

Each payment method's logo, passed on to PaymentMethods' renderIcon.

isPaying?boolean
payError?ReactNode
payable?boolean

Whether the order may be paid. false for one held by an approval flow.

approval?OrderApprovalHold | null
approvers?readonly string[]
onRevise?(() => void)

Reopen the order for editing — wire it to useReviseOrder and route to the cart it hands back.

More

Omit it where the engine does not compose orderRevise, and the action is simply not rendered. That is the intended way to turn it off: the mutation is optional in the contract because not every engine can build a cart from an order, so a surface that always offered it would 400 on those.

It is also hidden on an order the mutation would refuse — a paid one. Revising that is a refund conversation, not an edit.

isRevising?boolean
reviseError?ReactNode

Shown when reopening failed — most often because the order has been paid.

renderActions?((actions: OrderResumeActions) => ReactNode)

Arrange paying and revising, such as two branches with an "or" between them. Defaults to the two stacked, pay first.

headingLevel?HeadingLevel

Level for the order number, which is this page's title. Defaults to 1; the pay section derives from it.

Any other props go to the root element, like on a plain HTML element.

Examples

Actions As A ChoicePaying and changing as a choice. renderActions gets both sections and arranges them; here as two branches with an "or" between them.
<OrderResume
order={order}
methods={methods}
onPay={onPay}
onRevise={onRevise}
renderActions={({ pay, revise }) => (
<div className="resume-choice">
{pay}
{revise ? (
<>
<p aria-hidden="true">{t("or")}</p>
{revise}
</>
) : null}
</div>
)}
/>;
Open in Storybook ↗