--- title: "Reject a pending order safely" description: "Reject a pending order with a clear reason, verify every affected order, and treat customer calling as a separate phone-app handoff." canonical: https://docs.ordering.co/docs/products/business-app/orders/reject-order/ --- # Reject a pending order safely Reject an order only when it is still **Pending** and cannot be fulfilled. A successful rejection records your written reason, moves the order toward **Rejected by business**, and can trigger customer-facing updates. Confirm the result for every affected order; a closed screen or notification does not prove that the rejection or every follow-up completed. ## Before you start - Sign in to the intended project and business scope, then open **Orders**. - Refresh the queue and match the order number, business, customer, items, and current **Pending** status to the decision you intend to make. - If you are rejecting a grouped set, refresh and review every displayed order. Confirm that each member is intended and still **Pending**. The app checks the first order before showing **Reject all**, but submits the same reason for every displayed group member without filtering their individual statuses. - Prepare a clear, customer-safe reason. Business App requires a written comment; it does not use the preset reason picker shown in some other apps. - Treat rejection as a remote order change. Do not repeat it while the result is unknown. ## Reject the order 1. From a pending order, select **Reject**. For a displayed group, select **Reject all** only after confirming that every member is intended and still **Pending**; the visible group action is gated by its first order only. 2. Review the **Reject Order** screen. If a customer phone button appears, use it only when your operating procedure requires contact. Selecting it hands the number to the device phone app; it does not confirm that a call started or connected. 3. Enter the rejection reason in **Please type your comments in here**. The **Reject** button remains unavailable while the comment is empty. If the app reports a length validation error, shorten the reason to 255 characters or fewer. 4. Before selecting **Reject**, preview the effect: a single order or every displayed group member is submitted with the same reason. Each accepted order can leave **Pending** and trigger configured notifications, email, realtime updates, webhooks, or logistics follow-up. A mixed or stale group can produce different results for its members. 5. Select **Reject** once. Wait for the current update to finish before navigating away or trying again. ## Verify the result Return to **Orders**, refresh, and verify each affected order separately. - A verified rejection shows the intended order as **Rejected by business** in the **Cancelled** group or in its refreshed order details. - If a grouped set was submitted, confirm every displayed order number and current status. The rejection screen can close after receiving one result slot per order even when a non-pending member was submitted or one or more individual updates failed. - A customer notification, email, realtime event, or phone-app screen is not proof of the saved order status. Those follow-up channels can finish, fail, or arrive separately. - If the app was offline or reconnecting, a local change can be stale or unsynchronized. Reconnect and refresh before treating the order as rejected. ## Recover safely | What you observe | What it means | Safe next action | | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Reject** is unavailable | The comment is empty, or the order update is already loading. | Enter a clear reason or wait for the current attempt. Do not tap repeatedly. | | **Reject** or **Reject all** is missing | The order is not currently pending, the view is stale, or offline actions are unavailable. | Refresh and verify the exact status, scope, and connection. Do not force a different status. | | A validation, permission, locked-order, status-change, or network error appears | The service did not accept the current request as submitted. | Keep the visible message, refresh the order, correct only the stated problem, and retry once if the status is still **Pending**. | | The rejection screen closes but an order remains **Pending** | A grouped request may have failed partially, or the list may be stale. | Refresh every submitted order. Retry only the intended still-pending order once; escalate persistent mismatches to the project administrator or Ordering support. | | A submitted group member shows a different non-pending status | **Reject all** submitted the displayed group IDs without rechecking each status, or another actor changed the order first. | Stop. Reopen that order and follow its current workflow instead of repeating rejection. Verify the other group members separately. | | The device phone app does not open, or no call result is visible | The optional device handoff was unavailable or its result is outside Business App. | Contact the customer through an approved alternative if required. Do not treat the order as rejected until its status is verified separately. | | A notification or realtime update is missing | A follow-up channel can fail or lag after the order update. | Verify the saved order status by refreshing. Escalate the missing channel separately; do not repeat the rejection solely to resend it. | ## Availability and platform differences - **Reject** is available for a pending order in order details. A displayed group's **Reject all** visibility checks only its first order for **Pending**, then submits every displayed group member without filtering each status. Refresh and verify every member before submission and again afterward. - The Business App flow uses a free-text comment as the rejection reason. It does not expose the preset rejection-reason list used by the driver flow. - When the app cannot perform or retain offline actions, status controls are unavailable. When it retains an offline change, there is no supported pending-action indicator that proves later synchronization. - The customer phone button appears only when the loaded order includes a customer mobile number. It opens the platform phone handler and is separate from the remote rejection. - Visible behavior describes the current documented source contract. Deployed app, API, phone provider, notification, email, webhook, and realtime parity are not established by this article. ## Related articles - [Review an order before taking action](https://docs.ordering.co/docs/products/business-app/orders/view-order/) - [Understand order queues and statuses](https://docs.ordering.co/docs/products/business-app/orders/groups-statuses/) - [Loading, connection, empty, and error states](https://docs.ordering.co/docs/products/business-app/app-behavior/loading-connection-errors/)