The Guide to Commerce Banking
A practical guide to building the commerce layer for modern merchants.
Table of Contents[ 12 ]
What is commerce banking? Why the merchant relationship is changing The commerce layer The four commerce surfaces Why banks are positioned to provide this What the institution can provide Architecture Build vs buy What good commerce infrastructure looks like Measuring success Where Box fits The opportunityA merchant’s relationship with a financial institution traditionally begins and ends with the account.
But the merchant’s business does not happen inside the account. It happens across websites, checkout, payments, point-of-sale systems, customer management, orders and other operational tools.
Commerce banking is the idea of bringing those two worlds closer together. Instead of treating banking and commerce as separate systems, institutions can provide infrastructure that allows merchants to operate their businesses alongside their financial relationship.
This guide explains what that means, why it matters and what an institution needs to build it.
What is commerce banking?
Commerce banking is the extension of a financial institution’s infrastructure into the operational layer of merchant commerce.
Traditional banking might provide accounts, payments, cards, transfers, lending and savings. Commerce banking adds infrastructure for products, websites, checkout, orders, customers, point of sale, payment links and commerce analytics.
The goal isn’t to turn a bank into a marketplace. The goal is to allow the institution to provide infrastructure around the merchant’s business.
Why the merchant relationship is changing
A merchant no longer interacts with a bank only through financial transactions. Their business generates activity across many systems.
Consider a simple sale:
A traditional banking infrastructure may only see the payment and the settlement. A commerce infrastructure layer can understand the entire transaction lifecycle.
That difference creates a much richer merchant relationship.
The commerce layer
A commerce platform can be thought of as a set of interconnected primitives.
- Products. What the merchant sells.
- Customers. Who the merchant sells to.
- Orders. What customers purchase.
- Payments. How customers pay.
- Transactions. What actually happened financially.
- Inventory. What is available.
- Commerce surfaces. Where the transaction happens.
The power comes from connecting these primitives.
A payment shouldn’t exist independently from the order. An order shouldn’t exist independently from the customer. A website shouldn’t need its own isolated product catalogue. A point-of-sale transaction shouldn’t become a completely separate merchant record.
One commerce system can connect them.
The four commerce surfaces
A modern commerce infrastructure should support multiple ways of selling.
- Online. The merchant gets a website and checkout.
- In person. The merchant can use point of sale and physical payment infrastructure.
- Payment links. The merchant can create a direct path from conversation to payment.
- Embedded commerce. The institution can expose commerce inside an existing application or product.
The surface changes. The underlying merchant and commerce data remain connected.
Why banks are positioned to provide this
Banks already have several critical advantages.
- Distribution. The merchants already exist inside the institution’s customer base.
- Trust. The institution already has an established financial relationship.
- Financial infrastructure. Accounts, payments and settlement already exist.
- Merchant data. The institution already sees meaningful financial activity.
- Capital. Banks can connect commerce activity to financial products.
The missing component is often the operational commerce layer.
What the institution can provide
A commerce banking platform can start small. An institution might begin with a website and checkout, then expand into orders and customers, then point of sale and payment links, then analytics, loyalty, subscriptions and other commerce services.
Website + checkout → Orders + customers → Point of sale + links → Analytics, loyalty, subscriptions
The important architectural decision is to make these capabilities work together from the beginning.
Architecture
A typical architecture looks like this:
The institution’s existing financial infrastructure remains important. Commerce infrastructure sits alongside it and connects the two worlds.
Build vs buy
Institutions have three broad options.
- Build everything. Maximum control, maximum engineering burden.
- Buy a complete commerce platform. Faster initial deployment, less control over architecture and experience.
- Use composable infrastructure. The institution gets reusable commerce primitives and composes the experience it needs.
Build
- Maximum control
- Maximum engineering burden
- The infrastructure is the real project
Buy
- Fastest start
- Least control
- You inherit their data model
Compose
- Infrastructure and control
- Faster path to production
- Room for what you build next
This third model is particularly useful when commerce is becoming a strategic part of the institution’s product infrastructure. There is a fuller treatment in Build vs Buy.
What good commerce infrastructure looks like
A serious commerce infrastructure platform should be:
- Composable. Capabilities can be assembled rather than accepted as one fixed application.
- Extensible. Developers can build beyond the default experience.
- Self-hostable. Institutions can control the deployment environment.
- Multi-surface. Online and physical commerce share the same underlying system.
- API-first. Commerce primitives are accessible programmatically.
- Upgradeable. The infrastructure can evolve without forcing institutions to rebuild.
- Institution-ready. The system can fit into existing identity, payments, security and infrastructure environments.
Measuring success
Commerce banking should not only be measured through product adoption. Measure the relationship.
- Merchant activation. How quickly does a merchant complete their first transaction?
- Commerce volume. How much commerce is flowing through the platform?
- Merchant retention. Do merchants continue using the institution’s commerce infrastructure?
- Product expansion. How many commerce capabilities does each merchant adopt?
- Financial expansion. Does commerce activity lead to greater adoption of financial products?
- Merchant value. Does the institution become more valuable to the businesses it serves?
The ultimate goal is not another feature. It is a deeper merchant relationship.
Where Box fits
Box provides the infrastructure layer institutions can use to build this model.
The institution provides the brand, the merchant relationship, the financial rails and the commerce experience. Box provides the commerce infrastructure underneath.
That can mean a complete merchant platform, embedded commerce or API-level infrastructure. The institution decides how much of the experience it wants to own, which is the subject of Choosing Your Commerce Architecture.
The opportunity
The merchant already has a business. The institution already has the merchant. The missing connection is infrastructure.
Commerce banking closes that gap.
The next generation of financial institutions won’t only help businesses manage money. They will provide more of the infrastructure businesses use to create it.