confirm_order

Finalize a Dineout booking that's awaiting payment. For paid UPI reservations, book_table creates the booking 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 booking; 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: "224511744004217",
    paasId: "PAAS_TXN_12345",
  },
});

Parameters

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 booking 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 booking 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 booking 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; book_table with the new selection creates a fresh transaction.
• ❌ DO NOT fire on REFUND-INITIATED. This status means the money was debited but the payment system has already started refunding it — the booking 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 booking.

Idempotent: safe to retry on transient failure. It reconciles via paasId and never places an unpaid booking.

Next in this journey →

Continue with get_booking_status to confirm the reservation.