Eshop integration with Epsilon Net PYLON: workflows, prerequisites and testing

Integrate the store with Epsilon Net PYLON around a defined workflow and the installation's available interface. For PYLON, begin with the exact application, version and enabled modules: the family name does not describe a single installation. Store integration organises products, identifiers, inventory and orders through the available interface.

For PYLON, begin with the exact application, version and enabled modules: the family name does not describe a single installation. Store integration organises products, identifiers, inventory and orders through the available interface. The key decision concerns which channel reserves inventory and when. Where a physical shop and marketplace also operate, one sale must reduce the appropriate available quantity without another channel creating a duplicate commercial record.

PYLON flex presents an e-shop connector for products, inventory, and orders through Connectivity API. Its integration family also includes courier and Skroutz functions, which are separate workflows from the basic catalogue. We do not assume that PYLON flex features apply unchanged to every older PYLON installation. Epsilon Smart is also a separate product requiring its own integration design.

A homeware chain sells a lamp both online and at its till. The connector uses a shared SKU mapping and agreed availability policy. After a physical-store sale, an online update must not replace a newer balance with an older file. The online order is transmitted with a distinct channel reference and the appropriate commercial entry type. If courier integration is added later, its voucher belongs to the shipment and does not create another sale.

An important failure scenario occurs when an item is sold in the physical shop before online inventory has been updated. Keep the external reference and confirmed destination ID before retrying. Separate access failure, business rejection and an unknown outcome. An operator must be able to inspect the relevant record and resolve its status without replaying completed steps. Agree which fields may appear in logs and who handles unresolved cases.

Test a simultaneous sale on two channels, an unmapped product, and a failed update. For each case record the expected source data, destination record and customer-visible state. Include one denied-permission case and one interrupted response. Re-run a previously confirmed event and check that its business effect is unchanged. The acceptance record should identify the responsible team and the evidence required to close any discrepancy.

The initial discovery should confirm: Exact PYLON product/version and available Connectivity API; Access to the enabled installation modules; Available-stock policy and a test environment. Before launch, document the mapping for PYLON catalogue/inventory → store → Online sale → correct commercial document type → Order confirmation → cross-channel reconciliation. Assign responsibility for access renewal, monitoring and correction. A change to product configuration or the agreed business rule should trigger targeted regression checks. Begin with this defined workflow; add another channel only after its ownership and acceptance cases are clear.