The most expensive assumption in B2B commerce is that checkout is the solved part. The reasoning goes: B2C checkouts are a commodity, B2B is B2C with invoices instead of credit cards, therefore the checkout is a line item. Then the workshops start, and the line item unfolds into the half of the project where the client's actual business lives.

Here is what is really inside it, and roughly where a platform like Spryker stops helping and your build begins.

"Payment" mostly means credit

In B2C, payment is authorisation: is this card good for €80, yes or no, in two seconds. In B2B, the dominant payment method is on account — the order ships now and the invoice is due in thirty days — which means the question is not "is the card good" but "is this customer good for another €40,000 on top of what they already owe". That is a credit decision, and the data to make it lives in the ERP: open items, credit limit, payment history, blocks.

So the checkout has a synchronous dependency on the credit check, and you need three answers designed before anyone writes code:

  1. Where is the check made? Asking the ERP live is accurate and couples your checkout availability to the ERP's uptime. Replicating exposure data into the shop is fast and can be minutes stale — which matters exactly when a customer is placing orders rapidly, which is exactly when credit matters.
  2. What happens on "no"? Hard-blocking the order loses revenue over data staleness. The pattern that survives contact with sales teams: accept the order into a review state, tell the customer honestly, and give the credit team a queue. A blocked checkout is a phone call to sales anyway; better to own it in the system.
  3. What happens on "unknown"? The ERP will be unreachable during checkout at some point. Failing open or failing closed is a finance-department decision. Get it in writing; you are choosing between lost orders and bad debt.

Spryker gives you the plumbing here — a payment method plugin architecture and a state machine per payment method — and none of the policy. The state machine you configure is the credit policy. Treat that XML with the reverence you would give pricing code.

The order is a committee

A B2C order has one human. A B2B order routinely has three: the requester who fills the cart, the approver who owns the budget, and purchasing who owns the supplier relationship. Spryker's company account model — business units, roles, permissions, approval flows — covers the healthy 80%: spend thresholds per role, approve or reject with a comment, notifications.

The remaining 20% is where the workshops earn their keep, because approval rules encode the org chart, and org charts are weird. Approval by cost centre rather than amount. Deputies for approvers on holiday. The rule that chemicals need a safety officer's sign-off regardless of price. You will not configure that; you will build it. The trick is to find out which of those rules are real requirements and which are how the old fax workflow happened to work. Asking "what happens today when this rule is violated?" kills about half of them.

Punchout, quotes, and the other doors into checkout

A serious B2B storefront has more entrances than the cart button:

  • Punchout (OCI/cXML). Your biggest customers may never see your checkout at all — their procurement system opens your catalog, the filled cart is returned to their system, and the order arrives later as an EDI or API message. Checkout, payment and approval all happen on their side. If the target segment includes enterprises with SAP Ariba or Coupa, punchout is not an add-on, it reshapes what "checkout" even means for your best accounts.
  • Quotes. Above a certain order value, the cart is an opening bid. Request-for-quote flows — cart becomes a quote, sales adjusts prices, the customer converts it back into an order — blur the line between commerce platform and CRM. Decide early which system owns a negotiated price and how long it is honoured.
  • Order templates and replenishment. The weekly re-order of two hundred line items is the actual daily life of B2B buying. A checkout optimised for the first-time visitor and unusable for the two-hundred-line repeat order has optimised the wrong funnel.

None of this is exotic. It is the ordinary contents of the phrase "B2B checkout", visible only if you unfold it before the estimate instead of after. The projects that go well are the ones where the credit policy, the approval matrix and the punchout question were on a whiteboard in week two — while the projects that go badly discovered them in UAT, one surprised stakeholder at a time.