A WooCommerce connector is easy to demo with one order. Production gets harder when stores have variations, discounts, mixed tax, partial refunds, failed payments, shipping adjustments and stock changes. The integration contract should be designed around those exceptions before the first automatic journal is posted.
Do not treat the order payload as a flat invoice. Preserve the customer, line, tax, discount, shipping, payment and refund relationships.
1. Set ownership for every record
WooCommerce should remain responsible for checkout, storefront order state and the source product representation. JielianERP can own company accounting, bank, purchasing, management inventory and reporting. If stock is written in both directions, define which system wins and how delayed events are handled.
2. Choose webhooks and API reads
WooCommerce webhooks can notify another system when orders, customers, products and coupons change. The REST API can then be used to read the complete record or backfill a date range. Webhook payloads include a signature header generated from the configured secret. Verify it before accepting the event.
Keep the WooCommerce webhook ID and delivery ID with the ERP event. They provide a useful audit and support trail when a store administrator reports that an order did not appear.
3. Map the commerce model
Products and variations need stable ERP relations. Tax lines, shipping methods, coupons and fees should map by explicit rules rather than disappearing into one sales total. Payment gateways need deposit, clearing and fee behavior. Multi-currency stores also need the original order currency and the company base-currency conversion snapshot.
Minimum order snapshot
- Store, company and connection identity
- Order number, internal ID and status
- Customer and addresses
- Products, variations, quantity and line totals
- Discount, shipping, fee and tax lines
- Payment method, currency and settlement reference
- Refund and parent-order relationships
4. Design for partial refunds
A refund can reverse selected lines, quantities, shipping, tax or an arbitrary amount. The ERP should link it to the original order and original accounting result. Inventory movement and revenue reversal should follow the actual refund data, not assume every refund cancels the whole order.
5. Choose an inventory source
If WooCommerce is the inventory source, ERP stock should follow verified store events. If JielianERP is the source, product and stock updates need a protected outbound queue. A conflict policy is required for manual changes made while a sync is delayed. The pilot should include oversell, cancelled order and restored-stock scenarios.
6. Run a measurable pilot
- Use one store and one dedicated company workspace.
- Import products and variations, then review every match.
- Test new, paid, cancelled and failed orders.
- Test full and partial refunds with tax and shipping.
- Reconcile order totals, gateway settlements, fees and bank receipts.
- Repeat webhook deliveries and verify that records are not duplicated.
Production gate
The connector is ready only when source ownership, webhook verification, idempotency, mapping locks, refund behavior, inventory conflicts, currency snapshots, settlement reconciliation and tenant isolation have automated tests and visible support tooling.