Shopify B2B store for a US subsidiary · B2B backend
Period — Present
A Shopify B2B store where a global sports brand's US subsidiary takes orders from business accounts. I owned the backend and built the B2B server and the ERP integration server.
B2B server that serves catalogs and prices per account
and handles orders from submission to partial shipment
- Account, location, product and inventory synchronization
- Account‑specific order quantity rules
- Signature‑verified webhook storage, retries on failure and quarantine of invalid messages
One server for ERP communication
- Problem
- If the B2B and B2C servers each kept their own ERP client, credentials and integration rules would be scattered. Every ERP‑side change would need fixes in each server.
- Solution
- Routed all ERP communication through one integration server. The B2B and B2C servers use only its internal API and events. Changes on the ERP side need updates only in the integration server.
Checking the assumptions behind the requested scope
- Problem
- The development scope the client requested assumed an ERP connector already existed.
- Solution
- Sorted the requested items into reuse, modification, new development and external confirmation. Before development began, I pointed out that the connector did not exist and which work needed a separate contract.
One validation for three order methods
- Problem
- Requirements for per‑account access, catalog visibility, bulk orders and prepaid versus postpaid billing arrived at once. Orders also had to come through a matrix, a catalog or product codes and CSV files.
- Solution
- I opened a separate technical review for each policy and answered with three questionnaires that split what the client had to decide from what needed technical checks. All three order methods feed the same cart, so I designed one shared order validation API.
A changed order basis and confirmed policy
- Problem
- In a meeting, the B2B order basis changed from production orders to current stock plus incoming quantities. The change conflicted with work already built.
- Solution
- I recorded change requests apart from confirmed policy and listed where they conflicted with the existing implementation. Changes went through a set order: back up what was built, list the changes, then agree on the scope and schedule impact. Confirmed policy and requests still needing checks no longer get mixed up.
Constraints that mock responses missed
- Problem
- Mock server responses could not reveal the real store's constraints.
- Solution
- Sent synthetic data through the integration server and processor to a development store and checked actual prices and inventory. From the real responses, I found and fixed issues with identifier formats, account update fields and conflicting price list names.