Record the order
WooCommerce would save the selected products and buyer details. The order would remain in the store as the basis for further processing.
TYRE STORE / DOCUMENTATION
Technical specification for a tyre store
Technical specification for an e-commerce dependent on a wholesaler by an API
We documented how tyre selection, store pricing and wholesaler fulfilment should work together, including exception handling and the scope of prototyping.
Websites and e-commerce
00 / Starting situation
The planned online store would sell tyres from a wholesaler’s range and pass orders to that partner for fulfilment. The owner needed to define how supplier data would connect with the store’s pricing rules, payments and customer service. We prepared the technical specification for this service.
01 / SCOPE OF WORK
How the store would sell from a partner’s stock
We prepared a specification for a WordPress and WooCommerce store, covering the journey from finding tyres to sending a paid order to the wholesaler. We described customer and administrator functions, the division of data between systems and the integration requirements.
The central task was to connect what customers would see and buy in the store with information about what the partner could supply. Wholesale prices and availability would come from an external system, while orders and payments would be handled in the store. The document defined the relationships between these parts of the sales process.
02 / PRODUCT SELECTION
From vehicle details to a specific tyre
We described two search paths. Buyers who knew their tyre size would enter its width, profile and diameter. The second option would let them select vehicle details, including make, model and year.
That second path required a local database mapping vehicles to tyre sizes. Only after identifying the size would the system search for matching products in the wholesaler’s range. The specification therefore separated size selection from retrieving available tyres.
03 / DIVISION OF RESPONSIBILITIES
The wholesaler’s range, the store’s order records
We defined the wholesaler as the authoritative source of base prices and stock levels. Products would be retrieved through an API, with the option to cache responses temporarily, without permanently maintaining the full catalogue in the store. Orders and customer accounts would remain in WooCommerce, with pricing rules also managed on the store side. We identified the data source for each of these parts of the system.
04 / PRICING RULES
A retail price calculated from the wholesale price
We described a markup mechanism applied when retrieving a product. The administrator would set and edit rules in the panel, assigning them to categories, brands or tyre parameters. The supplier’s price would provide the basis for calculating the price shown to buyers.
The document thus specified both where the store’s pricing policy would be managed and when it would be applied to data received from the wholesaler.
05 / Process
Planned flow: from purchase to wholesaler acceptance
Confirm payment
Confirmation from the payment provider would trigger submission of the order to the wholesaler. Payment alone would not yet mean that the partner had accepted it.
Receive the wholesaler’s response
The integration would receive either confirmation of order acceptance or information about a problem. This response would determine the next processing step.
06 / EXCEPTION SCENARIO
What if stock runs out after payment?
We included a scenario in which the buyer pays for an order but the wholesaler can no longer fulfil it because the product is unavailable. The specification provided for receiving the stock error and notifying the customer.
We separately described API communication failures: logging them, then retrying the request or notifying the administrator. The requirements therefore also covered situations where payment has been accepted but passing the order on for fulfilment requires further attention.
YOUR E-COMMERCE PROJECT
Define how your store should work before building it
We translate a sales model into requirements for the store, its integrations and daily operations. We help define the data and decisions that need to connect these areas.
08 / OPERATIONS AND MAINTENANCE
Tasks for the team running the store
The administration scope covered orders, integration settings, pricing rules and content management. We also described requirements for a knowledge base, a newsletter and reports on sales and order statuses.
We supplemented these with requirements for user permissions, backups and service performance. These were conditions for future implementation and verification, defining maintenance needs alongside the sales functions.
09 / VERIFICATION PLAN
API dependencies identified before implementation
We distinguished the required order flow from features dependent on the partner’s capabilities. Shipping updates would be optional, available if the wholesaler’s API provided the relevant data or notifications.
The prototyping plan included product retrieval, tyre search, payment and order submission. The document set out the scope for verifying these connections before full implementation.
S.09 / ContactEnquiry / similar challenge
What in this case resembles your situation?
Describe the similarity and the result you need. We will not assume that the same scope is the right answer.
- 1Conversation scopeCurrent step
- 2Context
- 3Budget and timing
- 4Contact
We respond with a concrete recommendation by the end of the next business day.
Step 1 / 4