What a Kerridge integration gives you.
Customers see accurate stock levels and pricing at checkout because Kerridge feeds the storefront on a cadence you control and stock is reconciled at order time.
Web orders are automatically captured into Kerridge, acknowledged and routed to the warehouse without manual keying, so picking and dispatch start immediately.
Trade customers' account balances and credit limits are live on the storefront, and checkout blocks orders that would exceed their terms.
Customers and your customer service team see invoices, credit notes and dispatch confirmations in the ecommerce system within hours of Kerridge generating them.
If Kerridge becomes unavailable, the integration queues orders and notifies the team, so sales are not lost and no manual backlog accumulates.
Where a Kerridge integration earns its place.
If two or more of these are true, the integration usually pays for itself quickly.
Where off-the-shelf connectors fall short.
Vendor connectors are fine for simple cases. Here's where the real ones need more.
Kerridge publishes stock, but ecommerce often needs a buffer or safety stock level to account for offline demand, manual warehouse picks or fulfilment lag. Standard connectors rarely manage reservation, hold logic or stock allocation rules between systems.
Kerridge holds tiered pricing, customer-specific terms and credit limits. Moving these accurately to ecommerce requires mapping Kerridge customer types to ecommerce segments and handling mid-transaction credit-hold enforcement that most connectors do not address.
Kerridge may reject an order due to credit hold, stock failure or account block. Standard integration tooling rarely implements fallback queues, customer notification or manual intervention workflows for these cases.
Kerridge invoices, credit notes and returns operate on different timelines from ecommerce orders. Keeping the storefront and customer-facing tracking in step without duplication or orphaned records requires careful ownership design that generic connectors do not enforce.
If Kerridge is unreachable at order time, ecommerce must decide whether to hold checkout, queue orders, or allow sales offline. Without clear fallback rules and monitoring, orders can be lost or duplicated.
Wholesale and distribution operations live on accurate inventory and customer credit; silent drift between Kerridge and ecommerce is the biggest risk, so monitoring and idempotency matter more than speed.
Where this integration sits in your estate.
Kerridge holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.
One integration architecture, any storefront. Kerridge connects through the same governed layer whatever commerce core you run.
- Stock levels and reservations
- Base and customer-specific pricing
- Customer account balances and credit limits
- Order acknowledgement and routing
- Invoices, credit notes and dispatch confirmations
- Storefront product catalog and merchandising
- Ecommerce checkout and customer session
- Shopping cart and basket
- Order placement capture
- Customer-facing order tracking and returns
Systems this integration usually sits next to.
Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.
- Magento Open Source
- Adobe Commerce
- Shopify Plus
- BigCommerce
- Other storefronts
- Warehouse management and picking systems
- Point-of-sale and branch stock
- Payment processors and settlement
- Shipping and carrier selection
- Customer support and order tracking
- Financial reporting and reconciliation
- Email and customer notifications
Not sure if this works with your stack?
Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.
The data flows we wire.
Each flow has a direction and an owner. We agree both before a line of code is written.
How iWeb configures the integration around your business.
Same method on every integration. The decisions come before the code.
- 01Data flow design and ownership
iWeb maps which system owns each field (stock level, pricing tier, customer credit, order status), when it updates, and how it reconciles if the systems diverge.
- 02Exception and fallback handling
iWeb builds queuing, retry logic and manual-intervention workflows for order rejections, credit holds, stock failures and Kerridge unavailability so ecommerce and fulfillment continue to operate.
- 03Monitoring and alerting
iWeb sets up dashboards and alerts so your team sees stock sync delays, pricing mismatches, rejected orders and invoice backlog in real time.
- 04Testing and rollback
iWeb validates data parity between Kerridge and ecommerce before launch, establishes rollback paths if issues emerge, and sets performance baselines so integration lag does not break checkout.
Who owns what.
The single most important table in any integration. One system owns each field; everything else reads it.
Built Kerridge integrations before
iWeb understands how Kerridge operates in wholesale and distribution estates and how ecommerce needs to connect to stock, pricing, accounts and order processing. We have designed and supported integrations that keep inventory, customer credit and invoice reconciliation accurate across both systems.
What we test before launch.
Every one of these is rehearsed before a customer ever sees the integration.
Common risks and where they bite.
We name these on day one. A risk written down is a risk you can plan around.
If the integration feed from Kerridge runs infrequently or is delayed, customers can place orders against out-of-stock items or old pricing, leading to oversell or margin loss. Silent delays in the feed are especially dangerous.
An order may be accepted by ecommerce but rejected by Kerridge due to credit hold, stock failure or account block. Without clear fallback and customer notification, the order is lost and the customer receives no acknowledgement.
If the integration retries without idempotency checks, orders can be duplicated in Kerridge. Conversely, if a network fault occurs between ecommerce capture and Kerridge receipt, the order can disappear entirely.
Kerridge invoices, credits and ecommerce refunds operate on separate timelines. Without careful tracking of which system is the source of truth for each document type, invoices and credits can be lost, duplicated or mismatched.
Customer master data, account balances and credit limits live in Kerridge but are needed on the storefront. If syncing is incomplete or infrequent, some customers see old balances or incorrect credit limits, leading to failed checkouts or unauthorized orders.
If ecommerce tries to fetch live stock or check credit at order time and Kerridge is offline, checkout hangs or fails. Without fallback logic to queue orders and notify the team, sales stop and manual backlog piles up.
Relevant services and sectors.
Common questions about Kerridge integrations.
How often does stock sync from Kerridge to ecommerce?
iWeb configures the stock feed cadence based on your fulfillment speed and product mix. Fast-moving stock typically syncs every 15-60 minutes; slower lines may sync daily. The integration also publishes real-time stock adjustments if Kerridge supports event streaming. Monitoring alerts you if a sync is delayed.
What happens if a customer's credit limit is exceeded at checkout?
The integration fetches the current credit limit and balance from Kerridge at order time. If the order would exceed the limit, ecommerce either blocks the order, triggers a manual review workflow, or holds the order in a queue for credit approval. The rules are configured based on your credit policy.
How are orders captured into Kerridge?
Web orders are transmitted from ecommerce to Kerridge in real time or in a batch, depending on your integration design. Kerridge acknowledges receipt, applies validation rules (credit, stock, account status) and routes the order to the warehouse. If Kerridge rejects the order, iWeb logs the reason and triggers a fallback or manual intervention workflow.
What happens if Kerridge is offline when an order is placed?
iWeb configures a fallback behaviour: the integration can queue the order in a staging system, allow ecommerce to capture it locally and retry sending to Kerridge later, or hold checkout with a retry message to the customer. The choice depends on your tolerance for offline orders and reconciliation complexity. Alerts notify your team immediately.
How do invoices and credit notes flow back to the customer?
Kerridge generates invoices and credit notes as orders are picked and dispatched. The integration pulls these documents and publishes them to ecommerce, where customers can view them in their account or via email. The integration also reconciles these documents with the original order to ensure nothing is orphaned.
How are returns and refunds handled?
Returns can be initiated in ecommerce or in Kerridge. The integration captures the return reason and quantity, sends a request to Kerridge to generate a credit note, and syncs the credit back to the customer's account. The flow ensures the customer balance is updated and the warehouse is notified of the return.
How do you prevent duplicate orders in Kerridge?
The integration implements idempotency keys and order-deduplication logic so that network retries or system failures do not result in the same order being created twice. Kerridge is configured to reject duplicates based on the ecommerce order ID, and monitoring alerts you if a duplicate is attempted.
How is customer-specific pricing applied at checkout?
The integration maps each customer record in ecommerce to their Kerridge customer type or pricing tier. At checkout, the integration queries Kerridge for the applicable price and discount rules and applies them in real time. This ensures trade customers always see their negotiated rates.
Who owns the stock buffer between Kerridge and ecommerce?
iWeb defines whether the buffer is managed in Kerridge (via reserved stock), in ecommerce (via a local hold), or shared. Ownership is documented and monitored so that oversell is prevented and stock is not double-counted. A typical approach is to hold a small buffer in ecommerce and reconcile it daily against Kerridge.
How do you handle price and stock changes mid-week?
The integration can support real-time or scheduled price and stock updates from Kerridge to ecommerce. If you need changes to go live immediately, iWeb configures event-driven syncs; if batch is acceptable, the integration can run on a schedule. Monitoring tracks whether updates are applied on time.
What happens if order acknowledgement from Kerridge is delayed?
The integration tracks acknowledgement status and sets time-based alerts. If an order is not acknowledged within a threshold (e.g., 1 hour), iWeb escalates the issue to your team. The order remains visible to the customer with a 'pending' status until Kerridge acknowledges it.
How do you test the integration before going live?
iWeb runs data-parity checks to ensure stock, pricing, customer accounts and orders match between Kerridge and ecommerce. Test orders are placed end-to-end to verify capture, acknowledgement, picking and invoicing. Fallback scenarios (Kerridge offline, credit rejection, stock failure) are exercised to confirm alerts and queue handling work correctly.
How does the integration handle VAT and tax on orders?
Kerridge is configured with tax codes and rules. When an order is sent from ecommerce, the integration ensures tax is calculated correctly and passed to Kerridge so the invoice reflects the right amount. Invoices generated by Kerridge include tax and are reconciled in finance.
What monitoring and dashboards does iWeb provide?
iWeb builds dashboards showing stock sync status, pricing update lag, order capture and acknowledgement rates, rejected orders, invoice backlog and Kerridge availability. Alerts notify your team of delays, failures or anomalies so issues are caught before they impact customers.
Other erp · finance integrations.
Adjacent integrations in the same category. Same shape of work, different vendor.



