Skip to main content
Talk to an expert
Hyvä Commerce ecommerce platform

Hyvä integration for ecommerce

Headless Magento storefront that keeps operations governed cleanly. Hyvä is the commerce platform layer. iWeb connects it with ERP, PIM, OMS, payments and fulfilment so products, stock, pricing, orders and customers stay in sync without the frontend becoming a hidden system of record. Integrates with the ERP, PIM, OMS and operational systems commerce teams already run.

Also searched as: commerce platform, storefront, online store, shop platform, commerce engine.

Your systemsiWeb integration layerHyvä
Talk to an expertSee the estate map ↓
Works with - ERP (SAP, NetSuite, Deltek) · PIM (Salsify, Informatica, Contentserv) · OMS (Flexport, custom) · Search (Elasticsearch, Algolia, Klevu) · Payments (Adyen, Stripe, Square)
On this pageGet a brief reviewed
01 · What you get

What a Hyvä integration gives you.

Faster storefront iteration

Decoupling the Hyvä frontend from Magento backend logic means frontend teams can move fast on design, checkout and experience without ERP deployment cycles.

Clear ownership and governance

iWeb maps exactly which system owns product data, pricing, stock, customers and orders. Teams know where to go to change rules and where failures come from.

Safer replatform from Adobe Commerce

Hyvä sits on Magento Open Source, so migrating from Adobe Commerce is technically lighter. iWeb handles the data sync, ownership transition and rollback safety.

Multi-channel readiness

Once Hyvä connects to the same ERP, PIM and OMS as other channels, adding B2B, marketplaces or branches becomes a matter of configuring new channels, not rebuilding integrations.

Reduced technical debt

Hyvä's decoupling means fewer hidden integrations embedded in themes or custom extensions. iWeb's API-first integration layer becomes the single source of truth for system connections.

02 · When it's worth it

Where a Hyvä integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Migrate from Adobe Commerce / Magento monolith to Hyvä Other storefronts without losing ERP or PIM sync
Launch new Hyvä store connected to an existing ERP, PIM and OMS estate
Add Hyvä as a parallel storefront alongside other sales channels, managed by the same OMS and fulfilment layer
Rebuild checkout, cart and customer experience on Hyvä while keeping order capture and customer account logic unified
Replace theme layer on Magento Open Source with Hyvä rendering while maintaining backend integrations
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

No native ERP or OMS integration

Hyvä is a frontend layer. It does not natively connect to ERP systems for stock, pricing or order capture. Custom integration builds or middleware are required to move data in and out.

Order handoff to ERP requires custom logic

Hyvä captures web orders but does not have native order acknowledgement, routing or exception handling. That logic must be defined and built in the ERP or OMS integration layer.

No built-in multi-channel order orchestration

Hyvä is a single storefront. If orders must be routed across branches, dropship locations or alternative fulfilment paths, that logic lives in OMS or ERP, not Hyvä.

Stock availability depends on upstream sync

Hyvä displays stock pulled from ERP or OMS. If that sync breaks or lags, the storefront shows stale availability and oversell risk increases. The refresh frequency and fallback behaviour must be designed explicitly.

Pricing and promotions require careful ownership

Hyvä can display price from ERP or PIM, or apply rules in the frontend. If both layers hold pricing logic, reconciliation and override conflicts need active governance.

04 · The real work

Frontend speed gains evaporate if stock and pricing are fetched synchronously from slow ERP endpoints, so cache strategy and fallback rendering matter as much as the decoupling itself.

05 · Where it sits

Where this integration sits in your estate.

Hyvä is the commerce platform - the customer-facing experience, catalogue, checkout and account area. The iWeb integration layer wires it into the ERP, PIM, OMS, WMS and payments systems it depends on. The estate map helps agree ownership before anything is built.

A storefront is a system, not an island. Hyvä earns its keep once ERP, PIM and OMS are wired in behind it.

Customer-facing commerce
Commerce platform
Hyvä
Commerce frontend and storefront rendering layer
  • Checkout flow and cart experience
  • Storefront customer session and authentication
  • Product browse and search consumption
  • Payment capture initiation
