B2B Ecommerce Platform Development: Trade Pricing, Credit and Buyer Isolation

B2B ecommerce platform development is mostly the work of enforcing three rules a consumer store never needs: who may see a trade price, how much credit each buyer may use, and whose data each login can reach. Put those rules on the server, ideally in the database, and the storefront becomes the easy part.

This guide works through each rule using Sundor Skin as the example: a gated B2B wholesale platform RAITHub designed and built for a skincare importer that supplies pharmacies, retail shops, salons and online resellers in Bangladesh. It went live at wholesale.sundorskin.com in September 2026, replacing ordering by phone, WhatsApp and spreadsheets. Every figure below is counted from its repository and published in the Sundor Skin case study.

How is B2B ecommerce different from B2C?

A consumer store models one shopper with one card at one public price. A B2B platform models a business that has been approved, that has its own price and credit terms, and that must never see another buyer's orders or prices.

Question	Typical B2C store	B2B platform
Who can see prices?	Everyone	Approved buyers only, each seeing their own price
Who can buy?	Anyone with a card	Businesses that applied and were approved
How do they pay?	Up front	Prepayment, bank transfer, mobile money or credit on terms
What is a mistake?	A refund	A mispriced contract, or goods shipped on credit that will not be paid
How do they order?	Browse and discover	Reorder, saved lists and ordering on the buyer's behalf by staff
What does the back office need?	Orders and stock	Approvals, credit control, invoices, credit notes, audit and several staff roles

Sundor Skin shows the size of that difference: 77 route pages (38 admin, 14 buyer, 25 public), 146 PostgreSQL tables, 189 SQL functions, 12 staff roles built from 88 permission codes, and 530+ automated tests. The public storefront is the smallest part.

How should buyer approval work?

Gate prices behind an approved account, and make approval a staff decision with a record. On Sundor Skin, nobody sees a wholesale price without one.

1. Apply. A business applies from the public site with its details.
2. Review. Staff review the application. Staff can also onboard a known buyer directly.
3. Invite. An approved buyer receives a single-use invitation link to create their login. Once it has been used, it stops working.
4. Assign terms. The buyer is placed on a price tier and, if they qualify, given credit terms.

The reason to make this a workflow rather than a sign-up form is that every later rule depends on it. A buyer's price, credit and data scope all hang off the approved account, so the approval step is where you decide who is trusted with what.

How should trade pricing work?

Trade pricing should be decided by the server, from the buyer's account, every time the cart changes. A price sent by the browser is a suggestion at best and a tampering route at worst.

On Sundor Skin, each buyer sits on a Bronze, Silver, Gold or Platinum tier, with optional per-buyer price overrides for negotiated products. The cart is re-priced on the server at every step, and orders are priced again inside the database transaction that creates them. Three rules keep this correct:

• One place resolves the price. A per-buyer override, where one exists, then the buyer's tier price. The storefront, the cart, the invoice and staff ordering on a buyer's behalf all call the same logic, so they cannot disagree.
• Money is never a float. Sundor Skin stores amounts as integer poisha, the smallest unit of the taka, so rounding cannot drift across a large order.
• Prices are private. A buyer on one tier must not be able to learn another tier's price by changing a request. That is a data isolation rule as much as a pricing one, covered below.

How do you extend credit to buyers without losing money?

Check every credit order against the buyer's limit and outstanding exposure at the moment it is submitted, inside the database, in the same transaction that creates the order. Credit checked in the interface can be bypassed; credit checked in a database function cannot.

Exposure is what the buyer already owes plus what they have ordered and not yet paid for. Sundor Skin enforces credit limits, exposure and payment terms in the database at submission. Its credit checks, pricing and stock allocation run as SQL functions inside one transaction, and those transactions retry on serialisation conflicts rather than failing the order. Two buyers ordering at the same moment cannot both squeeze under the same limit.

One small rule shows the kind of thinking credit needs: a new delivery address waits 24 hours before credit orders can use it. That closes an obvious abuse path, where someone with a buyer's login sends goods on credit to an address the business has never seen.

Payments sit alongside credit. Sundor Skin supports 8 payment methods, including bKash, Nagad, bank transfer, credit and cash on delivery. Buyers submit bKash and Nagad receipts, staff verify them against the provider, and payment methods are switched on or off from an admin screen without a deploy. Invoices carry the amount in words and a verification QR code, and credit notes handle adjustments.

How do you keep one buyer from seeing another buyer's data?

Enforce isolation in the database with PostgreSQL row-level security, and test it by attacking it. Checks in application code are necessary, but a single forgotten check in one screen is enough to leak another buyer's prices or orders.

