B2B ecommerce: Customer pricing, payment terms and repeat orders
A trade customer emails a spreadsheet, a salesperson looks up their agreed prices, and accounts checks whether they can buy on credit. The same work happens again next week. A B2B store can shorten that process when your trading rules are built into ordering. A company registration form and a catalogue-wide discount are only the beginning.

01Start with the rules for actual customers
Choose a few representative customers and document how they buy today. Include a small business using standard prices, a customer with negotiated rates and a company with several branches. For each, record the product range, pricing, payment method, delivery addresses and people allowed to order.
This gives you a basis for deciding what the portal must support at launch. Separate rules essential to accepting an order from convenience features that can follow later. Give suppliers anonymised examples of orders and price lists, rather than just a list of feature names.
02Define which price takes precedence and when it applies
“Every customer has their own price” could mean a fixed product price, a discount from a base list or a quantity discount. Decide what happens when rules overlap. Does a contract price override a promotion? Are discounts combined? Which price applies after the buyer switches branch?
Shopify, for example, uses B2B catalogues to control products and prices. Catalogue limits and assignment to companies or locations depend on the plan. A platform's B2B label alone does not establish that it supports your pricing exceptions.
Specify currency, price validity, selling unit, minimum quantities and pack multiples. Decide how tax and delivery charges are displayed, confirming the configuration with your accountant for the markets served. A missing negotiated price should not silently become an arbitrary public price.
Ask for an explainable result: support staff should be able to identify the rule behind a price. When a buyer opens an old basket, the system should either honour a still-valid offer or recalculate and highlight the change before confirmation, according to your agreed policy.
03Separate payment terms from permission to buy on credit
Define who qualifies for deferred payment, who approves it and what starts the payment period. Order date, invoice date and delivery date can produce different outcomes. If branches have different agreed terms, the store needs to apply the right ones.
Shopify's documentation distinguishes several payment-term types and notes that reaching the due date does not automatically collect payment. Describe the due-date calculation, receipt of payment and overdue-order checks as separate requirements.
If you use a credit limit, meaning the maximum approved outstanding amount, define its calculation. Does it include accepted orders that have not yet been invoiced? What happens when today's payment has not reached the accounting system? Holding the order for review or offering payment in advance may be practical options. An authorised person should approve any override, with a record retained.
04A company account is not a single user
Separate the customer organisation from the individual people logging in. A shared password makes it harder to identify who placed an order and to remove access when somebody leaves. The following roles are a suggested starting point, not a mandatory structure.
| Role | Typical task | Decision required |
|---|---|---|
| Buyer | Prepares a branch order | Can they submit it without approval? |
| Approver | Reviews selected purchases | When is approval required, and who provides cover? |
| Customer's accounts user | Finds invoices and payments | Do they also need permission to order? |
| Company account administrator | Manages users and branches | Who can change this person's permissions? |
Adobe Commerce documents separate company permissions for purchasing, order visibility, user management and approvals. Ask for a demonstration of the roles you need, including boundaries between customers and branches.
05A repeat order should prepare a new purchase for review
For regular buyers, consider ordering by product code, saved list or previous order. For example, Adobe Commerce provides reusable requisition lists from which buyers add items to their basket.
Reordering should not blindly copy historical terms. Before confirmation, check current availability, pricing under valid agreements, pack sizes and the buyer's permissions. Highlight discontinued products and offer any replacement for approval. Do not silently omit the item.
Consider an illustrative monthly branch order. One product now comes in a different pack size and another is out of stock. The portal prepares the rest of the basket, clearly identifies both changes and lets the buyer decide. They avoid searching the entire range again while retaining visibility of changes to the delivery.

06Check the connection to stock and accounting
Identify the authoritative data source for prices, availability, customer terms and invoices. Your internal system integration brief should cover data age and outages. If a price or credit limit cannot be confirmed, decide whether the request waits for manual review. Make the distinction between a received request and a confirmed order clear to the customer.
Build the pilot around specific scenarios: switching branch, overlapping price lists, an expired quote, an exceeded credit limit, an absent approver, an unavailable item and a lost connection. Check that a user from one company cannot retrieve another company's prices or invoices. Follow the purchase through to internal processing.

07Common questions when choosing a solution
Does a B2B store have to be bespoke?
No. An existing platform is a sensible choice when configuration or maintainable extensions support your rules. Compare licensing, implementation, connections, updates and manual exception handling. Consider a custom online store where important rules repeatedly conflict with a standard solution.
What should we bring to the first supplier meeting?
An anonymised price list containing real exceptions, a routine order and a problematic one, a role outline and a list of current systems. Name the person who currently decides each exception. These materials help establish whether an existing platform fits and which changes would be required.
Tell us how your wholesale ordering works. We can discuss what the first portal release should take over and which decisions need settling before screen design begins.