The purchase happened. The conversation kept going.

The order number came back. Then the shopper asked:

Thanks. When will it ship?

Juniper answered, right there in the same conversation that had helped them choose what to buy.

I got Stripe checkout working in my Salesforce Storefront Next build, including inside Juniper, the Claude-powered shopping concierge in Après Studio. Plenty of technical work in that sentence. But the bit I keep thinking about happened after checkout was done.

The purchase happened. The conversation just kept going.

The shopper had already told the store what they were trying to do. They had worked through the products, made a decision and paid. Why should that experience end because an order number now exists?

These screenshots are from a September 7 sandbox run using Stripe test payments. The order was a sandbox order, and the shipping answer came from the demo store’s policy, not live tracking. This shows a working experience. It doesn’t give me a conversion-lift number.

The shopper has already done some work

The conversation started with:

Dress me for a twenty-degree morning on the hill.

That is a much more normal thing to say than narrating your way through a retailer’s category tree. There is a person with a day in mind, trying to work out what they need for it.

Juniper put together a layering plan from the Après Studio catalog. When asked to add the first piece in a medium, she asked which colour. Black. The base layer went into the bag.

Then: “I’m ready to pay.”

By then, the shopper has done more than put something in a cart. They’ve explained the situation, considered a recommendation and settled a couple of choices. There is useful context in that conversation.

If the next step sends them somewhere that leaves that help behind, we’re asking them to carry the experience across the gap themselves. The bag may come along. The ability to ask another question, check a choice or resolve a doubt should come along too.

That’s the retailer question for me. Can we make it easier for someone who wants to buy to actually finish buying?

I want to keep the products, the decision and the checkout together. A separate checkout page can be the right choice. I just don’t think leaving the conversation should be the default requirement for completing the purchase.

Native Stripe checkout in Storefront Next

If you read my earlier note on Claude-first commerce, Juniper could already help someone find products and build a bag. This takes that experience through to an order.

The Stripe integration works in the storefront’s regular checkout and in Juniper’s panel. By native, I mean payment is integrated into the retailer’s own checkout experience. This is the integration I built for Après Studio, not a claim that Stripe is the default payment provider in Storefront Next.

Someone who knows exactly what they want can use the normal product, bag and checkout pages. Someone shopping with Juniper can finish there. Both routes use the same underlying commerce platform; neither requires the shopper to become an AI enthusiast to buy a base layer.

Checkout opens in her panel, with the bag and the familiar contact, delivery and payment steps. The shopper fills in the details, reviews the purchase and explicitly taps Pay. The full checkout page is still available for someone who prefers it.

Nobody needs to conduct a conversation with a credit-card field. Those are still proper payment fields, using Stripe’s payment interface. Card details never belong in a chat message.

The demonstrated card flow stays in the experience. A payment method that requires bank authentication can still involve a handoff. Keeping checkout close should not mean pretending those requirements disappear.

Here are the actual screens. Scroll across the sequence or open a frame for a larger view. The amounts and order number belong to this sandbox demonstration.

Juniper can open checkout. She cannot decide to spend the shopper’s money. Claude, from Anthropic, handles the conversation. Salesforce B2C Commerce owns the basket and order, and Stripe handles payment authorization. Putting them in one experience doesn’t hand the purchasing decision to the model.

The production work still matters: reliable payment and order handling, recovery when something fails, and the merchant’s downstream payment collection and fulfilment processes. Those need to be integrated and validated before a retailer puts this in front of customers.

An order number isn’t the end of the customer’s question

“When will it ship?” is such an ordinary next thing to ask. That’s why I like this moment.

The shopper didn’t have to start another chat, explain what they’d just bought or go looking for a shipping-policy page. The order was acknowledged and the next question happened in place.

For a retailer, that raises a useful possibility: the help that made the purchase possible could remain useful after the purchase. A question about delivery doesn’t become a completely separate experience simply because it now belongs to a different team inside the business.

There are limits to what this demonstration proves. Explaining a shipping policy isn’t the same as knowing where a particular parcel is. An answer about an actual order needs the retailer’s actual order data. I’d rather have Juniper say she doesn’t know than invent a reassuring delivery date.

But the continuity is there to build on. The customer can finish buying without losing the place where they’ve been getting help.

What I want to prove with a retailer

My hypothesis is straightforward: keeping useful shopping context through checkout can remove some of the interruptions and unresolved questions that get between a decision and a completed purchase.

I want to find out whether more shoppers finish the purchase, and whether they find it easier to do so. Those are the outcomes. Time spent talking to Juniper is not the business case.

I’d test it against the retailer’s existing experience with comparable shoppers and shopping tasks. Measure completed purchases and where people abandon checkout. Watch for repeated steps, confusion about payment and requests for help. Then follow what happens after the order: did the shopper get a useful answer, or did we simply create another reason to contact support?

More completed orders wouldn’t be much of a win if people were buying the wrong thing or misunderstanding what they’d agreed to. I’d want to watch corrections, cancellations and returns too.

I don’t know those results yet. That’s the point of testing this with a retailer’s products, customers and operating reality. A successful sandbox order gives us something real to test; it doesn’t settle the argument.

And keep the regular storefront. Sometimes I know exactly what I want and would rather click the thing. People should be able to move between browsing and conversation without losing the work they’ve already done.

That’s what I’m exploring in Après Studio. The related merchant-agent work brings storefront marketing and merchandising into Slack, where the team decides what shoppers will see. If you have a place where shoppers get stuck between choosing and buying, I’d like to look at it with you.

They’ve already told the store what they’re trying to do. I’d like the store to stay with them while they do it.