PromptZone - AI Prompts, Guides and Tools for Builders: Steve Jonas

Agentic Checkout on BigCommerce: ACP, UCP and What Developers Should Prepare

Steve Jonas — Fri, 16 Oct 2026 06:55:14 +0000

AI agents can now find a product and complete the purchase on a shopper's behalf. Checkout is no longer always a page a human clicks through.
Two open standards lead this space: the Agentic Commerce Protocol (ACP) from OpenAI and Stripe, and the Universal Commerce Protocol (UCP) from Google and Shopify.
BigCommerce has endorsed UCP and announced agentic features, but support is still rolling out. Developers should prepare their data, checkout rules, and order flow now, and confirm exact platform support in current documentation.

Why This Matters for Store Owners

A few years ago, checkout was the last page a shopper saw. Today, a shopper can ask an assistant to buy a product, and the assistant handles the steps. The store still receives the order, but the person never opened the cart page.

This changes what a good store needs. Teams that invest in BigCommerce development services have usually focused on page speed, theme design, and conversion rate. Those still matter. Now, the checkout also has to work for software that reads rules, not for a person who reads buttons.

This article explains how agentic checkout works, how the two main protocols differ, and what a developer can do today.

What Agentic Checkout Means in Practice

Agentic checkout means an AI agent completes part or all of a purchase for a shopper. The shopper gives permission and sets limits, such as a maximum price. The agent does the rest.

Here is a simple version of the flow.

The shopper asks. For example, "Order a black 30-liter backpack under $120."
The agent searches. It reads product feeds and catalog data from many stores.
The agent compares. It checks price, stock, delivery time, and return terms.
The agent builds the order. It creates a cart with the right variant and quantity.
The shopper approves payment. A saved wallet or payment method completes the step, often with one confirmation.
The store receives the order. It then handles fulfillment, notifications, and returns as usual.

Steps 2 to 4 are where most stores fail today. If the agent cannot read the data or build a valid cart, it moves on to another store.

The Two Protocols to Know

Agents need a shared language to talk to stores. Two open standards compete to provide it.

ACP (Agentic Commerce Protocol) was introduced by OpenAI and Stripe in September 2025. It powers Instant Checkout in ChatGPT. Merchants that already use Stripe for payments have a short path to support it.

UCP (Universal Commerce Protocol) was unveiled by Google at the NRF conference in January 2026. It was developed with Shopify and other retailers, and it is endorsed by more than twenty companies across payments and retail. Google plans to use it for eligible listings in AI Mode and Gemini, with purchases paid through Google Pay.

Aspect	ACP	UCP
Led by	OpenAI and Stripe	Google and Shopify, with a wider coalition
Introduced	September 2025	January 2026
First major surface	ChatGPT Instant Checkout	Google AI Mode and Gemini
Payment link	Closely tied to Stripe	Works with several payment providers
Openness	Open source	Open source, designed to be vendor neutral

Neither one has won yet. Many large payment companies support both, so a store that prepares well for one will find the other easier to add.

Where BigCommerce Fits

BigCommerce's parent company, Commerce, endorsed UCP when it launched in January 2026. It has also announced work with Stripe's Agentic Commerce Suite, which is built around ACP. At Commerce Live 2026, the company put agentic commerce at the center of its roadmap and announced features for discovery, search, checkout, and daily store operations.

This is encouraging, but the details matter. Announcements are not the same as general availability. Some features may be in beta, limited to certain regions, or tied to specific payment providers. Before you plan a launch, check the current BigCommerce developer documentation and ask your account contact which features are live for your store.

What a Developer Needs to Prepare

You do not need to wait for every feature to be final. Most of the groundwork is useful anyway.

Catalog data an agent can trust

An agent cannot buy what it cannot understand. Clean identifiers, structured attributes, accurate variants, and current stock are the base. If your catalog is messy, fix that first, since every other step depends on it.

Checkout rules that are explicit

A human can handle a vague rule such as "ships to most countries." An agent cannot. Write down your shipping zones, delivery times, tax rules, and return terms in a clear form. Make sure they match what your checkout really does, because any mismatch will cause failed or disputed orders.

Payments that support delegated purchases

Agentic payments often use tokens, wallets, or saved credentials that the shopper has approved in advance. Confirm that your payment provider supports these flows. Check also how your system handles declined payments, partial approvals, and fraud checks when no human is on the page.

A reliable order and inventory flow

Orders from agents arrive fast and in patterns that differ from human traffic. Stock must update quickly so you do not oversell, and order data must reach your warehouse or ERP without delay. Review your integrations for rate limits and retry logic.

Connecting AI systems safely

