Launching today
CartAI
The AI agent that handles checkout.
695 followers
The AI agent that handles checkout.
695 followers
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).
CartAI
Hey PH 👋
I'm Manil, founder of CartAI. We have been building CartAI for more than a year now and today we're shipping the developer release.
The problem we kept running into: every AI agent demo ends right before the part that matters. Browser automation can navigate the web but can't pay. Payment APIs can move money but can't navigate. Your agent gets to the checkout button — and stops.
CartAI is the API that closes that gap. Integrate, point an agent at any web property, and it completes the transaction — checkouts, subscriptions, invoices, orders.
It's four products covering the full transaction lifecycle, with checkout as the wedge everything sits on:
→ Catalog — find the product: search across merchants, live variants + pricing, and checkout estimates before a cart even exists
→ Checkout — clear the order: complete on the live merchant surface, tracked to confirmation with normalized orders + webhooks
→ Payments — move the money: hosted, PCI-compliant sessions on Visa Intelligent Commerce and Mastercard Agent Pay
→ Monetization — share the upside: affiliate commission captured automatically across 70,000+ brands, attribution preserved through to the sale
Three ways to use it:
→ Automate — your agent runs the full flow autonomously
→ Embed — drop our agent into your app workflow
→ Enable — add checkouts to surfaces that never had one. Make any surface commerce enabled.
What's actually hard here isn't the navigation. It's PCI-compliant payment handling, cooperative bot-mitigation so you clear checkout instead of getting blocked (we cooperate with Cloudflare/HUMAN/Akamai/Fingerprint via Web Bot Auth and signed agent identity using Skyfire — we don't evade them), and workflows that always terminate in a known transactional state. That's the part we built.
CartAI clears real orders on production merchants: start to finish, from one API call. There's also an open-source MCP server if you'd rather drop it straight into Claude, Cursor, or your own agent.
Would love your feedback, especially from anyone building agents that need to actually transact. What would you point CartAI at first?
Docs → docs.cartai.ai
@manil_uppal What’s the simplest, lowest-risk “first integration” you’d recommend for a developer who wants to test CartAI’s end-to-end transaction flow without exposing themselves to large financial or legal risk; for example: a specific merchant type, a sandbox/test merchant, or a particular payment/checkout pattern that proves the system while keeping complexity low?
the cooperative bot-mitigation angle (Web Bot Auth + signed agent identity instead of evasion) is the part that actually made me trust this more than most agent-checkout plays, that's a much more durable strategy than a cat-and-mouse scraper. one thing I didn't see addressed: if the agent completes checkout but the price or stock changed between the catalog quote and the confirmed order (this will happen on flash-sale or low-stock items), does CartAI guarantee the originally quoted price, or does the developer/end user just eat the discrepancy when it clears at a different amount?
CartAI
@galdayan
Thanks! I'm glad the cooperative trust model resonated with you—that's exactly the approach we believe will make Agentic Commerce sustainable.
On pricing and inventory, we actually treat the AI agent much like a human shopper. If a product goes out of stock or its price changes before checkout, a human decides whether to continue with the purchase. The same principle applies to CartAI.
Through our Agentic Payment Flows (e.g. Visa Intelligent Commerce and Mastercard Agent Pay), the AI agent is granted authorization to transact within predefined boundaries—such as a maximum spend amount or other purchasing constraints.
At checkout, CartAI validates the merchant's latest state. The purchase is completed only if the items are still available and the final amount falls within the authorized grant.
We also recommend that developers request a grant that's 5–10% higher than the expected order value. This provides a small buffer for dynamic shipping charges, taxes, or minor price fluctuations that commonly occur between product discovery and checkout, while still keeping spending within user-approved limits.
If the final amount exceeds the authorized grant or the item is no longer available, the AI agent doesn't proceed silently.
We believe this strikes the right balance between autonomy, flexibility, and user trust.
@kunalmestri9 makes sense, and the "doesn't proceed silently" part is the key detail for me - that's basically the same trust model as a card pre-auth hold, just extended to an agent. good to know the buffer is a recommendation rather than something baked in with no visibility. appreciate the detailed answer, following along as you ship the developer release.
CartAI
Thank you@galdayan . We appreciate your support 🙏
Coming at this from the merchant side, we build support tooling there, so my head goes straight to what happens after a wrong order clears.
The thread's covered the price/stock case at checkout. The one I don't see: the order completes fine, and then it's wrong. Wrong variant, wrong address, size M when the person wanted L. On a human order the merchant's support desk just emails the buyer, confirms, sends a return label. The whole post-purchase flow assumes a human on the other end who can answer "which one did you mean".
When the buyer was an agent, who does the merchant's support team reach? The agent is an API, not an inbox. The end user is behind someone else's app. So a returns or "wrong item" ticket lands on a merchant with nobody reachable to resolve it.
Does CartAI keep a channel open back to the buyer after confirmation, or does the agent vanish at the confirmation webhook and leave the merchant holding a ticket they can't close…
CartAI
@jernej_jan_kocica Great question. CartAI places the order with no loss of fidelity between the consumer and the merchant. So the contact information(email, phone) etc that goes with the order is of the end consumer. Any post purchase or customer service activities including customer reach back etc will follow exactly your normal processes as the order we place will look no different than any other E-com orders that you get.
@manil_uppal Ok, that makes sense, the consumer contact riding on the order is the important part.
Half of it anyway. Contact is solved, context is not. The customer told their agent to buy, they never saw my store, so when support writes to ask which size they meant it comes from a brand they don't really remember..
The other thing bugs me more. You said earlier signed agent identity lets merchants distinguish trusted agents and set policy. But if the order then looks no different than any other order, that signal stays at the bot-auth edge and never reaches the order record. Support and ops don't work at the edge, they work off the order in the admin.
So does the agent origin land on the order itself, a tag or an attribute, or is it gone by then?
CartAI
@jernej_jan_kocica
I completely agree.
Today, most merchant systems don't distinguish between an order placed by a human and one placed by a trusted AI agent. That context often ends at the security layer.
But I see that as a question of when, not what. As Agentic Commerce becomes more widely adopted, merchants will naturally evolve their commerce and operational systems to absorb agent identity as part of the order lifecycle.
The good news is that the trust rails are already being established. Providers like Cloudflare, HUMAN, and Akamai are building the identity and trust infrastructure at the edge.
The next step is carrying that trusted identity deeper into merchant systems so support, operations, analytics, and customer service can all benefit from it.
We believe agent identity shouldn't just help decide whether to allow a checkout, it should become part of the commerce context that follows the order throughout its lifecycle.
@kunalmestri9 Fair, and "when not what" is probably right for real signed identity.
But for the basic case you might not need merchants to evolve at all. The buyer can already write to the order, order notes on Woo, cart note on Shopify if the theme exposes it, and that text lands in the admin where support actually looks. You are filling the checkout anyway.
Not identity, obviously. Forgeable, unsigned, useless for policy. But it would put "this came from an agent" in front of the support person on day one with no merchant work, which is the whole point of your no-integration angle.
Would you write something there by default, or does that count as polluting the order..
Congrats on the launch @maniluppal! Solving the execution wedge with cooperative Web Bot Auth rather than scraper evasion is definitely the right long-term move.
On the payments side, when an agent executes a purchase via Visa Intelligent Commerce or Mastercard Agent Pay, how is chargeback liability and dispute resolution structured between the agent developer, CartAI, and the issuing bank? If an end-user claims their agent made an unauthorized purchase within its spending grant, does the tokenized agent identity serve as cryptographic proof of authorization during a dispute?
CartAI
@franz_briones Great question, and it's the part of agentic payments people still don't talk about enough.
The main thing agent identity changes is the evidence around a transaction. On both Visa Intelligent Commerce and Mastercard Agent Pay, the purchase carries a token scoped to the agent plus a signed record of the user's mandate: the spend grant, its limits, and proof the agent acted inside them. That works a lot like a 3DS authentication signal. A properly authenticated agent transaction that stayed inside its grant is designed to move fraud liability off the merchant, the same way authenticated card not present does today.
Where @CartAI sits: we're infrastructure, not the issuer or the merchant of record, and we don't adjudicate disputes. What we provide is the cryptographic authorization trail. Who consented, what the grant was, and proof that execution stayed within it. That gives the developer and merchant real evidence to represent a dispute.
So on your exact case, an agent buys something inside its grant and the user later calls it unauthorized: the signed agent identity plus the mandate is strong evidence the purchase was authorized, and materially better than anything in current card not present flows. It strengthens the issuer's picture rather than replacing their decision.
Hi @CartAI Team,
First of all, Many many congratulations for such a great launch, 🎉
Really like the approach of working with bot detection instead of trying to sneak past it. Getting listed in Cloudflare’s verified bot directory is not something most teams can pull off.
One question though. Since you’re checking out on live merchant sites, what happens if a payment goes through but the site glitches before the confirmation shows up? Does the system know not to retry and charge the customer twice? Curious how you handle those messy edge cases, because that feels like the hardest part of making this reliable.
Rooting for you guys, the idea makes a lot of sense. Great job 👏
CartAI
@waqas_baloch4
Great question !!
The agentic order is considered successful once the merchant processes and confirms it. Any failure during this period will fail the entire transaction.
We do not retry if the merchant site glitches before the confirmation and fails to display an order confirmation page.
@aman_gupta14 Hi Aman, Thanks for the clear answer! Failing safe instead of retrying blindly is definitely the right call, way better than risking a double charge.
Out of curiosity, in the rare case where the card gets charged but the glitch happens before the confirmation shows up, does the system catch that afterwards and update the order? Would love to understand how you close that loop, since handling it well would honestly be a huge trust signal for anyone building on top of you.
Btw, Loving the thoughtful engineering behind this.
Great work!
CartAI
@waqas_baloch4
Really appreciate you asking this.
Our agent uses the customer's contact information when interacting with the merchant, so the merchant remains the source of truth and customers continue to receive official order confirmations through the merchant's existing communication channels.
Our agent intentionally doesn't infer the outcome without confirmation, preferring accuracy over making potentially incorrect assumptions.
The charged-but-no-confirmation case Waqas raised is the one I'd lose sleep over building this. When we ran agents against checkout flows we didn't control, the timeout was never clean: the backend committed but the confirmation render died, and our side couldn't tell 'it failed' from 'it succeeded and we didn't hear back'. Since the Visa and Mastercard tokens are scoped per agent, can you reconcile against the payment network's authorization record instead of the merchant's confirmation page, so a dropped render doesn't strand a real charge?
CartAI
@dipankar_sarkar
That's a great question—and trust us, we've already spent plenty of sleepless nights thinking about this exact scenario. It's one of the reasons this has become a recurring discussion in almost every conversation we have with our payment providers.
Today, if CartAI doesn't receive a definitive confirmation from the merchant, we intentionally treat the checkout as failed rather than assuming success. From the developer's perspective, there are only two possibilities:
The merchant successfully created the order, but the confirmation never made it back to CartAI.
The merchant never completed the order.
In the first case, the customer is still the contact on the order, so they'll receive the merchant's normal order confirmation and post-purchase communications even though CartAI couldn't verify the final state.
Your suggestion about reconciling against the payment network's authorization record is exactly the kind of capability we're exploring with our payment partners.
We don't consider this problem fully solved yet, and we're actively working on making this edge case much more transparent for developers.
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.