Describe one real order before naming a platform
Follow a representative buyer from product discovery through delivery, returns, and settlement. Identify which prices are public, who approves discounts, and where an order becomes authoritative. Consider a hypothetical wholesaler: a distributor receives contract prices, submits a draft order, and passes a credit check before warehouse release. That differs from guest checkout with immediate payment. Record both workflows explicitly so a broad request for a store does not conceal the operational differences that determine platform fit.
- Deliverable: an order map naming actors, states, systems of record, and exception owners.
- For each requirement, record today's method and an observable test; 'supports B2B' is not an acceptance criterion.
- Separate launch essentials from growth ideas so suitable options are not discarded prematurely.
Technical sources for this section: OWASP [3]
Compare operational gaps and ownership
These patterns are starting points for evaluation, not a universal ranking. Configuration may make a packaged product sufficient; custom solutions may still use external catalog or payment services. In this suggested comparison, prioritize a working buying journey and maintainability. Ask suppliers to demonstrate the preceding workflow. Classify every gap as configuration, extension, integration, process change, or code, and identify who maintains that change after launch. Compare proposals against the same scenarios and ownership period.
| Pattern to investigate | Decision question | Evidence to request |
|---|---|---|
| Hosted, configuration-led commerce | Can current features and contractual terms implement your prices, roles, and payments? | A representative order and a usable data export |
| Extensible platform with integrations | Can bounded, maintainable changes close the gaps? | Extension inventory, version ownership, and compatibility tests |
| Custom or hybrid solution | Which sales rule justifies development and operating costs? | A prototype of that rule, integration boundaries, and operating handover |
Technical sources for this section: Stripe [1]OWASP [3]
Define inventory and pricing authority
Assign an authoritative source and a discrepancy-resolution path for each field: SKU, available stock, tax, contract price, and shipping charges. Then decide how the store behaves when an integration fails. In a hypothetical workflow, stale warehouse stock could put an order into pending approval or block checkout; your operations should choose. Treat payment confirmation and inventory reservation as distinct events and test what happens when one succeeds while the other fails. Require evidence for the chosen behavior before accepting an integration.
- Concurrency: what happens when two buyers request the last unit?
- Pricing: which rule applies if a price changes between adding to cart and placing an order, and how is the buyer informed?
- Reconciliation: which operational queue and owner handle a confirmed payment whose warehouse registration failed?
Technical sources for this section: Stripe [1]
Test uncertain and duplicate payment events
Do not use a browser return as the sole financial evidence. Verify authoritative status server-side according to the selected gateway's contract and API. As one documented example, Stripe describes duplicate and out-of-order event delivery and requires verification of webhook signatures. Use that example to formulate questions rather than assuming every gateway behaves identically. Specify permitted transitions among pending, successful, failed, canceled, and refunded states. Orders and transactions should have separate tracking identifiers so operations can investigate a mismatch without guessing.
- Acceptance: replaying valid confirmation does not create another order or shipment; this property is called idempotency.
- If a buyer closes the browser or confirmation arrives late, operations can retrieve the actual status and reconcile it with the order.
- A forged message or invalid state cannot authorize fulfillment; diagnostic records avoid sensitive data.
Technical sources for this section: Stripe [1]
Enforce B2B permissions on each request
Signing in does not authorize access to another company's contract. OWASP recommends least privilege, denying access by default, and checking permissions on every request. Define the user's relationship to the company, branch, contract, and purchasing authority. In a hypothetical approval flow, a buyer prepares a basket, a manager from that company approves it, and sales staff may adjust prices. Each actor must see only authorized records. Hidden buttons or columns alone do not demonstrate that the underlying access rules work.
- Two-company test: changing an order or invoice identifier does not reveal another company's data.
- Restricted-role test: a direct request to approve an order or change its price is denied.
- Leaver test: removal of membership and relevant sessions follows the organization's documented policy.
Technical sources for this section: OWASP [3]
Include catalog and URL migration in the scope
Sample actual exports of products, images, variants, categories, and existing URLs before selecting a platform. Google's guidance explains how multiple URLs for identical content or unbounded parameters can complicate crawling. Define destinations for old URLs, each product's canonical page, and filter behavior in the migration plan. Make separate editorial decisions for discontinued and replacement products. A platform move should not automatically send every old address to the home page. Check how catalog ownership and publishing responsibilities will work after migration.
- The migration sample includes a product with variants, an unavailable product, and a category with filters.
- Validate titles, descriptions, images, prices, and availability against the authoritative source after transfer.
- Before changing domains or paths, review the URL inventory and redirect map, then test important entry-to-purchase journeys.
Technical sources for this section: Google Search Central [2]
Tie the buying decision to a pilot and handover
Run the pilot on a manageable catalog subset and one buyer group. Sales and operations owners should agree the evidence needed to continue before work starts; page counts or installed extensions are insufficient. The table is a suggested acceptance template, not a reported project outcome. After testing, review remaining gaps alongside estimates with explicit assumptions and named support ownership. Use that evidence to continue, revise the scope, or stop. Keep the decision record so later expansion can revisit its assumptions.
| Flow | Suggested acceptance criterion | Operational handover |
|---|---|---|
| Checkout and payment | Success, delay, duplicates, and failure end in the correct financial state | Reconciliation and order-investigation runbook |
| Stock and pricing | Discrepancies and integration outages follow the agreed rule | Systems of record and exception queue |
| Business purchasing | Test accounts demonstrate company isolation and approval limits | Role matrix and access owner |
| Exit from the solution | A sample data export and transfer method are usable | Account, version, and integration-document ownership |
Technical sources for this section: Stripe [1]OWASP [3]Google Search Central [2]