Commerce, payments, and financial workflows

Ecommerce Platform Requirements Checklist for Retailers

A retailer-focused framework for deciding what an ecommerce build must operate, integrate, verify, and hand over before approving development.

Published by · Expert-reviewed by Kennedy Gichobi · Published · 1617 words

Decide whether custom development solves a commercial constraint

Begin with the customer, product, channel, and operating problem that standard commerce products cannot support economically. A retailer may need unusual product configuration, business-account pricing, location inventory, regulated fulfillment, subscription logic, a marketplace model, offline sales synchronization, or a workflow connecting service and physical goods. If the need is ordinary catalog, checkout, payment, and shipment, a hosted platform with careful configuration may deliver lower risk and ownership cost than rebuilding commerce foundations.

State the intended outcome in measurable terms: reduce incorrect orders, support a new sales model, synchronize stock across locations, shorten quotation-to-payment time, improve repeat purchase, or eliminate manual re-entry. Identify current volume, average order characteristics, peak periods, markets, staff, integrations, and failure cost. Requirements should compare buy, extend, integrate, and custom-build options against that outcome. “A website like a major marketplace” is not a scope.

Model products, variants, bundles, and availability

Define what is sold and what uniquely identifies it. Products may have variants by size, color, material, license, duration, location, or configuration. Decide which attributes affect price, inventory, images, shipping, tax, fulfillment, eligibility, and URL. Model bundles, add-ons, substitutions, preorder, backorder, made-to-order items, digital goods, services, gift cards, and discontinued products only when the business actually needs them. Avoid forcing every offering into one overloaded product record.

Identify who creates and approves catalog data, where descriptions and media originate, how imports work, and whether another system is authoritative. Define stock states and the moment inventory is reserved, released, reduced, and reconciled. A displayed “in stock” label may represent warehouse quantity, sellable quantity after safety stock, supplier availability, or a promise based on lead time. Write the rule. Test concurrent purchases, cancelled payment, returned stock, damaged items, and delayed inventory feeds.

Specify pricing, promotions, tax, and customer context

List currencies, markets, customer groups, contract pricing, volume tiers, memberships, subscriptions, coupons, automatic promotions, gift balances, deposits, and manual adjustments. Define priority and combination rules. State whether prices include tax, when tax is calculated, which address controls it, and which service or qualified professional determines jurisdictional rules. Keep money in precise decimal or minor-unit representations and record currency explicitly.

Pricing should be reproducible from order evidence. Preserve item description, selected options, quantity, unit price, discount, tax, shipping, fees, and total as accepted at purchase rather than recalculating old orders from today's catalog. Define who may issue discounts, refunds, or credits and what approval and audit evidence is required. Test boundary times, expired promotions, partial returns, mixed-tax carts, rounding, currency changes, and retries so a marketing rule cannot silently alter accounting.

Design the cart and checkout as a recoverable transaction

Map add-to-cart, option selection, quantity change, saved cart, guest or account checkout, address, delivery or pickup, payment, confirmation, and recovery. Decide when price and inventory are revalidated. Show changes before charging. Avoid clearing a cart because a session expired or payment needs another step. Prevent accidental duplicate orders when a shopper refreshes, returns from a payment provider, or retries after an unclear response.

Define the order state machine: draft, awaiting payment, authorized, paid, processing, partially fulfilled, fulfilled, cancelled, partially refunded, refunded, disputed, and exceptional states relevant to the business. Separate payment state from fulfillment state. A provider accepting a request does not prove payment succeeded, and a shipping label does not prove delivery. Use idempotency and durable event handling according to the selected services, reconcile asynchronous updates, and give staff an exception queue rather than hiding inconsistent orders.

Minimize payment scope and assign compliance responsibility

Choose the payment architecture with the payment provider, acquiring organization, and qualified compliance advisers. Prefer provider-hosted or provider-supplied collection methods that prevent the merchant application from handling raw card details when they meet the business need. Do not store card numbers, security codes, or payment credentials in application logs, analytics, support messages, or the database. Tokenization reduces exposure but does not remove responsibility for the merchant website, access, vendors, and operating procedures.

PCI DSS provides baseline technical and operational requirements for entities that store, process, transmit, or can affect the security of payment-account data. PCI SSC's current ecommerce guidance emphasizes authorization, integrity, and tamper monitoring for scripts on payment pages because compromised browser code can steal information without interrupting checkout. Inventory third-party scripts, restrict change, monitor important headers and page behavior, and confirm the merchant's validation obligations with the organizations managing its compliance program. A developer should not promise compliance from a library choice.

Connect fulfillment, returns, and customer service

Map how an accepted order becomes a shipment, pickup, digital delivery, scheduled service, or supplier request. Define allocation across locations, split fulfillment, substitutions, packing, labels, tracking, failed delivery, lost packages, and proof of completion. Identify the authoritative system for order, stock, shipment, and customer communication. Treat warehouse, carrier, point-of-sale, supplier, and marketplace integrations as operational relationships with retry and reconciliation—not simple API calls.