Some stores will want to build their own assistants or connect to external agents through APIs. This is where AI integration services can help, since the work involves secure API access, permission rules, and clear limits on what an agent may do. Start with read-only access, then move to ordering features once you trust the setup.

Monitoring and logs

Add tracking that separates agent-driven orders from regular ones. You will want to know conversion rates, refund rates, and error types for each group. Without this view, problems stay hidden inside your totals.

Questions Teams Often Ask

Do we need to support both ACP and UCP?
Not on day one. Start with the channels that matter most to your customers, and build a clean data and checkout foundation that works for either standard.

Will agentic checkout replace our website?
No. It adds a new channel next to your store. Many shoppers will still browse and buy directly, and your site remains the place where your brand is fully expressed.

Who is responsible when an agent makes a wrong purchase?
This is still being worked out across the industry. Make your return and refund terms clear, keep good order records, and follow guidance from your payment provider.

Is our current checkout good enough?
Test it. Try to complete a purchase using only structured data, with no visual cues. If key details are missing or unclear, an agent will struggle in the same way.

How should we start?
Run a small pilot. Pick one product category, clean its data fully, enable the available agentic features, and measure results for a few weeks before expanding.

The Bottom Line

Agentic checkout is early, but the direction is clear. Shoppers will delegate more buying to AI, and stores that give clear, accurate, machine-readable information will get more of that demand. The protocols may change and the platforms will keep updating, yet good data, explicit rules, and reliable order flow will stay valuable in every version of this future.

Emizentech works with merchants on API-first BigCommerce builds, and its engineers can help map your catalog, checkout, and integrations to what agent-driven channels will need. A short technical review is often enough to show which gaps to close first.

Building a Remote-First Engineering Culture That Lasts

Steve Jonas — Thu, 15 Oct 2026 05:43:14 +0000

Here is a paragraph from a real kind of document, the sort a distributed team writes once and revises every few months:

"We answer messages within one working day. We write down decisions so nobody has to ask twice. We don't expect replies outside your working hours. If something is on fire, we call."

Four sentences, and they say more about how that team lives than any slogan on a wall. Remote-first culture isn't a perk or a mood. It is a set of small, repeatable agreements that make good work possible when nobody shares a room.

Culture Without an Office: What Actually Changes

In an office, culture leaks in through the walls. New people learn by watching who speaks up in meetings, who stays late, and who gets thanked. Nobody has to write any of it down.

Remove the building and that leakage stops. What remains is only what you deliberately say and do. A remote team has the culture it writes down and practises, and nothing more.

That sounds like a loss, but it can be an advantage. Because nothing happens by accident, a remote-first team gets to decide on purpose how decisions are made, how people disagree, and what good work looks like. The teams that struggle are usually the ones that moved online and kept hoping the old habits would survive the trip.

Remote-first also differs from "remote-friendly". A remote-friendly company has an office and tolerates people who aren't in it. A remote-first company designs every process, from meetings to promotions, as though nobody were in the room. That choice is what stops people at headquarters from becoming the real team while everyone else becomes an afterthought.

Trust as the Default Setting

Everything else in a distributed team rests on one assumption: people are doing their best work when you can't see them. If leaders don't believe that, no tool or ritual will repair it. Constant check-ins and activity trackers tell people they are suspected, and capable engineers leave suspicious teams quickly.

Trust starts before the first day, with the people you bring in. When a team sets out to hire dedicated remote developer talent for the long haul, ownership is the quality that matters most: someone who raises a risk early, asks a sharp question instead of guessing, and finishes what they start without being chased.

After that, trust is kept alive by how work is judged. Measure outcomes, not hours online. A developer who ships a clean, well-tested feature on Thursday has done the job, whether they were logged in for six hours or ten. Managers who grade presence get presence, and presence is not the same thing as progress.

Trust also needs a safe way to fail. If the first time someone admits a mistake is the last time they do it, mistakes go underground. Short, blame-free reviews after incidents, focused on what the system allowed and not on who slipped, teach a team that honesty is cheaper than hiding.

Write Down How You Work Together

Unwritten rules are the main source of friction in distributed teams, because people fill the gaps with their own assumptions. A short working agreement, often called a team user manual, replaces guesswork with something everyone can read.

A useful one covers a handful of topics:

Working hours and overlap. When people are expected to be reachable, and when they are not.
Response times. What counts as a normal message, and what counts as urgent.
Where things live. Which tool holds decisions, tickets, documents, and casual chat.
How decisions are made. Who decides, who is consulted, and how disagreements are resolved.
How to give feedback. Direct, private for criticism, public for praise.
How to ask for help. What a good question looks like, and that asking is expected.

