confirm_order

Finalize a Food order that's awaiting payment. For UPI flows, place_food_order creates the order in PENDING_PAYMENT and it only transitions to PLACED (or failed) here. It fires automatically when the payment settles — SUCCESS, FAILED, or the polling-cap TIMEOUT — SUCCESS places the order; FAILED and the polling-cap TIMEOUT finalize it the other way (out of PENDING_PAYMENT, triggering any refund) so it never lingers. A REFUND-INITIATED payment is never placed — its refund is already in flight. In practice this runs server-side inside check_payment_status (bound on the terminal poll), not from the widget or the agent. It is idempotent and safe to retry.

Example

const result = await client.callTool({
  name: "confirm_order",
  arguments: {
    orderId: "241234567890",
    addressId: "addr_01HXYZ",
    lat: 12.9352,
    lng: 77.6245,
  },
});

Parameters

Food's confirm contract uses orderId + addressId + lat + lng (query-param + headers). paasId is not used by Food's confirm_order — that field is for Instamart and Dineout only.

Session credentials (user identity, access token) are supplied automatically by the authenticated MCP session - you do not pass them in the tool call. See Authenticate.

Response

All Swiggy MCP tools return:

{
  "success": true,
  "data": { /* tool-specific payload */ },
  "message": "optional human-readable message"
}

On failure:

{
  "success": false,
  "error": { "message": "description of what went wrong" }
}

See Error codes for the full catalogue.

Details

Agent guidance

How Swiggy agents and orchestration logic use this tool. Surface these expectations in your prompts or tool-selection policies.

In normal flows you (the agent) never call this — check_payment_status binds confirm_order server-side on the terminal poll (SUCCESS, FAILED, and the cap), so the guidance below is about the rare manual case and, mostly, what NOT to do.

WHEN TO CALL:

• ✅ On the first SUCCESS / PAID poll → finalizes the order to PLACED. Already done for you server-side; only fire it yourself if check_payment_status reports the payment was PAID but auto-confirm couldn't run (missing args).
• ⏱️ At your polling cap while still PENDING → call confirm_order once to finalize (a single call — never a poll loop). The backend marks the order failed (the payment is still non-terminal), and a late success is reconciled server-side. On a widget host the picker owns polling and confirmation end-to-end (via check_payment_status(finalize: true)) — you never call this at all. Only a headless client running its own capped poll fires it, and only once when the cap is hit.
• ❌ DO NOT fire it yourself on FAILED. This isn't a case where confirm never runs — check_payment_status fires it server-side best-effort (when the poll carried the confirm args) to finalize the order to failed, out of PENDING_PAYMENT and triggering any refund. Your job on FAILED is the retry, not the finalize: call get_payment_options to re-show the picker; place_food_order with the new selection creates a fresh transaction on the same cart.
• ❌ DO NOT fire on REFUND-INITIATED. This status means the money was debited but the payment system has already started refunding it — the order won't be placed, and the refund is underway on the payment side. Unlike FAILED, there's nothing to finalize and the system does not auto-confirm here. Just tell the user a refund is on its way, and don't retry this order.

ECHO THE FOOD ARGS: orderId, addressId, lat, and lng all come from the place_food_order response. Pass them through unchanged.

Idempotent: safe to retry on transient failure.

Next in this journey →

Continue with track_food_order to follow delivery.