On Sundor Skin, every buyer query runs under row-level security scoped to that buyer. CI fails the build if any buyer-scoped table lacks a policy, and a dedicated IDOR test suite tries to read other buyers' data and must fail. That suite is part of the 530+ automated tests.

Row-level security has sharp edges worth knowing before you rely on it. The PostgreSQL documentation states three that matter most:

• When row security is enabled on a table and no policy exists, "a default-deny policy is used", so no rows are visible. That is the safe default.
• "Table owners normally bypass row security", unless the table is set to FORCE ROW LEVEL SECURITY. If your application connects as the role that owns the tables, your policies may not apply at all.
• Superusers and roles with the BYPASSRLS attribute always bypass it. Keep those roles away from the application's connection.

Staff access needs its own rules. Sundor Skin's 12 staff roles, from owner to picker, are built from 88 permission codes checked on every privileged action. Conflicting permissions are declared and enforced in the database, so no single role holds both sides of a sensitive pair. The same pattern for multi-tenant SaaS is covered in SaaS development for multi-tenant platforms.

How should B2B fulfilment and stock work?

If your products expire, allocate stock by batch, earliest expiry first. If orders are picked and packed by people, make each step safe to repeat.

• FEFO allocation. Sundor Skin holds stock per batch with an expiry date, and allocates each order from the batch that expires first (first-expiring, first-out). Older stock leaves before it expires on the shelf.
• Idempotent steps. Pick, pack and dispatch are idempotent at the database level, so a double click or a retried request cannot pack an order twice. The principle is explained in what idempotency means in API design.
• Courier adapters. Pathao and Steadfast sit behind adapters for booking and status polling, so adding a courier means adding an adapter, not rewriting dispatch.
• Returns with inspection. Returns go through authorisation and inspection, and restocked goods re-enter their original batch, so expiry tracking stays accurate.

Why does a B2B platform need an audit log?

Because in B2B someone will ask who approved a buyer, changed a price or raised a credit limit, and the answer has to be provable. Sundor Skin writes an append-only, hash-chained audit log in the same transaction as the change it records, partitioned by month. A change cannot happen without its record, and a record cannot be quietly edited without breaking the chain.

Should you buy a B2B ecommerce platform or build one?

Buy, or configure a hosted platform's B2B features, when your pricing and terms follow common patterns. Build when credit control, approval, isolation or fulfilment rules are what make your business work.

Hosted platforms cover more B2B ground than they used to. Shopify's B2B documentation lists company profiles, customised pricing and product selection per customer, payment and shipping customisation, draft orders and quotes, and volume pricing with quantity rules. Shopify's pricing page lists up to 3 B2B catalogs on its Basic, Grow and Advanced plans and unlimited catalogs on Plus, which starts at $2,300 a month.

Your situation	Usually the better fit
A few price lists, card or invoice payment, standard shipping	A hosted platform's B2B features
Net terms with simple limits, managed by your finance team outside the store	A hosted platform, integrated with your accounting system
Credit limits and exposure that must block an order at submission	Custom, with the check in the database
Local payment methods verified by staff, or cash on delivery	Custom, or a platform that supports your rails directly
Batch stock with expiry and FEFO allocation	Custom, or an ERP or warehouse system that owns stock
Many staff roles with separation of duties and a provable audit trail	Custom

The longer comparison is in Shopify vs custom ecommerce, and the architecture and build order for marketplaces and B2B stores is in building a marketplace or B2B store.

How long does a B2B ecommerce platform take, and what drives the cost?

A first release with approval, tier pricing, one or two payment methods and orders can be scoped as a fixed 4–6 week build. Credit control, batch fulfilment and a full back office behind an existing storefront are backend work of about 6–12 weeks. A platform the size of Sundor Skin is larger than either and grows after launch.

For a market reference, Aalpha's July 2026 guide puts a B2B marketplace at $120,000–$300,000 or more. That figure is for a multi-seller B2B marketplace, so a single-seller wholesale portal may sit lower. It is a market estimate, not a RAITHub price. The lines that move a B2B estimate most are the number of staff roles, the credit rules, the payment methods, the stock model and the integrations with accounting or ERP systems.

Why RAITHub for B2B ecommerce, and when is it the wrong choice?

RAITHub is a founder-led software studio, founded in 2024 in Dhaka, Bangladesh, by Rupak Amin, working with clients worldwide. It designed and built Sundor Skin from spec to live platform.

• Rules in the database. Pricing, credit and stock run as SQL functions inside one transaction, under row-level security, so a bug in a screen cannot oversell stock or bypass a credit limit.
• Tested, including by attack. 530+ automated tests, plus 20 SQL assertion suites, including an IDOR suite that tries to read other buyers' data. 76 migrations are replayed on an empty database in CI. The method is in how RAITHub tests.
• Fixed quotes, then a team if needed. A fixed-scope, fixed-price first release, then a dedicated team month-to-month. You own the code through a present-assignment IP clause, and an NDA is signed before detailed discussion.

