# Shopify Cart MCP or Checkout MCP: where should a merchant require credentials?

Canonical: https://mudpie.ai/webmcp/guides/shopify-cart-or-checkout-where-credentials-begin/
Breadcrumb: [Home](https://mudpie.ai/) / [WebMCP guides](https://mudpie.ai/webmcp/guides/) / [Shopify Cart MCP or Checkout MCP: where should a merchant require credentials?](https://mudpie.ai/webmcp/guides/shopify-cart-or-checkout-where-credentials-begin/)
Author: Ali Abouelatta (https://mudpie.ai/authors/ali-abouelatta/)
Published: 2026-09-19
Updated: 2026-09-19
Research type: guide
Method: Current Shopify Cart/Checkout and authentication documentation synthesized into a stage-by-stage decision. No purchase or third-party action was performed.

Require stronger identity before purchase authority, not before every commerce step. Let an agent browse and build context without credentials where the platform allows it. Make the boundary explicit before checkout completion, order access, or anything that commits the buyer.

Shopify’s current agent documentation is useful because it exposes a distinction that product teams often flatten: a cart is exploratory state; checkout is a purchase workflow. The exact credential boundary is tiered, so “checkout requires login” is too simple to be a safe implementation rule.

## Read the two Shopify pages together

The [Carts and checkout guide](https://shopify.dev/docs/agents/carts-and-checkout) describes Cart MCP as a way to iterate on line items and estimate totals before credentials. It describes Checkout MCP as the path for a buyer who is ready to purchase and says checkout sessions require authentication or a signed request.

Shopify’s newer [authentication and rate-limiting page](https://shopify.dev/docs/agents/profiles/auth-and-rate-limiting) adds an important qualification: the current traffic-tier table lists Catalog, Cart, and Checkout tools for anonymous and signed agents, while `complete_checkout` is unavailable to anonymous and signed traffic. A token can complete checkout only when it has the required permission.

That is not a contradiction you should hide. It means “checkout tools” includes building or editing checkout state, while final purchase authority is a separate capability.

## The practical boundary

| Stage | Credential posture | What the agent can safely do | Founder decision |
| --- | --- | --- | --- |
| Product discovery | Anonymous or identified | Find products and variants | Keep public facts clear and current |
| Cart exploration | Anonymous is documented | Add, inspect, replace, or cancel line items; estimate totals | Let the buyer refine intent before asking for identity |
| Checkout preparation | Tier-dependent | Create or update checkout state, resolve missing details | Treat it as sensitive preparation, not a completed purchase |
| Purchase completion | Token plus explicit permission | Complete only when the shop and token allow it | Keep payment and approval boundaries visible |
| Review or escalation | Merchant storefront | Continue through the merchant’s checkout URL | Hand off with the cart and context preserved |
| Order access | Scope-dependent | Read orders only where the documented token scope allows it | Never infer order access from cart access |

The clean policy is: anonymous for exploration, identified or signed traffic for the parts of checkout that need it, and explicit permission for final completion. If the current platform contract allows an anonymous agent to build some checkout state, that still does not make the agent a buyer or give it permission to complete payment.

## Why the cart should come first

Cart state is where the agent can do useful work while the buyer is still deciding. It can hold line items, buyer context, and estimated totals. The [Shopify guide](https://shopify.dev/docs/agents/carts-and-checkout) describes carts as suitable for long-running exploratory sessions and says an agent can share a cart with the buyer before starting checkout.

That gives the product a better first conversation:

1. Find products and variants.
2. Add the buyer’s chosen items to a cart.
3. Show the estimated total and any known missing information.
4. Ask whether the buyer is ready to continue.
5. Convert the cart to checkout only when the workflow needs checkout state.

The agent should not collect payment credentials in the conversation just because it has reached step four. Use the merchant’s documented checkout and approval path.

## Checkout is preparation, not permission to finish

The current Shopify auth table makes the final boundary concrete. Anonymous and signed traffic do not get `complete_checkout`; token traffic may get it when the token has the required permission. Rate limits also vary by identification tier, and Shopify says Checkout MCP is more strictly limited than Cart MCP at every tier.

So a merchant should avoid a single boolean such as `agent_can_checkout`. Track at least:

- Can the agent read catalog facts?
- Can it create or update a cart?
- Can it create or update checkout state?
- Can it resolve missing buyer or fulfillment details?
- Can it complete the purchase?
- Can it read orders afterward?

Each answer needs its own auth and approval rule. This is more work than a single badge. It is also much clearer to a buyer.

## The handoff is part of the product

Shopify documents `continue_url` handoffs for incomplete, escalated, or ready-for-completion states. That is the useful human boundary: the agent preserves the cart or checkout context, then sends the buyer to the merchant’s storefront for the step it should not silently perform.

The merchant remains the merchant of record. Keep that visible. A good handoff says what is ready, what is missing, and where the buyer will finish. It does not imply that an agent has paid, placed an order, or verified a fulfillment result.

## The decision

If you are building an agent-operable commerce surface, start with anonymous catalog and cart exploration. Add checkout preparation only when you can name the required identity, rate limit, and missing-field behavior. Reserve final completion for explicit permission and a documented token path. When review is required, send the buyer to the merchant storefront with context intact.

This is a documentation-derived design boundary, not a live Shopify checkout test. No purchase or third-party action is part of the recommendation.


## Author disclosure

I cofound Lazyweb and publish Mudpie. This is an owner-written publication, not an independent testing organization. Research notes distinguish observations, sourced reporting and editorial judgment.