B2B E-commerce Platform

Contract Pricing, Approvals, Credit and EDI

Design a platform where businesses buy from a supplier: each company sees its own negotiated prices, orders pass through approval rules, pay later on credit terms, and flow in and out of the buyer's own systems through EDI and punchout.

Overview

A B2B (business-to-business) platform sells to companies rather than to people. The cart looks the same as a consumer shop, but almost everything behind it is different. A company has many buyers with different permissions. It has negotiated prices that other customers do not get. A large order needs a manager's approval before it becomes a purchase order (PO). The company does not pay by card at checkout; it receives an invoice and pays later, on terms such as net 30 (due 30 days after the invoice). And big buyers often do not use the website at all: their purchasing systems send orders directly as EDI documents.

So the design is less about raw traffic and more about rules: which price applies to this company for this product today, who must approve this order, whether this company has enough credit left, and how to exchange documents with systems you do not control.

Questions to ask first

Who buys? — 500,000 company accounts with 10 million users
How many orders? — About 300,000 a day, peaks 5 times the average
How are prices set? — List prices, public volume tiers, and per-account contracts and category discounts
Is approval needed? — Configured per company, by order amount
How do they pay? — Most on net 30 or net 60 terms against a credit limit; some by card
How do large buyers connect? — EDI (X12) for orders, acknowledgments, ship notices and invoices; punchout from their procurement system
What must be fast? — Showing prices on search and product pages; 100 ms at p99 is our target

What you will be able to do

Model company accounts, roles and spending limits, and route an order through an approval chain.
Resolve the right price for an account, a product and a quantity, fast enough for a search page.
Enforce credit limits under concurrent orders and explain net terms and invoice aging.
Explain EDI (850, 855, 856, 810, 997), AS2 and punchout, and design the three-way match that releases payment.

Key concepts

Account hierarchy
Contract pricing
Price resolution order
Approval chains
Credit limits
Net terms
EDI (X12)
Punchout (cXML)
Three-way match
Entitled catalogs

Functional requirements

Company accounts with users, roles (buyer, approver, admin), cost centers and per-user spending limits
Show each account its own price for every product and quantity: contract, category discount, volume tier or list
Route orders above a company's thresholds through an approval chain before they become purchase orders
Check and reserve credit at order time; invoice on net terms; put accounts on credit hold when overdue
Accept orders by EDI and punchout, and send acknowledgments, ship notices and invoices back the same way
Ship one order to several addresses and in several shipments; invoice what shipped
Restrict each account to the catalog its contract allows

Non-functional requirements

Price lookups answer in 100 ms at p99 for a page of 50 products (a target we chose)
Contract changes show in prices within a minute
Orders, approvals and invoices are durable and auditable; no silent edits after approval
Credit can never be overcommitted by two orders placed at the same time
An EDI document is processed once even if the partner sends it twice

Interview questions

How do you show each company its own prices, fast?
Design the approval workflow.
How do you stop a company from exceeding its credit limit?
What is EDI and how would you support it?
What is punchout?
What is a three-way match and why does the supplier care?
How does B2B differ from a consumer shop at scale?