iWeb integration layer
Systems behind the platform
Systems it depends on
ERP (SAP, NetSuite, Deltek)PIM (Salsify, Informatica, Contentserv)OMS (Flexport, custom)Search (Elasticsearch, Algolia, Klevu)Payments (Adyen, Stripe, Square)WMS (NetSuite Openair, 3PL API)CRM (Salesforce, HubSpot)
  • Product catalogue and merchandising display
  • Stock availability status
  • Pricing and promotions display
  • Customer account visibility
  • Order and payment status
  • Returns and refund requests
Connected neighbours
Integration layer
Magento Backend
API source for product data, inventory sync, order validation and customer master
Integration layer
ERP
System of record for stock, pricing, orders, invoices, customer accounts and finance
Integration layer
PIM
Product attributes, descriptions, images, categories and enrichment fed to Magento and consumed by Hyvä
Integration layer
OMS
Order routing, fulfilment orchestration, returns and customer service visibility
Integration layer
Search Engine
Indexed catalogue, facets and merchandising rules consumed by Hyvä discovery
Integration layer
Payments
Authorization, capture and settlement; tokenisation for returning customers
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb wires Hyvä into whatever ERP, PIM, OMS, WMS, payments and operational systems your estate already runs.

Systems behind the platform (examples)
  • ERP (SAP, NetSuite, Deltek)
  • PIM (Salsify, Informatica, Contentserv)
  • OMS (Flexport, custom)
  • Search (Elasticsearch, Algolia, Klevu)
  • Payments (Adyen, Stripe, Square)
  • WMS (NetSuite Openair, 3PL API)
  • CRM (Salesforce, HubSpot)
Not sure?

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.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into ERP / OMS & SEARCH / MERCHANDISING
←From ERP / PIM & ERP / OMS & PAYMENTS
↔BOTH WAYS
Product catalogue and pricing: Product attributes, descriptions, images, categories and pricing flow from ERP or PIM into Hyvä storefront via API or data feeds
Hyvä renders the catalogue for customers without storing product truth itself.
Stock and availability: Stock levels and product availability are fetched from ERP or OMS systems
Hyvä displays stock status and availability windows at checkout without owning stock logic.
Web orders and customer data: Customer registration, basket abandonment, orders and account changes flow from the Hyvä storefront into ERP or OMS for acknowledgement, fulfilment, invoicing and customer service.
Authorisation and capture status: Payment authorisation, capture confirmation and refund status return from the payment provider to Hyvä checkout and customer account, keeping order status in step.
Indexed catalogue: Product data, attributes and updates flow from PIM or ERP into search indexes
Hyvä consumes ranked, faceted and merchandised results to power discovery and search pages.
Customer consent and marketing: Customer profiles, email consent, preferences and event data sync between Hyvä customer accounts and CRM or marketing automation platforms for segmentation and campaign triggers.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Design the decoupling

    iWeb maps which Magento backend logic, ERP functions and PIM responsibilities are needed by Hyvä and which can be deferred to operational systems. This clarity prevents both over-engineering the frontend and losing critical business logic.

  2. 02
    Build the data flows

    iWeb connects Hyvä APIs to ERP, PIM, OMS, search and payments systems. Product catalogue, stock, pricing, orders, customers and payment status are kept in sync with named owners and automatic exception handling.

  3. 03
    Manage the Magento backend transition

    iWeb designs how Hyvä frontend and Magento backend coexist during migration and can operate independently. Custom extensions, configurations and data are either kept in sync or cleanly separated based on business need.

  4. 04
    Set up observability and alerting

    iWeb builds dashboards and alerts for product sync lag, stock freshness, order capture delays and payment exceptions. Teams see failures in real time and know which system to page.

  5. 05
    Plan testing and rollback

    iWeb defines pre-launch checks for data parity between Hyvä and upstream systems, fallback rendering if APIs fail, and rollback paths if integrations break during peak traffic.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataProduct catalogue, attributes, descriptions, images, categories
