IRIS Commerce Eshop integration: payments and order-state updates

IRIS Commerce reaches checkout through an appropriate provider and requires a verified payment-result workflow.

DIAS distinguishes IRIS services and the commercial online-store scenario. An Eshop integration is not established simply by displaying a personal phone number or a generic transfer instruction. Select a supported route from the merchant's payment provider, confirm activation and follow its current documentation. Terms and technical behavior need checking against the actual account. This distinction makes the payment understandable to the customer and lets the store associate the result with the correct purchase, rather than relying on manually interpreted transfer notes.

Preserve the amount, currency and reference related to the payment process. Customers follow the provider's available route while the store receives or verifies results as documented. Design what appears when a user delays, abandons the flow or returns without final confirmation. Only the state permitted by the payment rule should trigger dispatch. ERP and accounting reconciliation should retain the same reference to avoid manual matching from unclear comments. Customer service also needs to see whether the order awaits payment or whether a successful payment awaits an internal update.

Confusing different IRIS products creates incorrect expectations about automation. State exactly which account service is integrated and how outcomes are verified. If the result is missing, keep an appropriate pending status rather than displaying unverified success. Provide a clear next step for the customer and a reconciliation queue for staff. Duplicate notifications, amount changes and later commercial cancellations need separate handling. Confirm current terms with the provider rather than borrowing historical limits from another service, and keep operational explanations distinct from legal advice about payment obligations.

For IRIS Commerce, define the service actually activated and the method for associating results. Checkout messaging should describe that route without confusing other IRIS products. Keep a stable order reference even when the shopper delays or returns later. Warehouse staff see a confirmed commercial state rather than a guess based on browser navigation. Preserve the same reference for ERP reconciliation. When a mismatch occurs, investigate before giving the customer another payment instruction. This provides a clear operational distinction between awaiting a payment and awaiting an internal status update.

A food store adds IRIS Commerce as a distinct payment method. The purchase uses a reference and amount for the provider's supported route. If the shopper leaves before completion, dispatch does not start. A later verified result uses the same reference to find the appropriate order. Repeated updates must not charge or release it again. ERP receives consistent information so accounting reconciliation does not depend on an unclear comment. Customer support can inspect the transaction relationship while keeping other IRIS products and manually interpreted transfers outside this defined workflow.

Test abandonment, delayed updates and repeated results through the actual provider route. Compare amount, reference and purchase state before releasing warehouse work. A modified order must not reuse old payment data indiscriminately. Staff approve customer information and pending-payment review procedures. Check the ERP association so the same payment is not recorded twice. Document the exact service, active account capabilities and owner for instruction or commercial-term changes. Acceptance should also demonstrate that an unresolved result remains visibly pending rather than automatically becoming successful because the browser returned.