E-commerce Integration Beyond the Storefront

Most e-commerce platforms solve important customer-facing problems well: catalogue, checkout, payment collection and order confirmation. A growing operation then adds other systems for accounting, shipping, fulfilment, customer service, wholesale, inventory or point-of-sale activity. Each system creates a valid record for its own purpose.

The business problem begins when management needs those records to agree. A customer may place an order, receive a partial fulfilment, return one item and pay through a channel whose settlement arrives after fees have been deducted. The store, carrier, payment provider and ledger may each show a different stage of the same transaction. None is necessarily wrong. The integration needs to preserve the relationship between them.

Alastair McLeod, CEO of Wallace Corporation, describes the goal as operational clarity rather than platform replacement. "The storefront should not become the place where staff manually reconcile the rest of the business. A well-designed integration makes the order flow visible from sale through to fulfilment and financial control."

The relevant systems vary, but an implementation needs to identify the system of record for each part of the process. The store may own the customer order. A warehouse system may own stock availability and picking status. A carrier may own tracking events. A payment provider may own authorisations, refunds, fees and payout detail. Xero may own the accounting record. Problems arise when an integration assumes one system owns facts that actually originate somewhere else.

Inventory requires particular care. Stock availability may need to account for online, wholesale and physical sales, reservations, returns, damaged goods, supplier lead times and stock held in more than one location. Sending an inventory count from one system to another is easy compared with agreeing which adjustments should change the available-to-sell figure and when they should take effect.

The same applies to payments and accounting. An order, a refund, a gateway fee and a settlement need to be traceable to the appropriate financial records. Fulfilment data must give the shipping system enough information to act while returning tracking and delivery status that customer service can use. Customer context should be available without staff moving between several applications merely to establish what happened to a single order.

The implementation should start with the highest-cost failure, not an attempt to connect every system at once. In one operation that may be stock drift between a shop and warehouse. In another, it may be reconciling marketplace or payment-provider settlements before month-end. A narrowly scoped integration that removes a recurring exception is more useful than a broad project with unclear ownership.

Wallace Corporation assesses the balance of the client use case, speed, cost and control. In the Shopify ecosystem, established connectors can be a sensible starting point for standard order, payment and Xero workflows. They can reduce setup time and support processes that match the connector's intended design. A connector also has an operating model of its own: which events it imports, how often it syncs, which fields it maps, how it treats retries, and how it represents refunds or fees.

Those details matter because a connector can appear to work while quietly creating a reconciliation burden. It may not expose the required data, may force a particular timing or mapping rule, may add transaction-based cost, or may not handle a business's exceptions well. The gap becomes visible with multiple sales channels, bespoke freight, wholesale pricing, returns, product bundles, split fulfilments, gift cards, deposits or reporting requirements outside the connector's model.

A custom integration can target the specific hand-off that is failing. It may listen for a paid-order event, validate the payload, enrich it with stock or customer information, send the required fulfilment data and record the outcome for later reconciliation. It may instead run on a scheduled basis, collect a provider's payout report and prepare a matched set of accounting records for review. Scheduled processing is often appropriate where a provider finalises settlement once each day or where the business needs a controlled review point before data reaches the ledger.

For WooCommerce and other ecosystems, custom work may be preferable where it is cost effective and reduces dependency on third-party or abandoned plugins. The decision should account for the ongoing responsibility to monitor API changes, renew credentials, respond to failures and support staff when an exception needs investigation. Custom work has a maintenance cost; so do manual workarounds and a connector that no longer fits the business.

A documented API is a starting point, not a guarantee that an integration can be supported responsibly. Wallace Corporation evaluates permissions, available endpoints, event history, rate limits, pagination, data quality, versioning, maintenance burden and commercial terms. It also checks whether the API provides enough information to identify a record reliably across systems. An order number alone may not be enough where orders can be edited, merged, partially refunded or recreated.

