Unattended Terminals

This page is currently only available in English.

This page covers the unattended add-on to direct OPI. Most attended integrations do not need it. In Swiss self-service estates, unattended terminals are usually integrated either directly over OPI with a dedicated controller or through MDB. Only keep reading here if your terminal profile requires terminal-side delivery confirmation through DeliveryBox.

Quick Links

When This Page Applies

This page is relevant when:

• the terminal is used in vending, parking, ticketing, kiosk, locker, fuel, or similar self-service environments
• the terminal profile expects DeliveryBox handling over OPI
• the unattended controller, not the terminal alone, knows whether delivery really happened

For a normal attended checkout or unattended without DeliveryBox logic, you usually do not need any of this.

What DeliveryBox Actually Does

DeliveryBox is the OPI callback used when the terminal wants confirmation that the product or service was actually delivered after authorisation. That changes the responsibility boundary:

• authorisation success is no longer the whole story
• payment and delivery must stay linked
• the unattended controller becomes part of the final payment outcome

Typical Unattended Flow

1. The customer selects a product or service on the unattended system.
2. The unattended controller starts the OPI payment.
3. The terminal performs cardholder interaction and authorisation.
4. If authorisation succeeds, the terminal sends a DeviceRequest for OutDeviceTarget="DeliveryBox".
5. The unattended controller attempts delivery.
6. The unattended controller answers with a matching DeviceResponse.
7. The terminal completes, cancels, or reverses the payment based on the delivery result.

DeliveryBox request

<?xml version="1.0" encoding="utf-8"?>
<DeviceRequest WorkstationID="UVM"
               RequestID="3001"
               RequestType="Output"
               xmlns="http://www.nrf-arts.org/IXRetail/namespace">
  <Output OutDeviceTarget="DeliveryBox" />
</DeviceRequest>

Delivery Result Models

Successful delivery

Return Success only when the product or service was actually delivered.

<?xml version="1.0" encoding="utf-8"?>
<DeviceResponse WorkstationID="UVM"
                RequestID="3001"
                RequestType="Output"
                OverallResult="Success"
                xmlns="http://www.nrf-arts.org/IXRetail/namespace">
  <Output OutDeviceTarget="DeliveryBox" OutResult="Success" />
</DeviceResponse>

Failed delivery

Return Failure if delivery did not happen. The terminal should then cancel or reverse the payment instead of completing it.

<?xml version="1.0" encoding="utf-8"?>
<DeviceResponse WorkstationID="UVM"
                RequestID="3001"
                RequestType="Output"
                OverallResult="Failure"
                xmlns="http://www.nrf-arts.org/IXRetail/namespace">
  <Output OutDeviceTarget="DeliveryBox" OutResult="Failure" />
</DeviceResponse>

Delivery still in progress

Some unattended terminal profiles support Busy when the machine is still delivering and cannot yet return a final result.

<?xml version="1.0" encoding="utf-8"?>
<DeviceResponse WorkstationID="UVM"
                RequestID="3001"
                RequestType="Output"
                OverallResult="Busy"
                xmlns="http://www.nrf-arts.org/IXRetail/namespace">
  <Output OutDeviceTarget="DeliveryBox" OutResult="Busy" />
</DeviceResponse>

Use Busy only if the target terminal profile supports it. The terminal may repeat the DeliveryBox request until the controller returns a final result.

Partial delivery

Some unattended terminal profiles may support partial delivery. In that case, the unattended controller can return the amount actually delivered.

<?xml version="1.0" encoding="utf-8"?>
<DeviceResponse WorkstationID="UVM"
                RequestID="3001"
                RequestType="Output"
                OverallResult="Success"
                xmlns="http://www.nrf-arts.org/IXRetail/namespace">
  <Output OutDeviceTarget="DeliveryBox" OutResult="Success">
    <TotalAmount Currency="CHF">12.50</TotalAmount>
  </Output>
</DeviceResponse>

Use this only if the terminal profile explicitly supports it. The delivered amount must never exceed the authorised amount.

Testing and Recovery

For unattended integrations, test the normal attended flow first and then extend it with unattended-specific behaviour.

Focus especially on:

• correct DeliveryBox request handling
• success only after real delivery
• failure when nothing was delivered
• timeout behaviour
• repeated requests if Busy is supported
• partial delivery only where supported
• proof that payment and delivery stay linked after interruptions

For recovery, confirm:

• whether payment was authorised
• whether delivery happened
• whether delivery failed or remained unknown
• whether logs and stored references prove the final outcome

Loss of communication does not automatically explain either the payment result or the delivery result. Both sides must stay traceable.

When to Keep Unattended Separate From the Main Flow Docs

For most teams, unattended should be treated as an add-on rather than the default reading path.

Keep the standard flow set clean first:

• sale
• refund
• receipt handling
• device callbacks
• close day
• recovery after interrupted payments

Then add unattended delivery handling only if the target terminal profile really needs it.

If you do not want terminal-side delivery confirmation logic inside your POS, consider the Nexi OPI Proxy for its validated proxy-mode unattended scope or MDB where that is the real integration boundary.