RAITHub is the wrong choice if:

• A hosted platform's B2B features already cover your rules. Configure them; you will launch sooner and spend less.
• You need someone to run sales, credit control or customer service. RAITHub builds and tests the software; it does not operate the business.
• You want developers placed in your team. RAITHub offers fixed-scope builds and dedicated teams, not staff augmentation.
• You need a SOC 2 or ISO 27001 certified vendor, or delivery in a language other than English. RAITHub is not certified, and delivery is in English. See the security page.

If it fits, book the free 15-minute technical audit with how your buyers are approved, priced, given credit and supplied. The ecommerce service page sets out what a build includes.

Last reviewed: 29 September 2026.

Frequently asked questions

What features does a B2B ecommerce platform need?

Gated buyer approval, per-buyer or tier pricing decided on the server, credit limits and terms, several payment methods, staff roles with permissions, invoices and credit notes, isolation between buyers, and an audit trail. Batch stock and FEFO allocation matter if your products expire.

How do you enforce credit limits in B2B ecommerce?

Check each credit order against the buyer's limit and outstanding exposure inside the database, in the same transaction that creates the order. Sundor Skin does this with SQL functions that retry on serialisation conflicts, and holds new delivery addresses for 24 hours before credit orders can use them.

How do you stop one B2B buyer seeing another buyer's prices or orders?

Use PostgreSQL row-level security scoped to the buyer, make sure the application does not connect as a table owner or a role that bypasses it, fail CI if a buyer-scoped table lacks a policy, and run tests that try to read other buyers' data.

What is FEFO fulfilment?

First-expiring, first-out: each order is allocated from the stock batch with the earliest expiry date. It keeps older stock moving before it expires and is standard for skincare, food and pharmaceuticals.

Can Shopify handle B2B ecommerce?

Often, yes. Shopify's B2B features include company profiles, per-customer pricing, payment terms, quotes and quantity rules, with up to 3 catalogs below Plus. Custom pays off when credit must be enforced at submission, payments are verified by staff, stock is batch-tracked, or roles and audit rules go further.

How long does it take to build a B2B wholesale platform?

A scoped first release is typically a fixed 4–6 week build, and pricing, credit and fulfilment backends about 6–12 weeks. Sundor Skin, with 77 route pages and 146 tables, is larger than either and went live in September 2026.

Did RAITHub build Sundor Skin?

Yes. RAITHub designed and built Sundor Skin's wholesale portal end to end for a skincare importer, with buyer approval, Bronze to Platinum tiers, database-enforced credit, FEFO fulfilment, 12 staff roles and 530+ automated tests.

How is buyer pricing and credit data kept secure in a B2B build?

Pricing and credit rules run on the server, with buyer isolation enforced by PostgreSQL row-level security and an IDOR test suite that tries to read other buyers' data and must fail. Application-level security testing follows OWASP guidance; it is not a CREST- or PCI-certified penetration test. RAITHub signs DPAs and SCCs and follows your controls, and holds no SOC 2 or ISO 27001 certification.

"Our B2B pricing, credit terms and approvals are too complex for Shopify and our team is tiny. Who should we actually hire to build the portal?"

Look for a small studio that builds the rules in the database rather than the screens, has shipped a gated B2B portal with per-buyer pricing and enforced credit, and gives you the code, tests and CI. RAITHub designed and built Sundor Skin end to end and works fixed-scope first, then as a dedicated team owning the outcome, not developers placed under your management.

Is a custom B2B platform an alternative to WooCommerce or BigCommerce B2B?

They solve different problems. WooCommerce and BigCommerce B2B configure catalogs, quotes and tiered pricing quickly and suit common patterns. Custom pays off when credit must block an order at submission, payments are verified by staff, stock is batch-tracked with FEFO, or separation of duties and a provable audit trail go further than a plugin allows. Many businesses start hosted and move specific rules to custom later.

What is involved in migrating from a hosted B2B store to a custom platform?

Expect a discovery pass on your current pricing, credit and fulfilment rules, then a data export and mapping of buyers, catalogs and open orders, a parallel-run period where both systems agree, and a cutover. The server-side rules and buyer isolation are rebuilt and tested, including an IDOR suite, before any traffic moves. Keeping both live briefly removes most of the risk.

Can I just build this with an AI tool or no-code to save the work?

AI and no-code reach a working catalog fast, but B2B breaks on the parts they handle worst: a credit check that must hold under concurrent orders, prices that never leak between buyers, and roles that enforce separation of duties. Those belong in the database inside one transaction. Use AI to move quickly early, then have the money-and-isolation logic built and tested properly before real buyers rely on it.