What happens to return events when the network goes offline?

Connectivity fails at real sites. The important question is not whether a network interruption can happen; it is what the equipment, participant interface and receiving system do while it lasts. An integration that works only on a reliable office connection is not ready for a public return point.

Decide what can continue locally

For each return state, record whether the machine may accept an item without an online response. A local acceptance event should have a stable ID, device identity, event time and rule version. The participant interface must not imply that an external reward was issued if the reward service has not confirmed it. Some programmes may require an online decision and therefore need a clear unavailable state.

Agree the delivery contract

The sender and receiver should document authentication, event schema, acknowledgement, retry window and maximum queue behavior. An event can be delivered more than once after a timeout, so the receiver must use its stable ID to prevent a second business action. Device time and receipt time should remain separate; delayed delivery must not rewrite when the physical return occurred.

Reconcile after recovery

Compare the equipment event log with the receiver’s accepted records. Investigate missing, duplicate and rejected messages; do not silently mark them as successful. If a reward is part of the programme, its ledger has a separate acknowledgement and correction path. Physical material handover is another record again.

Tell the visitor only what is confirmed

During an outage, the equipment may know that a container entered its selected physical path while the external programme has not yet confirmed a benefit. The interface should distinguish those states. A vague “success” message can create a dispute that neither the site operator nor the reward team can easily resolve. Decide whether the visitor receives a reference for a pending transaction and which organisation can investigate it.

Put limits around the queue

Local storage for undelivered events is finite and needs an explicit policy. Define what happens when the configured limit or age is reached, who gets an alert and whether the station continues to accept items. Test a long interruption, not only a brief cable pull. After service returns, compare the recovered event count and IDs with the receiving system; do not treat a green connection indicator as proof that every event was processed.

Include these cases in the interface acceptance plan and name the person who investigates failures. Discuss a RECYNEX Connect scope with your current API and device list, or use the integration checklist to prepare the conversation.