Aeion Fulfillment vs ShipStation, ShipBob & Shippo

The Webhook Lag Problem

ShipStation syncs with Shopify/WooCommerce via webhooks. When a customer completes checkout:

Shopify: payment.captured ↓ (5-60 second webhook delay) ShipStation: inventory.decrement() ↓ (5-60 second webhook delay) Shopify: oversold (another customer bought in the gap) ↓ Both platforms now disagree on stock levels

ShipStation's inventory model is eventually consistent. It's a cache of Shopify's inventory, not the source of truth. During high-traffic periods (Black Friday, flash sales), the sync gap is catastrophic. Multiple customers can purchase the same last unit before ShipStation learns about the first sale.

Aeion's model is strong consistency:

Commerce: payment.captured ↓ (same transaction) Fulfillment: allocate inventory → Only succeeds if stock is actually available → If not enough stock → Order rejected with "Insufficient stock" ↓ (same transaction) Inventory is locked, order is allocated

One database. One atomic transaction. Zero sync lag. Zero overselling.

How the Atomic Guard Works

ShipStation can't do this because it doesn't own the database — it polls Shopify's API. Aeion owns the database, so every allocation runs as a single atomic database operation: increment the reserved quantity, but only if on-hand stock minus what's already reserved still covers the requested amount. If it doesn't, the operation is rejected outright and the order is told "insufficient stock" immediately — no partial state, no retry logic needed.

What the atomic guard prevents:

• Two concurrent orders both read "3 units available"
• Order A allocates 3 → allocated = 3, guard passes
• Order B tries to allocate 3 → allocated becomes 6 → guard FAILS, transaction rolls back
• Order B receives "Insufficient stock" error immediately

ShipStation has no equivalent guard. The API-based approach is "optimistic" — it assumes the read is accurate, then retries on conflict. Aeion's SQL guard is "pessimistic" — it only commits if the condition is guaranteed true at commit time.

ShipStation: Expensive Carrier Rate Lookups

ShipStation routes orders using carrier rate APIs (FedEx, UPS, USPS, DHL). The "nearest warehouse" decision is implicit — ShipStation doesn't know where your warehouses are. It just gets a rate from the carrier for the shipping address, then you pick the cheapest/best option.

Problems with carrier-API routing:

• You pay for every rate quote API call
• Carrier APIs return delivery estimates, not optimal warehouse selection
• ShipStation doesn't know you have a warehouse in Phoenix serving LA customers cheaper than your NJ warehouse
• FedEx ground rates are the same regardless of which warehouse ships — you pay extra for the wrong routing choice

Aeion: Haversine Distance = Optimal Warehouse

Aeion computes the physical distance between the customer and each warehouse using the Haversine formula — a great-circle distance calculation that accounts for the Earth's curvature — then allocates to the nearest facility with available stock. No external routing API, no rate quotes. Pure math, sub-millisecond.

Example: Customer in Los Angeles (34.0522, -118.2437)

• West Coast DC, Rialto (34.0911, -117.3884): 72 km
• Central DC, Dallas (32.7767, -96.7970): 2,013 km
• East Coast DC, Newark (40.7128, -74.0060): 3,940 km

Allocation: West Coast DC wins (72 km vs 2,013 km vs 3,940 km)

Benefits:

• FedEx ground transit: 72 km → 2-3 days, ~$8
• vs shipping from Newark: 3,940 km → 5-7 days, ~$18
• Savings: ~$10/order, 50% shorter transit time

No external API calls. No rate quotes. Pure math. <1ms routing decision.

Geocoding: Free vs Expensive

If customer address has no coordinates, ShipStation uses the carrier's address validation API (paid per lookup). Aeion geocodes addresses through OpenStreetMap's free lookup service by default — no per-lookup fee, no API key to manage. For brands with heavier bulk-geocoding needs, a paid geocoding provider can be swapped in with no change to how routing works.

ShipStation: Separate Returns App + Manual Refund

ShipStation requires a separate returns app (their own or a third-party). The flow is:

1. Customer initiates return in returns app 2. Returns app sends email to warehouse 3. Warehouse staff logs into returns app 4. Staff receives item, inspects condition 5. Staff manually triggers refund in Shopify admin 6. Staff manually updates inventory in ShipStation 7. Three separate systems updated manually — errors inevitable

Condition tracking: Basic (received/not received). No per-item condition assessment.

Aeion: Native RMA → Inspection → Restock → Refund in One Flow

Aeion's RMA is a first-class record with condition tracking per item. When a return is marked received, each line item's condition determines what happens next: new or opened items are automatically restocked back into sellable inventory as an atomic inbound movement, while damaged or defective items are excluded from sellable stock and flagged for disposition. Once processed, the RMA status flips to completed and a refund workflow fires automatically — no manual step required.

Condition values: new, opened, damaged, defective, wrong_item

Event-driven refund: Completing the return automatically triggers a workflow that calls Billing to issue the refund. No manual steps. No separate app. No sync risk.

Inventory model difference:

ShipStation: You manually add items back to inventory after inspection Aeion: Condition is recorded per item. New/opened auto-restocked. Damaged items logged for supplier claims, NOT added to sellable stock.