What Should You Prepare Before an Ecommerce Integration?
Prepare product identifiers, data ownership, order states and acceptance tests before connecting inventory, shipping and accounting systems.
Quick Answer
Map the Data Before Choosing the Connection
Match Product Identifiers and Variants
Agree on Inventory and Order States
Assign Access, Error Handling and Ownership
Test More Than a Successful Order
Define the Handover Before Going Live
Quick Answer
Before an ecommerce integration, identify systems, product IDs, field ownership, transfer directions and responsible people. Test payment, inventory, shipping and repeated events with sample orders, then record the acceptance conditions.
The last item sells on your website, but the warehouse system still shows one available. Meanwhile, the same order has reached accounting twice. Connections can appear healthy while staff spend hours reconciling records because nobody agreed which system owns each field or how repeated events should be handled.
Map the Data Before Choosing the Connection
Give products, prices, available stock, orders, payments, shipments and returns separate rows in the preparation document. Identify the source, destination, direction and person responsible for each. If the store is still being built, align the work with the ecommerce launch checks.
Consider a hypothetical homeware store that keeps stock in warehouse software and descriptions in the website editor. Importing every product field from the warehouse could overwrite descriptions the editor has corrected. A field-level agreement makes that conflict visible before implementation.
| Data | Decision Needed | Sample to Supply |
|---|---|---|
| Products and Variants | Which identifier represents the same item? | Product code, colour, size and corresponding system ID |
| Inventory | Which system calculates available stock? | Location, reserved quantity and sellable quantity |
| Prices | Which value changes under which conditions? | Currency, price type and discount field |
| Orders | Which event starts the transfer? | Order reference, line items and payment state |
| Shipping and Returns | Which changes are sent back? | Tracking reference, partial shipment and return example |
Match Product Identifiers and Variants
Names alone are unreliable identifiers: several sizes or colours may share a name. Compare the product IDs and stock keeping units, or SKUs, used by each system. Shopify’s SKU guidance distinguishes internal stock codes from barcodes and explains variant identification. Confirm which field your proposed connection actually uses.
Supply imperfect records as well as clean ones. Include a missing code, a duplicate, a code with a leading zero and a discontinued item. If opening a spreadsheet turns an identifier into a number and removes its leading zero, fix the handling before importing. An unmatched record should be flagged rather than silently attached to another product.
Agree on Inventory and Order States
Physical stock and stock available for sale may differ. Decide how to treat items reserved on another channel, returned items awaiting inspection and separate warehouse locations. Where two systems can change the same field, document which value takes precedence when they disagree.
Do not combine payment pending, paid, packed and partially shipped into one generic completed state. Shopify’s order status documentation separates payment, fulfilment and returns. Map the actions expected in the warehouse, payment service and accounting system when your business receives a cancellation request.
Assign Access, Error Handling and Ownership
Which account does the implementation team need, and with which permissions? Can they test without affecting real orders? Record the business account owner, technical contact and person who investigates failed transfers. Keep passwords and secret keys out of a shared product spreadsheet; use the provider’s supported secure access method.
Agree on the transfer interval and acceptable delay. Describing a connection as real time does not explain how missing records will be recovered after an outage. Assign someone to compare order lists and resolve discrepancies. If you are still choosing a supplier, include those responsibilities when comparing integration scope and acceptance tests.
Test More Than a Successful Order
For each scenario, record the starting data, expected result, actual result and reviewer. Test a repeated event deliberately. Shopify’s delivery verification documentation notes that duplicate notifications can occur. Developers need to handle repetition safely; the business should check that stock is not deducted twice and duplicate accounting records are not created.
- Transfer a variant order with the correct product code and quantity.
- Check the agreed order and inventory states after a declined payment.
- Apply the agreed stock rule when two channels request the last item.
- Process a partial shipment and return without closing unaffected items.
- Find missing records after disconnecting and restoring the connection.
- Repeat a notification and confirm that it does not duplicate the business transaction.
These are starting scenarios, not a universal implementation specification. Ask the accounting software provider and your business’s accounting adviser to confirm the conditions for financial documents and processes.
Define the Handover Before Going Live
Retain the approved field mapping, access owners, test results, known limitations and support contacts together. Decide which records will be checked in the first group of real orders. Establish who can pause the automation and how orders will be handled if a fault appears.
When discussing ecommerce integration planning with Piar Medya, share your systems and a representative order. The data and test list helps establish whether the work involves configuring an existing connection or developing something further.
FREQUENTLY ASKED QUESTIONS (FAQs)
List the systems, sample products and orders, field mappings and responsible people. Specify the source, direction and expected test result for each data item. A connection name alone does not define its scope.
Use an order with a real product structure but safe test data. Follow its variant identifier, quantity, payment state and fulfilment state across the connected systems. Include a partial shipment or return if your business uses them.
Compare the platform with your required fields, states and error handling. Test your own sample records, including a repeated event. Product popularity does not establish that a connection handles your workflow correctly.
Supply the system and version list, anonymised sample records, transfer directions and unresolved responsibilities. Identify product variants consistently so the supplier can assess matching requirements rather than guessing from product names.
Agree on field mappings, acceptance results, access ownership, known limitations and an error-resolution contact. Define how missed or repeated events will be identified. The required deliverables depend on the systems and business workflow.
Connection count alone is insufficient. A smaller supported scope that handles your variants, inventory and order states may fit better. Confirm the required behaviour with sample records and distinguish standard configuration from additional development.
