Checkout is the hard part, and most solutions clear it only where the merchant has integrated. CartAI completes checkout on any live merchant surface with no merchant-side work, cooperating with bot detection instead of evading it. One developer-first API, four products: Catalog (search and live pricing across merchants), Checkouts (clear and track orders to confirmation), Payments (PCI off your stack via Visa and Mastercard agent rails), Monetization (commissions on every agent sale).
Fail-closed is the right default, and I like that you'd rather under-claim than over-claim a success. The case that still bit us was the inverse: the charge actually settled on the merchant side while our side had already marked it failed, so the user retried and paid twice. Does the per-agent token give you a way to reconcile a 'we called it failed but it settled' mismatch after the fact, or does that fall to a manual dispute?
CartAI
@dipankar_sarkar
That's a fair concern. In that scenario, the customer would already have received the merchant's order confirmation because we use the customer's own contact and shipping information as first-party data during checkout.
So while CartAI may have marked the checkout as failed due to the missing confirmation, the customer would still be notified directly by the merchant if the order was actually created. That significantly reduces the likelihood of an unnecessary retry leading to a duplicate purchase.
That said, improving reconciliation for these rare edge cases is something we're actively working on with our payment partners.
Right, first-party contact means the shopper still gets the merchant's email even when your side logged a fail. What I keep circling is the fully-autonomous case where nobody reads that email: CartAI's own record stays 'failed' while the money actually moved, so the calling agent could retry and pay twice. Do you expose a reconciliation signal, a webhook or a status I can poll later, so the agent can catch a settled-after-failed order before it re-runs checkout?
CartAI
@dipankar_sarkar
That's a really good question.
One important difference with Visa Intelligent Commerce and Mastercard Agent Pay is that the customer grants spending authorization before checkout, and that grant is scoped to a specific order.
For example, if the customer authorizes an agent to purchase a shampoo for up to $100, and the checkout succeeds for $99, that grant has been consumed. Even if the agent retries because CartAI didn't receive the merchant's confirmation, it can't simply charge the customer a second time using the same grant.
If a developer were to initiate a brand-new grant, the customer would need to approve it again. In practice, if they've already received the merchant's confirmation or know the purchase went through, they're unlikely to authorize a duplicate purchase.
You're absolutely right that the lack of visibility after a successful-but-unconfirmed checkout is an edge case we're actively working on with our payment partners. But the underlying agentic payment guardrails are designed to prevent an agent from repeatedly charging a customer for the same purchase, even if a retry occurs.
completing checkout on any merchant surface with zero integration work is the hard part everyone else punts on, so props for actually shipping that instead of just a demo video. curious how disputes/refunds work in practice - if the agent picks the wrong variant or size because the merchant's page was ambiguous, does the normalized order data make it easy for the end user to catch that before it ships, or does it only surface after the fact like a normal order confirmation email would?
CartAI
@omri_ben_shoham1 So we do have a cart verification step where we have our QA agent check the work of our order placing agent to make sure the right variants, quantities etc were added to cart.
Also our order input api asks for the exact variant name and selection and we expect that to match what is on the website or the agent will not execute. The agent is trained not to "guess" or find "best match". It has to be a 100% match. That is also the reason we also have a catalog api service where we show the products and the exact variants available for sale with the merchants. We have made the path intentionally narrow to make sure there are no errors during execution.
The buyer-side and merchant-side approaches to this are converging fast, and the tradeoff you picked is the interesting one. Protocol-based integration only works where the merchant has already done the work, which is a thin slice of the web today, so completing on the live surface covers far more ground immediately.
The part I would watch is order state after confirmation. Refunds, partial cancellations and price changes get messy to normalize when you do not own the merchant's system of record.
Do the webhooks cover post-purchase events, or is confirmation the end of the tracked lifecycle?
CartAI
@paul_crinigan Today order confirmation is the terminal state. Once an order is placed the communication becomes direct between the merchant and the consumer. We do not insert ourselves in the middle of that conversation with email relay type techniques etc. We will see how this evolves over time
The protocol based approaches support post purchase messages a bit better(UCP for example) but there are no examples of UCP being pointed to 3rd party demand agents like @CartAI today so as you say, adoption is low at this point but we are hoping it picks up.
The 'checkout as the wedge, no merchant-side integration' framing is the interesting part for me, since that's the piece every agent demo skips. The first thing I'd test is failure semantics on Checkout: if the agent clears a cart but the confirmation webhook never lands — merchant surface changes mid-flow, or the session times out — does the API give me an idempotency key so a retry can't double-charge, and do I get a clean failed state with no partial charge? That reconciliation is where agent payments usually fall apart in support.
CartAI
@hazy0
Great question. Yes, every checkout has its own idempotency key, and every payment grant issued through Visa Intelligent Commerce or Mastercard Agent Pay has its own unique identifier. A checkout only succeeds when a valid payment grant is consumed.
If a consumed payment grant is used again, the transaction is rejected, preventing duplicate charges. If checkout fails before the grant is consumed, the customer's account is never charged.
That's clean — consuming the grant as the success gate closes the double-charge path well. The one I'd still want to nail down: if the grant is consumed (money moved) but the confirmation webhook back to CartAI is lost or delayed, does a client retry with the same idempotency key safely no-op and return the original success, or can it read as a fresh failed checkout? That lost-ack case is usually where a 'failed' order turns out to actually be paid.
CartAI
@hazy0
That's exactly the edge case we've been discussing throughout this thread.
If the payment grant has already been consumed, retrying with the same idempotency key will not create another charge; the payment guardrails prevent that.
The harder problem is the lost acknowledgment. If the merchant completed the order but the confirmation never reached CartAI, we currently prefer to return a failed state rather than incorrectly claiming success. We intentionally fail closed.
We're actively working with Visa Intelligent Commerce, Mastercard Agent Pay, and our payment partners on improving reconciliation for these scenarios so we can surface a more definitive post-checkout state. It's not a solved problem across the industry yet, but it's one we're investing heavily in because it's critical for trustworthy Agentic Commerce.
That said, for this scenario to actually occur, the merchant's systems would have to fail at a very specific point: the payment is successfully processed, but the merchant's confirmation page or confirmation response fails to reach CartAI immediately afterward.
It's a rare distributed systems edge case, but one we take seriously.
"Cooperating with bot detection instead of evading it" is the most interesting technical claim here since it's the opposite of how most browser automation tools in this space work. What does "cooperating" actually mean in practice, is CartAI disclosing itself as an agent to merchant bot detection systems through some kind of agreed protocol, or is it more that it mimics human behavior closely enough that detection doesn't trigger? Those are very different things ethically and legally.
CartAI
@ansari_adin
I think this distinction is one of the most important aspects of Agentic Commerce.
We believe trusted agents should be recognized, not disguised.
CartAI identifies itself as an AI agent and works within the merchant's existing trust and security ecosystem. We don't believe the future of Agentic Commerce is about making bots look more human or trying to evade bot detection.
That's why we're building alongside the emerging Agentic Commerce ecosystem through partnerships with Visa Intelligent Commerce, Mastercard Agent Pay, Cloudflare, HUMAN, Akamai, Fingerprint, and Skyfire KYA, while embracing the new standards they're introducing for agent identity and trust.
The goal is simple: enable merchants to recognize, authenticate, and apply their own policies to trusted AI agents—not hide their existence.
We believe that's the only approach that scales long term. Agentic Commerce should be built on merchant choice, not circumvention.
@kunalmestri9 The partnership list with Visa, Mastercard, Cloudflare, and HUMAN is a strong signal that the infrastructure side of agentic commerce is being built intentionally. The harder question is timing: right now most of those partnerships are producing standards and pilots, not live merchant implementations at scale. What percentage of CartAI's current checkout completions are happening through recognized agent channels versus surfaces that don't yet support agent identity, and how does that ratio affect the "cooperating not evading" claim in practice today versus where it's heading?
CartAI
@ansari_adin
Our view is that consumer choice will create an entirely new publisher ecosystem.
AI experiences that specialize in recommendations, discovery, and deeply personalized shopping.
CartAI bridges the gap between those recommendations and an actual purchase by providing the transaction layer that enables truly agentic behavior.
I agree that most merchants haven't yet evolved their internal systems to surface agent identity throughout their order records and operational workflows.
But the foundational trust infrastructure is already being built. Cloud security providers and payment networks are establishing the rails for trusted agent identity, and we believe merchant systems will naturally evolve to take advantage of them.
Ultimately, we think merchants stand to benefit the most. Agentic Commerce isn't replacing their existing channels; it's creating a trusted new acquisition channel that brings them customers with purchase intent already established.
We're also looking forward to publishing data on our use of identity frameworks across CartAI checkouts soon. The pace of adoption has been faster than many people expect, and we think the numbers will surprise the community.
I like that checkout works without merchant integration. How do you handle unexpected checkout changes on different stores? Publishing success rates by merchant could build more confidence.
CartAI
@alheri_murya
Thanks! That's a great question.
Handling dynamic checkout experiences is one of the core challenges we're solving. CartAI continuously adapts to changes in merchant checkout flows through our automation and validation layer, allowing us to remain resilient even as storefronts evolve.
I completely agree on merchant-level success metrics. As the platform grows, we'd love to publish coverage and success rates to give developers better visibility and confidence.
Thanks for the thoughtful feedback!