7.16 PaymentDeviceType definition

7.16.1 Overview

The PaymentDeviceType provides information about a payment device. It is formally defined in Table 50.

7.16.2 ObjectType definition

The 2:Identification Object provides Properties describing the identification of the payment device (see 7.2 for details).

The string-part of the DisplayName of Objects of this ObjectType shall be the 2:ProductInstanceUri defined in the 2:Identification Object. This simplifies identifying in the Events of the VendingAuditEventType which payment device has generated the Event, as the 0:SourceName of the Event is the string-part of the DisplayName.

The mandatory Property IsEmulated indicates if the Object is just an emulation. When set to "true", it indicates that the Object of PaymentDeviceType is just an emulation representing the payment device, and the payment device itself provides an OPC UA Server with an instance of PaymentDeviceType. In that case, no Events of VendingAuditEventType are generated, and consumers of those Events need to subscribe to the OPC UA Server of the payment device for those Events. This is used in a payment service providing information about the payment device, but the payment device has its own OPC UA Server. When set to "false", it indicates that this Object is not emulated and generates Events of VendingAuditEventType. This is used in a payment service where the payment device does not have an OPC UA Server and in the payment device if the payment device has an OPC UA Server. In 6.2.2 more descriptive text is given.

The mandatory Status represents the current status of the payment device (see 8.21 for details). A payment device taking physical assets of value (e.g., coins, bills, and tokens) provides the information about the physical assets it supports in the SupportedAssetList Property. The list shall be in ascending order by the Amount, not considering the Currency. If no physical assets of value are taken, the optional SupportedAssetList shall not be provided. For coin changers the SupportedAssetList is the list of accepted coins and tokens, as for bill validators is the list of bills and tokens handled.

Note: Tokens are managed the same way as cash, but the Currency of the PriceDataType shall use 000 as NumericCode and 0 as Exponent.

The SupportedAssetListVersion provides the current version of the SupportedAssetList. Clients may cache the SupportedAssetList and only access it after reconnect, if the SupportedAssetListVersion has changed. Therefore, each change in the SupportedAssetList shall change the SupportedAssetListVersion. The same SupportedAssetListVersion shall only be used if the SupportedAssetList is identical to the content of the previous SupportedAssetList using the same SupportedAssetListVersion.

A payment device taking physical assets of value (e.g., coins, bills, and tokens) may have two places where to store those assets.

The cashbox (coins) or stacker (bills) stores the assets and will be emptied by the technician. Typically, the amount of value in the cashbox or stacker is not known. A VendingAuditEvent (see 7.27) gets generated when a new value is added to the cashbox or stacker. Therefore, no information on the amount of value in the cashbox or stacker is provided by the PaymentDeviceType.

The tube (for coins) or recycler (for bills) buffers the assets, so that they can be returned as change, payback or when the user cancels the order or requests a refund. Those buffers have different slots to store different types of coins, bills, or tokens. The information about the general setup of those slots is provided in the SlotConfigurationList. Each entry of the list of SlotConfigurationDataType (see 8.20) consists of two indexes, the first one identifying the slot and the second the asset going to the slot as an index into the SupportedAssetList. Several entries of the SupportedAssetList may be assigned to the same slot index. In this case, the Amount and Currency shall be identical. Several slot indexes may have the same entries of the SupportedAssetList assigned to them. The slot indexes shall start with 0 and increase without interruptions (0, 1, 2, 3, …). As special index -1 is used in the SlotConfigurationList to indicate that the referenced entry of the SupportedAssetList is directly moved into the cashbox / stacker. The SlotConfigurationList shall have at least one entry for each entry of the SupportedAssetList.

In the following, an example is given.

SupportedAssetList = { (10, € cent), (50, € cent), (50, € cent), (100, € cent), (100, € cent) }

SlotConfigurationList = {(-1,4), (0,0), (1,0), (2,1), (2,2), (3,3), (4,3) }

In the example, the machine accepts coins of 10, 50, and 100 € cent. It distinguishes between two different types of 50 and 100 € cent coins.

The buffer contains 5 slots, the first two (index 0 and 1) taking 10 € cent coins, another one (index 2) taking all 50 € cent coins, and two more taking 100 € cent coins of one type, whereas the second one never goes into the buffer but always directly into the cashbox (index -1, first entry in the SlotConfigurationList).

An Object emulating a payment device (IsEmulated = "true") should not provide the SupportedAssetList, SupportedAssetListVersion, and SlotConfigurationList.

An Object not emulating a payment device (IsEmulated = "false") and taking physical assets of value (e.g., coins, bills, and tokens) shall provide the SupportedAssetList, the SupportedAssetListVersion and the SlotConfigurationList.

Remark: The SupportedAssetList and SlotConfigurationList are needed to interpret Events of VendingAuditEventType having a SlotIndex.

The GeneratesEvent Reference to the VendingAuditEventType indicates that instances may generate Events of that EventType (see 7.27 for details).