A business buyer with a net-30 account, a tax exemption, three ship-to locations, and a required PO number hits your checkout – and it asks for a credit card, one address, adds sales tax, and has never heard of a purchase order. That buyer closes the tab and emails their rep. The catalog and pricing can be perfect; if checkout assumes retail, the order still does not happen.
B2B checkout is where a lot of otherwise-good portals quietly fail. This guide covers what it has to do differently – net terms, credit, tax exemption, PO payment, multi-location shipping – and which parts live in the ERP versus the storefront. It is the last mile of a working B2B portal, and the one most likely to be underscoped.
Why B2B checkout is not B2C checkout
Retail checkout optimizes for a stranger paying by card and shipping to one address. B2B checkout serves a known account with an account, terms, exemptions, and process. The differences are not cosmetic – each one is a place where a retail checkout actively blocks a legitimate B2B order:
| Dimension | B2C assumption | B2B reality |
|---|---|---|
| Payment | Card, captured now | Pay on account, net terms, invoiced |
| Credit | N/A | Credit limit and holds, ERP-enforced |
| Tax | Charged | Often exempt / resale certificate |
| Reference | None | PO number, sometimes required |
| Ship-to | One address | Many locations per account |
| Price | List | Account-specific, resolved |
| Approval | None | Internal approval chain, sometimes |
Net terms and pay-on-account
The defining B2B payment method is not paying at all at checkout – it is placing the order on account and paying the invoice later. To support it online:
- Offer pay-on-account as a checkout method for approved customers only, based on their status in the ERP.
- Create the order for invoicing rather than capturing payment – the AR flow lives in the ERP.
- Still offer card and other methods for customers or orders that need them (new accounts, over-limit orders).
Which customers get terms, and on what limit, is an ERP decision the checkout reads – never a setting maintained separately in the storefront.
Credit limits and holds
Terms come with credit control. A B2B checkout has to respect, in real time from the ERP:
- Credit limits – an order that would exceed the customer’s available credit is flagged before it is accepted, not discovered by a CSR afterward.
- Credit holds – an account on hold cannot place a terms order until the hold clears, with a clear message rather than a silent failure.
- Available credit display – showing remaining credit helps buyers self-manage and avoids surprised, abandoned orders.
Tax exemption and resale certificates
A large share of B2B buyers are tax-exempt or buying for resale. The checkout should recognize the customer’s exemption status and apply it automatically, and the account should carry the resale or exemption certificate on file for compliance. The two failure modes both hurt: charging tax to an exempt customer creates friction and credits; accepting an exempt order without a valid certificate creates an audit exposure. Tax logic usually runs through the ERP or a tax engine, and the checkout enforces the customer’s status rather than guessing.
PO numbers and approval workflows
Many business buyers require a purchase-order number on every order, and some route orders through an internal approval chain first. A B2B checkout should:
- Capture the PO number (optionally require it per account) and carry it into the ERP order, so it appears on the invoice and in the customer’s procurement records.
- Support approval routing where a buyer places an order that a manager must approve before it is finalized – mirroring the customer’s own procurement process.
- For customers who buy through procurement systems, connect via PunchOut so the order and PO round-trip through their platform automatically.
What lives where
The division of labor is the same one that governs the whole portal: the ERP owns terms, credit, tax status, and the customer’s pricing; the storefront presents the options, enforces the rules it reads, captures the order, and hands it back. A B2B checkout that tries to own any of that data – maintaining its own credit limits or exemption flags – drifts out of sync with the system of record and creates exactly the reconciliation problems it was meant to avoid. It is the last stretch of the same ERP integration that powers pricing and inventory.
Who we are
Web Solutions NYC builds B2B checkout that behaves like B2B – net terms, credit enforcement, tax exemption, PO capture, multi-location shipping – on Shopware and Adobe Commerce, wired to NetSuite, SAP, Dynamics, Acumatica, Sage, and Epicor P21. We are a Shopware Platinum Partner and official Adobe Commerce partner, and checkout is one of the places we scope early because it is where B2B orders most often silently break.
Frequently asked questions
B2B checkout has to handle payment on account (net terms), credit limits and holds, tax exemption with resale certificates, purchase-order numbers, ship-to selection across multiple locations, and account-specific pricing – none of which a standard retail checkout assumes. Forcing B2B buyers through a card-only, single-address, tax-charged checkout is one of the fastest ways to send them back to phoning orders in.
Net terms mean the buyer pays on account within an agreed period (net 30, net 60) rather than at checkout. Supporting them online means the checkout offers pay-on-account as a method for approved customers, enforces their credit limit and any holds from the ERP, and creates the order for invoicing rather than immediate capture. Approval and limits are ERP facts the checkout must read in real time.
Yes, and it must. Many B2B buyers are tax-exempt or buying for resale. The checkout should recognize a customer’s exemption status, apply it automatically, and store the resale/exemption certificate on the account for compliance. Charging tax to an exempt customer – or failing to collect a valid certificate – creates reconciliation and audit problems.
Frequently, yes. Many business buyers require a purchase-order number on every order for their own procurement and approval tracking, and some route orders through an internal approval step before the PO is issued. A B2B checkout should capture the PO number, carry it into the ERP order, and where needed support an approval workflow before the order is finalized.
Losing B2B orders at a retail-style checkout? Bring us your terms, tax, and PO requirements and we will map a checkout that lets your accounts actually buy. Let’s talk.