Launching today
CartAI
The AI agent that handles checkout.
685 followers
The AI agent that handles checkout.
685 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
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.
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!
Me value the simple API approach for developers. What monitoring tools are available after checkout starts? Real time alerts could help teams respond faster.
CartAI
@hana_salazars
Thanks!
Excellent developer experience has been one of our core priorities from day one.
Once a checkout is initiated, developers can track its lifecycle through our Webhooks, receiving real-time events for important state changes and integrating those into their own monitoring or automation workflows.
We also provide a portal where teams can monitor orders, inspect checkout status, and troubleshoot issues when needed.
We believe every team has different operational needs, so rather than locking developers into a predefined alerting system, CartAI gives them the building blocks to create monitoring and notification workflows that fit their own stack.
Native email and SMS alerting are already on our roadmap and will be rolling out soon, making it even easier for teams to stay informed without building custom notification workflows.
Really appreciate the suggestion—feedback like this helps us prioritize what developers need most. 🚀