Event delivery requires similar care. Webhooks can make a process responsive, but providers can deliver the same event more than once, deliver events out of order or fail to deliver an event. A resilient integration validates the source, records a stable event identifier, handles repeat delivery safely and has a way to retrieve or replay missing events. Where an action changes stock, creates a financial record or triggers customer communication, the workflow needs safeguards against duplicate processing.

The integration should retain a useful audit trail: source event or record ID, destination record ID, time processed, mapping used, status, error message and the person or process that resolved an exception. This does not mean storing every available customer field. It means retaining enough evidence to explain how a record moved through the workflow while limiting retained data to what the process needs.

Security and access are part of the design

An integration often touches order details, customer contact information, inventory and financial records. Credentials should be scoped to the minimum data and actions required. Read-only reporting should not use a credential that can issue refunds. A fulfilment workflow should not have permission to alter the chart of accounts. Where a platform supports OAuth, the connection should use it rather than sharing a staff password or a broad API key.

Wallace Corporation also considers where credentials are stored, who can revoke them, how access is reviewed, and what happens when a staff member or supplier relationship changes. Secrets should not be placed in spreadsheets, source code or general team chat. Logs need enough detail for diagnosis without unnecessarily reproducing payment or customer information. A client should be able to identify who owns the integration, who is notified when it fails and how a paused workflow is restarted safely.

Security review is practical rather than ceremonial. The goal is to prevent an integration from gaining broad, unexamined access simply because it is convenient during setup. Permission boundaries are particularly important where the workflow can create invoices, adjust inventory, update customer data or prepare financial records.

Reconciliation is the financial control

An e-commerce integration does not need to make every system update at the same instant. It does need an agreed reconciliation process. The design should account for the order lifecycle, including payment authorisation, capture, fulfilment, cancellation, partial refund, full refund, carrier charge, gateway fee and deposit into the bank. The appropriate accounting treatment depends on the client's process and accountant advice, but the system should make each component traceable.

The distinction between order time and settlement time is common. A customer may pay on one day, the payment provider may settle the funds later, and the bank may receive a net amount after fees. If the workflow posts only the order total or only the bank deposit, staff still have to reconstruct the missing parts. A better design identifies the evidence source for each component and makes the expected relationship visible in an exception queue.

Tyrell's operational test is direct. "When a customer calls about a refund, the team should not have to ask which dashboard contains the truth. The order, the fulfilment status, the payment adjustment and the ledger trail need to be available together."

Exceptions decide whether the integration is usable

The happy path is usually straightforward. The work begins with the records that do not fit it: an order changed after fulfilment, a stock adjustment from a physical sale, a bundle whose components are held in different locations, a refund without a return, a carrier label that fails after payment, a duplicate webhook, an API timeout or a payout that does not reconcile.

Each exception needs an owner and a recovery path. Some can be retried automatically after a temporary API failure. Others should stop for review because an automatic retry could create a duplicate invoice, shipment or adjustment. The workflow should show what failed, which records are affected, whether any downstream action succeeded and what staff need to decide. A generic "sync failed" message is not enough for an operations team trying to resolve a customer order or close a month-end reconciliation.

Exception handling also affects the project scope. A team may decide that the first version should only read and report differences, or create drafts rather than final financial records. Once the exception rate and approval process are understood, the scope can expand to carefully defined actions. This approach gives the business evidence about the process before it delegates more responsibility to the integration.

Managing systems with APIs

Wallace Corporation does not limit integration work to one approved platform list. A system with a stable, documented API can be evaluated for connection, subject to its permissions, rate limits, data quality, maintenance burden and commercial terms. The question is whether the integration can be supported responsibly and whether it resolves a specific operating problem.

A practical discovery process maps the systems, events, systems of record, exceptions, owners and recovery paths. It also identifies where a person must approve an action. That protects the business from an integration that moves data quickly but creates unreviewed financial or customer-service errors.