Choosing Your Commerce Architecture

Institutions don’t all need the same architecture. The question is how much of the merchant experience the institution wants to own, and how much existing system it needs to preserve.

There are four workable answers.

Full platform

Use the commerce engine, merchant console, website and retail infrastructure together.

Best when speed matters, a complete merchant experience is required, and the institution wants a ready commerce foundation.

Embedded commerce

Use commerce infrastructure inside an existing product.

Best when the institution already has a strong application, commerce should feel native, and the merchant experience needs to remain inside the institution’s product.

API infrastructure

Use commerce primitives directly.

Best when engineering teams want complete control, the institution is building custom experiences, and commerce needs to become infrastructure underneath several products.

Hybrid

Use some Box surfaces and build others. For example:

Box engine → Custom website → Box point of sale

This is often the most practical architecture for institutions with existing systems.

How to choose

The deciding factor is usually not technical capability, it is what already exists. An institution with no merchant-facing application should start with the full platform. An institution with a well-adopted business banking app should embed. An institution with a platform team and a strong opinion about the experience should take the API.

All four use the same engine underneath, so the decision is reversible in one direction: starting with the full platform and later replacing a surface is straightforward. Starting with the API and later adopting the console is also fine. What is expensive is building on a system that only supports one of these shapes.