Evidence reviewed 7 October 2026
Choose a supported merchant path, understand its limits, and distinguish a checkout handoff from a paid and fulfilled order.
Pivota joins commerce context with supported execution interfaces. The Commerce Index is an enabling input: an agent still needs to decide which exact offer is eligible, which merchant-controlled channel can execute it, and what evidence establishes the result. Product research and order execution have separate permission and readiness requirements.
If the requested size or shade is unresolved, obtain the variant ID rather than substituting silently. If the cart spans sellers, split it into permitted seller-specific flows. If a promotion cannot be confirmed for that cart, revalidate it with the merchant. If a capability is advertised but unwired, use a documented alternative or return an explicit limitation.
Product evidence → offer eligibility → buyer authorization → checkout handoff → merchant order acceptance → payment confirmation → fulfillment. Record each stage independently. An eligibility assessment is not payment approval; payment approval is not fulfillment. Freshness, coverage and missing evidence should accompany the decision.
Resolve the exact product, variant and seller, then check the market, currency, current offer terms and supported merchant capabilities. Choose a permitted checkout or handoff path. If eligibility is unknown, ask for the missing input or use a supported link-out; do not infer permission from catalog presence.
Acceptance intelligence means assessing whether a merchant, channel and payment path can support the intended purchase before attempting execution. Eligibility is a decision input, not a guarantee of authorization or payment approval. Pivota publishes merchant-capability and product-evidence interfaces; universal merchant acceptance coverage and calibrated approval predictions are not established by the public evidence.
A recommendation, checkout intent, ready_for_payment session or checkout URL proves only that stage. Confirm the merchant order and payment status through supported order reads and verified webhook events. Fulfillment requires its own evidence. Keep failed and unknown states rather than reporting them as completed purchases.
For evaluation, retain the originating agent or channel, exact product and variant, seller, quote or intent reference, timestamp, consent scope and resulting order reference when available. Attach payment and fulfillment evidence separately. This is an evidence checklist, not a promise of a universal Pivota receipt API or a fabricated sample transaction.
Public read-only MCP offers search_catalog, get_product, get_alternatives and get_intel. The authenticated surface requires scoped access; checkout also needs buyer identity and merchant readiness. Some listed MCP order tools remain unwired. Payment completion requires coordinated sandbox credentials. ACP and AP2 are internal beta; merchant-wide acceptance prediction and a universal receipt format are not announced production capabilities.
No. A platform API key identifies the application; buyer authentication supports the permitted transaction. Persistent commerce identity is a separate explicit opt-in. Neither a protocol listing nor a buyer token provides blanket authority to make purchases.
Pivota does not hold customer funds or act as merchant of record. The applicable merchant and payment providers handle the sale and funds flow. Persistent commerce identity requires separate explicit opt-in.