Can an AI Agent Redeem a Loyalty Reward in Shopify's Checkout? We Tested It on a Demo Store
Direct Answer Yes, in one controlled demo-store test. A loyalty reward code issued through Stabile's MCP server was accepted through Shopify's checkout discount field, and one completed test order settled a 300-point hold for a $10 reward. The test used synthetic data and a human completing payment on Shopify's page with a test card. This is evidence that one specific integration worked, not a result about merchants, conversion rates or autonomous payment.
A reward code is only useful if it reaches the checkout and works there.
We wanted to test that connection: could a reward issued through our MCP server be applied through Shopify's checkout tools, appear on the completed order and settle the right points?
On our demo store, it did. Two earlier attempts stopped before a reward was issued. Here is what happened in each case.
Why we tested this
Our October 14 post about reward codes and agent checkout outlined what a reward needs to survive an AI-assisted purchase, including several things we had not tested. Shopify's September 28 announcement, reported by PYMNTS, opened checkout on eligible stores to browser-based AI agents.
Shopify documents two interfaces for the same Universal Commerce Protocol (UCP) checkout capability:
- Checkout MCP: tools a server-side agent or client can call. This is the interface we tested.
- Checkout WebMCP: tools a browser-based agent can use on the buyer's checkout page. We have not tested this interface.
They share a checkout model, but a result through one interface does not verify the other. Shopify describes the distinction in its Checkout MCP and Checkout WebMCP documentation.
What we tested, and the guardrails
Our test environment used a dedicated demo store, synthetic loyalty data and test-mode payments. A custom client connected Stabile's MCP reward service to Shopify's checkout tools.
Three guardrails were in place:
- A human operator had to type
yesbefore a loyalty reward code was issued. - The client was programmed never to call
complete_checkout. A person completed payment on Shopify's page. - The client never printed the raw reward code or wrote it to its saved evidence files.
The client also asked for a second confirmation before handing off to Shopify's page. Issuing a reward and completing a purchase remained separate decisions.
The run, step by step
We completed one end-to-end run through our client tooling to observe how Shopify handled the reward code.
| Step | What happened | Number / metric |
|---|---|---|
| 1. Catalog Search | The client searched the demo store's catalog. | 9 products available |
| 2. Checkout Creation | It created a checkout for a single item selected from the catalog. | $29.99 item price |
| 3. Control Check | It updated the same checkout without a reward code to establish a baseline. | Baseline total verified |
| 4. Human Confirmation | The operator typed yes before reward issuance. | 1 issuance approval |
| 5. Reward Issuance | The MCP reward service issued one reward, reserving points until settlement. | 300 points → $10 off |
| 6. Code Application | The client submitted the code in one checkout API call. | 1 coded update |
| 7. Final Payment | After a second typed confirmation, a human paid on Shopify's page with a test card. | $27.99 final total, including shipping |
In the coded API response, the reported discount increased by $10.00 and the checkout total before shipping fell from $29.99 to $19.99. Shopify's discounts.applied array contained exactly one entry naming the reward code.
For comparison, a separate check with a nonexistent code returned an empty applied-discounts list and a discount_code_invalid warning.
Why was the final order total $27.99?
The buyer had not entered a shipping address when the coded response showed $19.99. After a US address was entered on Shopify's page, the store offered Standard shipping at $8.00 and Express at $15.00.
The completed test order used Standard shipping:
$29.99 item subtotal − $10.00 reward + $8.00 shipping = $27.99.
The item subtotal remained $29.99. The reward appeared as a separate discount line, and Shopify flagged the order as a test order.
Did the points settle correctly?
Following settlement, the synthetic customer's balance decreased from 1,650 to 1,350 points. That matched the 300-point reward, and one hold settled.
As a negative control, we then issued a second reward and deliberately never applied it. No second order appeared, and the points balance did not change. Its Shopify discount code was manually deactivated. That did not release the loyalty hold; it was left to expire under the existing program rules. We did not observe its expiry.
After the run, the demo store's billing page showed a $0.10 current usage balance, consistent with 1% of the $10 reward. The transaction was recorded through the Online Store channel, and no separate agent-channel fee was observed.
Two things stopped us before any reward was issued
Both stops prevented issuance. One required a correction to our client logic; the other was an expected confirmation-expiry check.
1. The delivery-address messages
On the demo store, the observed checkouts created without a shipping address carried two messages marked error, with severity recoverable: delivery_address_required and delivery_no_delivery_available.
Our initial client treated every error message as fatal and stopped at the control check. That assumption was too broad. We changed it to accept those two observed recoverable conditions while continuing to stop on other errors. The buyer could then supply the address on Shopify's page.
2. The five-minute confirmation window
Confirmation tokens generated by our bridge expire after at most five minutes. During one attempt, an extended human review pause exceeded that window, and the bridge refused the confirmation before issuing a reward.
Retrying with a fresh confirmation and answering promptly resolved the issue. An old approval was not silently reused.
What we learned
Read what Shopify says it applied. Totals alone cannot identify a code: an automatic store promotion could appear between requests. The discounts.applied result provided stronger evidence, and we also checked the discount on Shopify's page and completed order.
Distinguish recoverable conditions from failures. An address still needed from the buyer is different from an invalid reward code. Our client needed to recognize the specific conditions we had observed.
Give confirmations a deadline. The five-minute limit prevented an expired confirmation from authorizing reward issuance. The operator needs to know about that limit before pausing to review.
Keep issuance, approval and settlement separate. Human approval gated issuance. A completed order settled the hold. Issuing an unused code did not immediately reduce the points balance.
What this does not show
This was one completed order on one demo store, with synthetic loyalty data and a test-mode payment.
- It does not prove commercial viability, conversion lift or revenue performance for real merchants.
- It does not establish the same result on other stores, with other discount types, through Shop Pay or with other agents.
- It does not show an autonomous agent completing payment, live hold expiry or live webhook replay.
- It does not establish a complete loyalty-account integration across UCP simply because an externally issued code worked in a checkout discount field.
- It is not an endorsement by Shopify, Google, OpenAI, Meta or another platform.
What we test next
The browser-based interface, Checkout WebMCP, is the next question. Could a browser agent carry the same reward into checkout, with the buyer's confirmation?
We have not completed that implementation or run that test. It needs its own verification and may expose different failure modes.
Frequently Asked Questions
Did a real shopper or real merchant take part?
No. The test used our own demo store, synthetic loyalty data and a test card. It was a controlled integration test, not a merchant customer case study.
Does this mean Shopify officially supports loyalty in UCP?
This test does not establish that. Shopify lists loyalty programs among UCP capabilities, but accepting an externally issued reward code does not demonstrate a complete loyalty-account integration in a particular agent or store.
Did the autonomous agent complete the purchase?
No. The client handled checkout creation and discount application through API tools. A human completed payment on Shopify's hosted page. The client never called complete_checkout.
Can I try this checkout bridge on my own store now?
The experiment used custom bridge tooling tied to a private demo environment. That checkout bridge is not a publicly packaged feature of the ChatGPT plugin. A merchant implementation needs its own checkout and loyalty-rule verification.
Get started
Explore loyalty rewards in ChatGPT.
View Stabile: Loyalty Rewards Agent in ChatGPT →
The plugin lets shoppers check reward options and redeem eligible rewards with participating Shopify merchants. It does not create carts, process payments or place orders. The custom checkout bridge tested in this post is separate experimental tooling.
For the merchant checklist behind this experiment, read where a reward code needs to work when an agent shops.
Sources
The test results come from our October 17, 2026 project records and observations of the demo checkout, completed order, loyalty balance and billing page. They have not been independently verified outside this project.