Senta Checkout

Order food by text. Tell Senta Checkout what you want, customize it in conversation, and go straight to checkout without opening a delivery app.

Comment 1

Inspiration

Most food ordering apps are built around browsing. You open the app, search for a restaurant, scroll through a menu, tap through a bunch of options, build a cart, and eventually check out.

That makes sense when you are exploring, but a lot of the time you already know what you want. If I know I want two Crunchwraps from Taco Bell, it feels unnecessary to go through all of that just to place the order.

Senta is a conversational commerce platform I was already working on before HackGT. This weekend, I wanted to push one part of that idea much further and see if the shopping interface itself could disappear.

Instead of opening a marketplace, what if you could just text what you wanted and let the system handle everything between that message and checkout?

That became Senta Checkout.

What it does

Senta Checkout lets someone order food through a normal text conversation.

You can send something like

Get me 2 Crunchwrap Supremes from Taco Bell

and Senta starts building the order from there.

It figures out the restaurant, finds the right item, keeps track of quantity, asks for required customizations, remembers what you chose across messages, builds the cart, and gets you to checkout.

You can also respond the way you normally would over text. Things like

make it 3

no tomatoes

actually get the first one

switch to Taco Bell

forget my order

The important part is that the user does not have to learn a new interface or phrase things perfectly. The conversation itself becomes the shopping interface.

That is what made the Visa Reimagine Shopping challenge such a good fit for what I wanted to build. Instead of making another food delivery interface, I wanted to see what shopping looks like when AI can understand the user's intent and remove most of the steps between wanting something and paying for it.

How I built it

Senta already had messaging and agent infrastructure before HackGT. My work this weekend focused on the actual food ordering and checkout flow.

I built and hardened the logic for resolving a restaurant from a conversation, finding the right menu item, handling quantities and required modifiers, keeping an order consistent across multiple messages, creating provider-backed carts, and moving that order into checkout.

A lot of the work ended up being around conversation state.

If someone says "make it 3," the system has to know what "it" refers to. If they switch restaurants halfway through an order, the old menu and cart state cannot accidentally carry over. If they change an item after checkout has already been created, that old checkout should no longer represent the current order.

I used OpenAI models as the language layer of the product. The model helps interpret messy, natural messages like "the first one," "no tomatoes," or "actually make it 3" and turns them into something the ordering system can act on.

I deliberately did not let the model directly own the actual cart or payment state. Once the system understands what the user means, deterministic application logic tracks the restaurant, item, quantity, modifiers, cart, and checkout state.

That split ended up being one of the most important parts of the system. AI makes the interaction flexible, while normal application logic keeps the transaction predictable.

The backend is built with TypeScript and Node.js. I used Linq for messaging, OpenAI for language understanding, DoorDash-backed commerce tooling for restaurant and menu data, Stripe for checkout, Supabase for persistence, and Docker on DigitalOcean for deployment.

Challenges I ran into

The hardest part was not getting an AI model to understand "I want a Crunchwrap."

The hard part was everything that happens after that.

Real conversations are messy. Someone can pick an item, change the quantity two messages later, switch restaurants, cancel the order, come back, or just respond with something like "the first one."

I ran into cases where old restaurant state could survive into a new order, quantities could be interpreted incorrectly, carts could outlive the conversation that created them, and external provider calls could fail even though the cart itself was still valid.

I also learned pretty quickly that a commerce agent has to be much stricter than a normal chatbot. If a chatbot gives a slightly weird answer, that is annoying. If a commerce agent picks the wrong restaurant, modifier, quantity, or payment amount, that is a much bigger problem.

A lot of my time went into testing those transitions and making sure the system knew when it could safely continue an order and when it needed to stop and ask the user.

Accomplishments that I'm proud of

I am proud that the demo works with real restaurant and menu data rather than a hardcoded fake ordering flow.

Senta Checkout can take a real food request, carry the order across multiple messages, handle required choices, preserve item and quantity state, create a real provider-backed cart, and move the user toward checkout.

I also spent a lot of time testing the way people actually text instead of designing the product around perfect prompts.

The simple version of the idea is "just text what you want."

Getting that sentence to actually work required connecting AI language understanding, restaurant and menu data, conversation state, cart logic, external providers, and payments without exposing most of that complexity to the user.

That is the part I am most proud of.

What I learned

I went into the weekend thinking conversational commerce was mostly an AI problem.

It turned out to be just as much of a state and reliability problem.

The AI is useful because people do not talk like APIs. They say things like "that one," "make it two," or "actually never mind." A language model makes that interface possible.

But once an order becomes real, the system needs much stricter rules around what is actually in the cart.

I also learned that the best version of conversational shopping probably does not replace browsing entirely.

Sometimes you want to scroll through restaurants and discover something new. But when you already know what you want, forcing you through that same interface creates work that does not need to exist.

That changed how I thought about the product.

The opportunity is not to put a chatbot on top of a shopping app. It is to use AI to understand intent well enough that parts of the shopping app no longer need to exist.

That is also what I found most interesting about the Visa challenge. Reimagining shopping does not necessarily mean creating another storefront. It can mean changing the interface between a person and commerce entirely.

What's next for Senta Checkout

The next step is making the ordering flow reliable across a much wider set of restaurants, menu structures, and ways people phrase requests.

I want to make corrections and order changes feel even more natural, improve recovery when external providers fail, support more fulfillment options, and reduce the amount of back-and-forth needed before someone can pay.

Food is a good place to start because the workflow is complicated enough to stress the system while still being something people understand immediately.

Longer term, the idea goes beyond food.

A lot of online shopping still assumes the customer should search through the structure of a marketplace themselves. I think there are a lot of cases where the user should be able to describe the outcome they want and let software handle the searching, configuration, and checkout underneath.

For me, Senta Checkout is the first step toward testing what shopping looks like when AI understands the intent and the conversation itself becomes the storefront.

Built With

Share this project:

Updates

Submission history