Source / ownerPIM or ERP
Maintained byProduct and merchandising teams
NotesHyvä consumes and displays catalogue data from upstream systems. Storefront does not own product truth.
DataStock levels and availability
Source / ownerERP or OMS
Maintained byWarehouse and inventory teams
NotesHyvä fetches and displays stock status. Real-time or cached updates must be configured based on business tolerance for lag.
DataBase and promotional pricing
Source / ownerERP or PIM
Maintained byPricing and revenue teams
NotesHyvä can display pricing from ERP or apply promotions in the frontend. Clear ownership and override rules prevent conflicts.
DataWeb orders and order status
Source / ownerERP or OMS
Maintained byOperations and customer service teams
NotesHyvä captures order intent. ERP or OMS acknowledges, routes, fulfils and invoices. Hyvä consumes status updates for customer visibility.
DataCustomer accounts and profiles
Source / ownerERP or CRM
Maintained byCustomer service and marketing teams
NotesHyvä holds storefront customer records. These must be linked to and kept in sync with ERP customer master and CRM profiles.
DataSearch indexes and merchandising rules
Source / ownerSearch platform (fed by PIM)
Maintained bySearch and merchandising teams
NotesHyvä consumes indexed results. Search engine holds rankings, facets and merchandising rules. iWeb monitors index freshness and relevance.
DataPayment authorisation and settlement
Source / ownerPayment provider
Maintained byFinance and payment teams
NotesHyvä initiates payment requests. Provider handles auth, capture, refund and reconciliation. Hyvä stores tokenised reference for customer session only.
10 · Experienced integrator

Built this before

iWeb has guided multiple estates from Adobe Commerce monolith to Hyvä headless rendering, keeping ERP, PIM, OMS and payment integrations live throughout. We understand the operational tensions between frontend speed and stock freshness, order handoff safety and merchant flexibility, and how Magento backend constraints shift when the frontend decouples.

iWeb has migrated live ecommerce traffic from Adobe Commerce to Hyvä without breaking orders, stock or customer accounts
iWeb understands how Hyvä APIs interact with Magento Open Source backend, ERP systems, PIM platforms and OMS layers, and which logic belongs where
iWeb designs stock and pricing refresh strategies so Hyvä rendering stays fast while operational data stays accurate and reconcilable
iWeb knows where Hyvä integrations fail silently (cached data, API timeouts, mismatched customer records) and builds exception handling and observability upfront
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Product data parity: verify 100% of attributes, images and descriptions synced from Magento to Hyvä; check for missing or truncated fields after full catalogue refresh.
Stock freshness: confirm stock displayed on Hyvä matches ERP snapshot within acceptable lag (e.g. 5-15 minutes); test fallback display if ERP API fails.
Order capture end-to-end: place test orders in Hyvä, verify order record and line items arrive in ERP within SLA, check acknowledgement and error queues for failures.
Customer account linkage: register new customer in Hyvä, confirm sync to ERP; log in with existing ERP customer, verify order history and credit data appear in Hyvä.
Pricing and promotions: apply discounts in Magento backend and Hyvä, verify correct totals at checkout and no double-discounting in ERP invoicing.
Payment processing: test auth, capture and refund flows with sandbox payment provider; confirm payment status updates Hyvä order and ERP invoice.
Rollback and recovery: simulate stock API failure, confirm Hyvä serves cache gracefully; simulate order capture failure, verify exception queue and retry logic work.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Stock availability lag during peak

If stock is fetched from ERP on every page load, slow ERP responses stall Hyvä rendering. If cached, stale stock causes oversell. iWeb designs refresh intervals and fallback behaviour to prevent both.

Order capture breaks in ERP

Hyvä sends orders to ERP or OMS, but if the handoff logic is weak, orders can be duplicated, lost, or stuck in exception queues. Poor observability means lost time before anyone notices.

Product data divergence between PIM and storefront

If PIM and Hyvä don't sync on the same schedule, or if merchandisers apply changes in both places, product descriptions, images or categories can be inconsistent. Unowned reconciliation drifts over time.

Customer account mismatches between Hyvä and ERP

Hyvä customer accounts can be created independently of ERP customer master. If accounts are not linked and kept in sync, invoicing, order history and credit limits become unreliable.

Pricing override conflicts

If both Hyvä and ERP hold pricing logic (e.g. discounts in the storefront, base prices in ERP), reconciliation is complex. Silent override rules can cause margin or compliance problems.

Replatform from Adobe Commerce gets stuck