Document cancellation, return authorization, received condition, restocking, exchange, partial refund, store credit, shipping refund, tax adjustment, and dispute evidence. State time limits and exceptions in business language and reflect them consistently on product, checkout, account, and support screens. Give staff permission-scoped tools to correct orders without editing the database. Preserve an audit history of consequential changes, actor, time, reason, and related payment or fulfillment evidence.

Make products crawlable, indexable, and consistent

Define canonical URLs for products, variants, categories, filters, pagination, and discontinued items. Ensure search engines can reach important product information in rendered HTML without authenticating or executing a user-specific flow. Avoid generating unlimited crawlable combinations from filters and tracking parameters. Keep titles, headings, descriptions, images, price, availability, currency, identifiers, shipping, and return information consistent between visible content, structured data, feeds, and authoritative inventory.

Google Search Central documents Product structured data for prices, availability, ratings, shipping, returns, and variants and notes that merchant pages may also provide feeds through Merchant Center. Structured data creates eligibility, not guaranteed placement. Validate generated markup and monitor Search Console. Do not publish false reviews, stale availability, or markup for information users cannot find on the page. Plan redirects and feed updates when products merge, split, or retire so catalog operations and discovery stay aligned.

Require accessible discovery, purchasing, and support

Test complete journeys with keyboard, zoom, screen readers, high contrast, mobile devices, slow networks, and realistic product names. Product media needs meaningful alternatives. Variant choices require clear labels and states. Errors should identify the affected field and explain correction without discarding other input. Status cannot depend only on color. Controls need visible focus and adequate targets. Time limits, authentication, address validation, coupons, payment errors, and confirmation must remain understandable.

W3C's WCAG 2.2 provides testable guidance across complete processes, including checkout. Accessibility also affects content operations: new images, product videos, comparison tables, and promotional banners should not undo the platform's accessible patterns. Include author guidance and acceptance sampling. Preserve support alternatives for shoppers who cannot complete an exceptional path, while ensuring staff assistance does not weaken identity or payment safeguards.

Protect accounts, orders, administration, and integrations

Define registration, guest checkout, verification, sign-in, multifactor protection where risk warrants it, recovery, address and payment changes, account deletion, and suspicious-activity response. Enforce authorization server-side for orders, saved addresses, files, refunds, discounts, customer records, exports, and administrative actions. Test attempts to retrieve another customer's order through changed identifiers. Limit staff access by responsibility and revoke it promptly when roles change.

Use managed secret storage, separated environments, reviewed deployment, dependency monitoring, backups, restore tests, security logs, and incident procedures. Validate webhooks and remote data. Restrict upload types if sellers, customers, or staff provide files. The OWASP Application Security Verification Standard can help turn vague security promises into versioned, testable requirements. Select controls based on risk and record evidence; a scanner alone cannot verify order authorization, refund approval, or tenant isolation.

Define performance and peak-event behavior

Set measurable targets for product pages, search, cart operations, checkout steps, administrative workflows, feed processing, and background jobs using representative devices, regions, and data. Identify expected concurrent shoppers and peak patterns from promotions, holidays, product launches, or events. Test beyond average traffic. Cache public catalog content carefully while ensuring price and availability remain trustworthy at decision points.

Plan degraded behavior. If recommendations fail, core purchasing may continue; if tax or inventory cannot be confirmed, the platform may need to pause the order honestly. Use queues, backpressure, timeouts, and alerting according to consequence. Define who responds, what customers see, and how incomplete transactions reconcile after recovery. Capacity is not only server size: payment, carrier, search, email, and inventory vendors have limits and failure modes too.

Preserve merchant ownership and operational visibility

The retailer should control or have transferable access to domains, source repositories, cloud projects, catalog and customer exports, payment and vendor accounts, analytics, search tools, deployment instructions, backups, and recovery procedures. Define data export format, image and content ownership, vendor termination, secret rotation, and removal of former developer access. Avoid permanent public URLs for private invoices, customer files, or exports.

Provide staff dashboards for failed payments, inventory mismatches, unfulfilled orders, integration backlog, refunds, disputes, feed errors, and security-relevant events. Assign owners for catalog quality, pricing, tax advice, orders, access, vendors, incidents, dependencies, and restoration. Budget continuing engineering and support. Commerce rules, product feeds, browsers, payment requirements, and integrations change after launch; an ecommerce platform is an operated service, not a completed set of pages.

Use the checklist before approving an ecommerce build

Confirm that the proposal defines the commercial outcome; compares configuration, extension, integration, and custom build; models products and variants; identifies price, promotion, tax, inventory, and order rules; separates payment and fulfillment state; minimizes card-data scope; covers checkout recovery and duplicate prevention; maps fulfillment and returns; documents system authority and reconciliation; makes product pages crawlable; tests accessible purchase journeys; enforces customer and staff authorization; validates peak behavior; and preserves merchant ownership and operational support.

Ask the developer to trace one difficult order from product availability through promotion, tax, payment retry, split fulfillment, partial return, refund, accounting integration, and customer history. A strong answer exposes state, evidence, failure, and ownership rather than offering only an attractive storefront. Use the project questionnaire to share catalog size, variants, markets, order volume, payment providers, fulfillment locations, integrations, current problems, and desired outcome so discovery can produce a defensible platform recommendation.

Authoritative references

Related software planning guides

Explore custom software development