Keep it to one or two pages. A manual nobody reads is worse than none, because it creates the feeling of a policy without the benefit. Let the team write it together, so it describes how people want to work and not how a manager imagines they do.

Review it every quarter and change whatever isn't working. A living document does more for culture than a polished one that never changes.

Rituals That Replace the Hallway

Offices produce a lot of accidental contact: a chat at the coffee machine, an overheard conversation, a quick walk to lunch. Much of what looks like small talk carries real information and builds the ease that makes hard conversations possible later.

Remote teams have to create that contact deliberately, but it doesn't need to be forced or cheesy. A few rituals tend to work well:

A weekly written update. Each person shares what they finished, what is next, and what is blocking them. It takes five minutes and replaces a long status meeting.
A regular demo. Short, informal show-and-tell of work in progress. It gives people credit and keeps everyone aware of the whole product.
Pairing sessions. Two people working on a hard problem together, which teaches skills and builds familiarity faster than any chat channel.
Optional social time. A video lunch, a games hour, or an open channel for hobbies. Make it genuinely optional, and nobody should be penalised for skipping.
A yearly in-person gathering, where the budget allows. Even a few days together can strengthen bonds for months afterwards.

Beware of ritual overload. Too many mandatory events recreate the meeting-heavy office you were trying to leave. Fewer, better rituals, run consistently, beat a packed calendar.

The First 90 Days of a New Team Member

How a person is welcomed decides how quickly they become effective and whether they stay. In a remote team, a new hire can spend days without a single human interaction unless someone plans otherwise.

A simple 90-day shape helps:

Days 1 to 30: Orientation. Set up accounts and tools before day one. Assign a buddy who answers questions without judgement. Give a small, real first task that ships quickly, so the person feels useful in the first week. Share the user manual and the architecture overview.

Days 31 to 60: Contribution. Increase the scope of tasks. Introduce the person to the people they will work with most. Hold a short check-in every week, asking what is unclear and what could be easier.

Days 61 to 90: Ownership. Hand over an area or feature to own. Ask for honest feedback on the onboarding itself, then use it to improve the process for the next person.

Onboarding stumbles often trace back to ownership, communication, and unclear expectations, the same issues covered in the challenges of hiring dedicated developers, so it helps to review them before the next person joins.

Leadership, Recognition and Growth

Remote culture is mostly shaped by what leaders do repeatedly. If they write things down, others will. If they reply thoughtfully and on time, the team learns that replies matter. If they only ever message people to chase tasks, that becomes the culture.

Three leadership habits make a visible difference. First, be explicit about priorities, because people who can't walk over and ask need clear direction. Second, share context generously, including the reasons behind decisions and the state of the business. Third, hold regular one-to-one conversations that cover growth and wellbeing as well as tasks.

Smaller companies often lack this kind of senior technical leadership, and some bring in a part-time executive, such as a fractional CTO, to set engineering direction and coach team leads without hiring a full-time role.

Recognition needs deliberate effort too. Work that happens quietly on a screen goes unnoticed unless someone says so. Praise specific contributions in public channels, mention names in updates, and make sure promotions and raises follow the same visible, fair criteria for everyone, regardless of time zone.

Growth is the final piece. Remote engineers should have a clear route to learn and advance, through mentoring, a learning budget, and chances to lead projects. People stay where they can see a future.

Signs the Culture Is Holding, and Signs It Is Slipping

Culture is hard to measure directly, but certain signals show up reliably.

Area	Healthy sign	Warning sign
Communication	Questions get answered once, in writing	The same questions repeat in private messages
Trust	People admit mistakes and ask for help early	Problems surface only when deadlines are missed
Participation	Quiet team members contribute in writing	Only the loudest voices on calls shape decisions
Workload	People take breaks and honour their hours	Messages arrive late at night and get answered immediately
Belonging	New joiners are productive and connected within weeks	New joiners feel isolated and leave in the first year
Decisions	Anyone can find out why something was decided	Decisions live in memory and in meetings nobody recorded

Check these every quarter with a short, anonymous survey and a few honest conversations. Act on what you hear, and tell the team what changed as a result, because people stop answering surveys that go nowhere.

Conclusion

A remote-first engineering culture lasts when it is built on trust, written agreements, a few well-chosen rituals, careful onboarding, and leaders who model the behaviour they want. It does not depend on perks or clever tools. It depends on small habits repeated until they become normal, and on a willingness to revisit them when they stop working.

EmizenTech, a mobile app development company, works with distributed teams across time zones, and relies on written working agreements and regular check-ins to keep those teams connected.