用途：在 Swiggy MCP 上完成共享支付阶段，支持 Food、Instamart、Dineout。基本流程：购物车就绪后调用 get_payment_options，再用对应下单工具（Food place_food_order、Instamart checkout、Dineout book_table，付费 deal 需先 create_cart），随后 check_payment_status（约 19 秒长轮询），最后 confirm_order 到 PLACED 并跟踪。三个支付工具在各服务器同名同形。
主要能力与规则：get_payment_options 是支付方式唯一来源，只能提供 data.allMethods 或 platforms.mobile/desktop.methods、cod 返回的方式，不得虚构。Food 需传与 get_food_cart 相同的 addressId。不要询问设备类型或 UPI ID/VPA。用户选择需原样传递：UPI 应用用 paymentMethod: "UPI" 加 intentApp: method.id；桌面扫码用 paymentMethod: "UPI" 加 generateUPIQR: true 且不传 intentApp；现金为 paymentMethod: "Cash"，仅在 cod.available 时；Swiggy Money 为 paymentMethod: "SwiggyPay"，仅当返回该组时。paymentMethod 始终是组名，不是应用 id。
PENDING_PAYMENT 不是订单：在 confirm_order 成功或 check_payment_status 报告 confirmed: true 前，不得说已下单/已确认/成功。Widget 宿主（Claude Desktop、ChatGPT、Cursor 等）不要轮询，确认 widget 会自行轮询并自动终结；仅当用户询问支付是否到账时调用一次。无 widget 的无头客户端需自行循环：先给出 data.bridgeUrl（桌面 QR、移动端应用按钮），再按 pollingIntervalInMs 轮询，上限 maxTimeToPollForInMs，不得紧循环。标识符需回显，不要重建。
参数与分支：check_payment_status 与 confirm_order 的参数因服务器而异——Food 需 paasId、orderId、addressId、cartId、lat、lng，confirm_order 不要 paasId；Instamart 与 Dineout 为 paasId、orderId（confirm_order 另可带 transactionId）。paasId 是下单响应中的支付交易号，没有真实值就不要调用。状态分支：成功且 confirmed 完成，否则 confirm_order 一次；失败不确认，重取支付选项并重新下单；cancelled 不自行重试，已扣款会退款；cart_changed 不是支付失败，需与用户复核购物车；refund-initiated 告知后停止；pending 到上限后调用 confirm_order 一次。confirm_order 幂等，不会为未付款订单下单。现金无支付环节，直接跟踪，也是 UPI 不可用时的自动回退。Swiggy Money 于 2026 年 9 月 4 日宣布用于 MCP，启用时以 SwiggyPay 组出现，按现金处理且未列出时不得传。限制：设备询问、VPA、具体价格与更多服务细节暂未提供。