Moving data and integrations from Adobe Commerce to Hyvä is risky if downstream systems aren't prepared to accept both systems in parallel. Cutover timing and validation must be explicit.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about Hyvä integrations.

Does Hyvä need Magento backend running behind it?

Yes, Hyvä is a frontend rendering layer that connects to Magento Open Source backend. iWeb manages the integration so Magento handles data and business logic while Hyvä renders the storefront. The backend can be on-premise, in Magento Cloud, or hosted separately.

How do we migrate from Adobe Commerce to Hyvä without breaking orders or stock?

iWeb runs both systems in parallel during cutover, keeps ERP and OMS integrations live in both, validates data parity, then switches traffic to Hyvä once all checks pass. Rollback paths are defined before launch.

Can Hyvä handle multi-channel orders if we sell on marketplaces or branches too?

Hyvä is a single storefront channel. Multi-channel order orchestration, stock allocation and routing live in OMS or ERP. iWeb connects Hyvä as one channel alongside others so all orders flow through the same fulfilment and accounting layer.

How quickly does Hyvä get stock updates from the ERP?

iWeb designs stock refresh timing based on business risk appetite. Real-time APIs are ideal but carry ERP performance cost. Cached updates (every 5-15 minutes) are typical for lower-volume sites. The chosen approach and fallback behaviour for API failures must be explicit before launch.

Where does pricing live - in Hyvä, Magento backend, or ERP?

iWeb maps pricing ownership based on your business model. Base prices typically live in ERP, promotional pricing can live in Magento backend or Hyvä, and discounts can be applied at checkout. Conflicts are prevented by clear ownership and no double-application of rules.

What happens to customer accounts when we go live on Hyvä?

iWeb can link existing Magento customer records to Hyvä without losing account history. New customers created in Hyvä are synced to ERP or CRM for credit, order history and marketing. Account identity and profile ownership must be defined upfront.

Can Hyvä work with third-party payment providers?

Yes, Hyvä integrates with major payment providers via APIs. iWeb manages the integration, tokenisation, 3DS / SCA handling and reconciliation back to ERP. Payment logic stays in the provider; Hyvä just captures and passes auth status.

How do we know if Hyvä is properly synced with the PIM?

iWeb sets up dashboards that show product freshness (when PIM data last updated the storefront), missing attributes, image sync lag and category drift. Alerts fire if sync breaks. Daily or weekly reconciliation reports confirm data parity.

What if an order fails to reach the ERP after checkout?

iWeb builds exception handling so failed orders are captured in a queue, retried automatically with backoff, and escalated to ops if they still fail. Teams get alerts with order details and can manually intervene before SLA breaks.

Can we A/B test checkout or pricing changes on Hyvä without touching Magento?

Yes, Hyvä's frontend isolation means checkout and UX changes can be deployed independently. Pricing or logic changes that affect ERP sync (e.g. discount rules, tax calculation) still need backend coordination to avoid conflicts.

How do we handle returns and refunds across Hyvä and the ERP?

iWeb connects Hyvä customer return requests to OMS or ERP. Refund triggers and status updates flow back to the storefront. Return authorisation, credit note generation and stock re-receipt are owned by the operational system, not Hyvä.

What's the performance impact of fetching stock on every page load?

Real-time stock APIs are slow if ERP response times are poor. iWeb caches stock locally, refreshes on intervals (e.g. every 10 minutes for fast-moving goods), and serves stale cache with a warning if the fetch fails. The trade-off between freshness and speed is designed explicitly.

Can Hyvä work alongside a native Magento storefront during migration?

Yes, both can run on the same Magento backend during transition. iWeb keeps integrations live in both, ensures stock and order data don't split, and handles traffic switchover when Hyvä is ready. This reduces migration risk.

How do we monitor and alert on integration health between Hyvä and operational systems?

iWeb builds observability into the integration layer. Metrics tracked: order capture lag, product sync freshness, stock fetch errors, payment processing time, ERP acknowledgement rate. Alerts fire on thresholds before customers see problems.

14b · Same category

Other commerce platforms integrations.

Adjacent integrations in the same category. Same shape of work, different vendor.

Commerce platforms
Next step

Have a Hyvä integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →