CartAI - The AI agent that handles checkout.
by•
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).
Replies
the cooperating with bot detection instead of evading it line is the most interesting part of this. i sell software online and my first thought was whether i'd even know an agent checked out on my site. what does the merchant actually see when cartai comes through?
@terminal_candy At the security layer, you see us. If you run Cloudflare, HUMAN, Akamai, or Fingerprint, CartAI shows up as a declared, signed agent via Web Bot Auth. A known identity you can allow, challenge, or block. We arrive labeled, and we're listed in Cloudflare's bot directory, so it isn't guesswork.
In your admin, less. The order lands looking like a normal ecommerce order with the real consumer's email and phone, because order records don't yet have a field for "an agent placed this." So you'd know from your bot detection, but not from the order itself today.
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?
@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?
@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.
@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.
@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.
@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?
@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.
@Manil Uppal the QA-agent-checks-the-order-agent setup plus the strict 100% variant match (no fuzzy 'best guess') makes a lot more sense now, that's a much narrower and safer surface than I assumed from the pitch. does the QA check happen before the order is actually submitted to the merchant, or after - i.e. can it catch and stop a bad match pre-purchase, or is it more of a post-hoc audit?
@omri_ben_shoham1
The QA check happens before the order is submitted to the merchant.
Think of it as the final validation step. The @CartAI execution agent prepares the checkout, and the@CartAI validator agent verifies that the product, variant, quantity, and other order details exactly match the user's intent.
We intentionally don't allow fuzzy "best guess" substitutions.
Only after the validation checks pass does the purchase proceed. If there's any ambiguity or validation failure, the checkout is stopped rather than risking an incorrect purchase.
That's another guardrail we believe is essential for building trust in Agentic Commerce.
Actually, purchasing is the most risky part of the whole process, so I feel like many people would hesitate to fully automate the checkout step. I'm curious how you handle purchase automation. Does the AI prepare everything, add items to the cart, and then ask the user for confirmation before payment? Or is it designed to make the purchase decision and complete the payment autonomously?
How do you manage the balance between automation and user control?
@jason91028238
That's a great question, and we think it's one of the biggest challenges in Agentic Commerce.
Our philosophy is that AI should automate execution & not the spending decisions.
The agent can search for products, compare options, build the cart, and prepare the checkout. But before payment, the customer explicitly authorizes the purchase by granting the agent permission to spend up to a defined amount for that specific order using Visa Intelligent Commerce or Mastercard Agent Pay.
Once that grant is given, the agent can complete the checkout autonomously within the approved limit. It cannot spend beyond that amount, and if the final checkout exceeds the authorized grant, the transaction fails.
We believe that's the right balance: consumer choice, merchant control, and automation within clearly defined guardrails.
@thys_beesman
We believe trusted agents should be recognized, not disguised (as mimicry).
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 flow for commission actually works a bit differently.
The merchant selection happens before Checkout enters the picture and is determined by the AI application's recommendation logic or the customer's explicit choice.
Once the merchant is finalized, CartAI simply finds the most appropriate affiliate network for that merchant to attribute the transaction and maximize publisher revenue. We don't influence which merchant the customer buys from. We only optimize the attribution after that decision has already been made.
That separation is intentional. Merchant choice should always be driven by what's best for the customer, not by affiliate economics.
@kunalmestri9 Appreciate the detail on the partnerships Visa/Mastercard agent rails plus the anti-fraud stack (HUMAN, Akamai, Fingerprint) makes sense as the "recognized, not disguised" answer.
Still curious about the other half though: with commission flowing from 70k+ brands, does the agent ever see or weigh that commission rate when ranking options for the buyer, or is merchant selection completely blind to it until after the purchase is already decided on price/fit? That's the detail that'd tell me whether it's a pure user-agent or one with a quiet thumb on the scale.
@thys_beesman
That's an important question, and our philosophy is to keep those concerns completely separate.
The agent decides what to recommend based on the application's own recommendation logic and the customer's preferences & not on the affiliate economics.
Once the customer (or the recommendation engine) has finalized the merchant, then CartAI determines the most appropriate affiliate network for that merchant to attribute the transaction. Affiliate optimization happens after the merchant has already been chosen, never before.
We believe merchant selection should always be driven by what's best for the customer. Monetization should happen after that decision, not influence it. That separation is intentional.
That being said, it's not a passive or "dumb" user agent. It actively works on the customer's behalf to verify the correct product and variant, avoiding overpriced or incorrect purchases, applying available coupons, and optimizing the checkout experience while keeping the selected merchant unchanged.
The intelligence is used to benefit the customer, not to influence where they buy once the checkout starts.
@thys_beesman We are able to enable monetization on the check out. There is no scope of any preference based on commission because the input to our api is a PDP url from the merchant so we expect our customer's users to decide what they want to buy. We just do the order placement execution.
There is a shopper experience challenges also needs a solution. Once the agent framework is embedded, the users can benefit from access to right discounting, comparison shopping, size selection, and more automated tools. Hopefully by solving merchant checkout, users can also benefit.
Absolutely @shubydoo
Merchant checkout is only one half of the problem. There's an equally important shopper experience that still needs to evolve.
From your work in this space, I'm sure you've seen many of these challenges firsthand. That's where I think the broader ecosystem has a huge role to play. Teams like yours can continue pushing the consumer experience forward; better recommendations, comparison shopping, discounts, sizing, personalization, and all the other pieces that make shopping genuinely easier.
Our role at CartAI is to provide the trusted transaction layer that turns those experiences into actual purchases. If we can solve checkout well, it gives partners across the ecosystem the foundation to build the next generation of AI-powered shopping experiences.