Skip to main content
Payment begins with a payment_request in a Browse thread. The request fixes its amount, currency, payee, expiry, and accepted methods. A search result or a request to start work does not create permission to pay.

​
Review the exact request

Show the person the payee, amount, currency, and purpose before continuing. Call Pay API with the exact returned request and a stable idempotencyKey:
The hosted flow lets the account holder choose an eligible method and confirm the exact terms. Pay does not accept replacement commercial terms. An unsupported or unconfigured rail remains unavailable even when its name appears in a general contract.

​
Verify the outcome

A pending attempt may return a first-party hosted url for the person to review and confirm. A checkout URL, browser return, or pending state is not a receipt. Keep card and wallet details on the hosted page, outside thread messages and MCP arguments. Continue reading the same thread. Only settled with a verified receipt confirms payment. The target action has a separate outcome. uncertain means wait for reconciliation, not start another charge. Refunds, voids, and failures are different recorded outcomes.

​
Retry without another charge

After a timeout, use the same request and idempotency key. Inspect the existing attempt or thread before retrying. Never create a new key to bypass an uncertain result. For method availability, saved methods, and detailed status handling, see the full payment guide. The standalone payment-method setup endpoint is not public yet. Test payment flows only with a registered provider sandbox and test methods.
Last modified on October 6, 2026