Mintsoft integration for ecommerce fulfilment

Orders are pulled from your commerce platform via API or file export on a scheduled interval (typically every 5-15 minutes). Each order includes line items, shipping address, customer contact and any special handling instructions. The integration acknowledges successful ingestion back to commerce to prevent duplicate orders.

Orders with missing or invalid data (unknown SKU, incomplete address, invalid postcode) are quarantined in an exception queue in Mintsoft. Fulfilment teams or customer service review these orders, correct the data, and resubmit them. The integration must surface these exceptions to a monitoring dashboard so they do not sit unnoticed.

Orders from Shopify, Amazon, eBay, or custom marketplaces are normalized by the integration so that channel-specific IDs and metadata (seller account, marketplace order ID, channel-specific SKU) are preserved. This allows returns and refunds to route back to the correct channel.

Once Mintsoft generates a shipping label, the integration publishes the tracking number and carrier name back to commerce. Commerce then sends a dispatch notification email to the customer with tracking link. Timing depends on label generation latency and integration batch frequency; ideally this happens within minutes of pack completion.

Stock sync frequency is typically hourly or every 4 hours, depending on order velocity and oversell tolerance. More frequent sync (every 15-30 minutes) is needed for high-velocity or limited-stock scenarios to reduce oversell risk. Sync must also be triggered immediately after significant stock movements (large returns, inventory adjustments).

The integration queues stock movements and retries sync when ERP is back online. During an ERP outage, stock counts in commerce may become stale; this risk is managed by setting a maximum acceptable staleness window (e.g. stock older than 2 hours is not served to commerce). Manual stock checks or service suspension may be needed if outage extends beyond that window.

Carrier selection rules (which carrier ships which postcode, weight or destination) live in Mintsoft or a carrier rules engine. When these rules change (e.g. carrier raises rates, new service tier added), shipping costs in commerce must be updated to match. This is typically a manual sync or a downstream push from Mintsoft to commerce when rates change.

When a customer initiates a return in commerce or a customer service team creates an RMA, the return event is sent to Mintsoft with RMA number and return reason. Mintsoft generates a return label and tracks the return back to the warehouse. Once returned inventory is receipted, Mintsoft updates stock counts and ERP adjusts the inventory record.

If a carrier integration fails (e.g. address validation fails, carrier rate server is down, carrier account balance is depleted), the order is flagged in Mintsoft's exception queue. The integration must alert the fulfilment team immediately so they can select a fallback carrier, contact the customer, or hold the order. Silent carrier failures are a major risk.

The integration must provide a monitoring dashboard or alert system that surfaces unshipped orders, exception queue size, and aging metrics (e.g. orders over 24 hours old with no despatch label). Alerts should be sent to fulfilment and customer service teams so issues are resolved before customers contact support.

Yes. If inventory is insufficient to fulfill an entire order, Mintsoft can create a partial shipment for available items and backorder the rest. The integration must update commerce order status to reflect split shipments and communicate backordered items and expected ship dates to customers.

If an order is cancelled in commerce before it ships, a cancellation event is sent to Mintsoft to remove the order from the picking queue. If the order has already been picked or packed, it is held in a cancellation queue where fulfilment teams decide whether to refund and discard inventory, or return items to shelf. Clear escalation paths and monitoring are needed to prevent cancelled orders from shipping.

Core mappings include: product SKU (commerce SKU to warehouse SKU), shipping address fields, order identifier, customer contact info, delivery options (carrier service level), and special handling codes (fragile, hazmat, signature required). Channel-specific mappings (marketplace order ID, seller account) are also needed for multichannel orders.

Monitoring tracks order ingestion latency, despatch confirmation latency, stock sync currency, exception queue age and size, and carrier success rates. Typical SLAs include: order acknowledged within 15 minutes, despatch confirmation within 1 hour of label generation, and stock sync fresher than 4 hours. Breaches trigger alerts and escalation.