This function retrieves information from TIXnGO about the ticket (status, holder) and stores it inside SecuTix.
With the lifecycle implementation, we aligned the statuses and the screens between TIXNGO and S-360 and synchronize the tickets from a "business" perspective

How does it work?

The "Retrieve ticket status from TIXnGO", also known as "Feedback interface" retrieves information from TIXnGO about the ticket holder and stores it inside S-360.

Only the batch size not already handled tickets are retrieved from TIXnGO.

Only one function "retrieve ticket status from TIXnGO" must run for a given organizer, regardless if tickets are injected from multiple organizations.

Recommended frequency

Every 5 minutes.

Pagination key

Do not touch this value if you do not know what you are doing.

Skip ticket

A non-mandatory parameter in which you can add all the ticket IDs that you want to skip.

Batch size

Recommended value: 1000

TIXNGO Ticket Status

In TIXNGO, we support 18 different statuses to ensure that at any time (before, during, and after an event), an organizer is able to know where a ticket is and who is its owner.

Possible status

INJECTED, DOWNLOADED, ASSIGNED, CONTROLLED, PENDING_TRANSFER, FAILURE_TRANSFER, TRANSFERRED, BT_ACTIVATED, MANUAL_ACTIVATED, OFFLINE_ACTIVATED, ONLINE_ACTIVATED, DELETION_PENDING, DELETED, ACTIVATED, DEACTIVATED, DEFAULT, INVALID, PENDING, FAILURE

We can regroup these 18 statuses into 5 families :

Initial delivery: the ticket is inserted into TIXNGO and/or into the spectator's wallet.
Transfer: the ticket is moving from one wallet to another.
Activation: the ticket is activated by one of the supported methods allowing the display of the QR code in the app.
Control: the ticket has been used to enter event's premises.
Deletion: the ticket has been deleted and cannot be used by a spectator.

S360 Ticket Status	TIXNGO Ticket Status
Not printed	NA. The ticket does not exist in TIXNGO
Printed	(after injection) INJECTED
	(after download) DOWNLOADED
	(after assignment) ASSIGNED
	(after transfer initiated) PENDING_TRANFER
	(after transfer cancelled by sender) FAILURE_TRANSFER (after transfer rejected by receiver) FAILURE_TRANSFER
	(after transfer accepted) TRANSFERRED
	(after ticket activation) XXX_ACTIVATED (OFFLINE_ACTIVATED, ONLINE_ACTIVATED, MANUAL_ACTIVATED, BT_ACTIVATED)
Controlled → ACS control → Ticket check (BO)	(after control before feedback from TIXNGO) XYZ_ACTIVATED where XYZ is the activation method used (after control and feedback from TIXNGO) CONTROLLED
Invalidated → Reprint ticket → Post ticket on resale	If the ticket was already existing in TIXNGO ... DELETION_PENDING (after sending the "invalidated status to TIXNGO and receiving feedback from TIXNGO) DELETED (after successful blockchain deletion and feedback from TIXNGO) If the ticket was never sent to TIXNGO → NA
Cancelled → Cancel ticket (manually or by batch)	If the ticket was already existing in TIXNGO ... DELETION_PENDING (after sending the "cancelled/invalidated" status to TIXNGO and receiving feedback from TIXNGO) DELETED (after successful blockchain deletion and feedback from TIXNGO) If the ticket was never sent to TIXNGO → NA

What and how we synchronize ticket details ?

Each mode has a specific mapping.

Last update	Mapping Document	Change log
03 Apr 2023	FIFASTX-2770_S360-TNG_Mapping_WIP.xlsx	Work in progress → Final version will be uploaded when developement will be completed. BeaconName & ExtraInfoX STX-129962 - Getting issue details... STATUS Cultural Contact creation STX-130794 - Getting issue details... STATUS
07 Feb 2023	S360-TNG_Mapping_20230207.xlsx	Fixing nationality STX-129714 - Getting issue details... STATUS
07 Oct 2022	S360-TNG_Mapping_20221007.xlsx	Lifecycle implementation

How to configure the interface ?

In the custom parameters, to enable the lifecycle mode, you can use TIXNGO_LIFECYCLE_MODE=lifecycle.
By default, if not specified, the history mode will be used.

DEPRECATED : History Mode

With the history mode (legacy behaviour), we synchronized the tickets from a "blockchain transaction" perspective. Since Lifecycle generalization, this mode has been deprecated and is not available to be used.

Possible Statuses (tixngo.legacyStatus) : INJECTED, RECEIVED, ACTIVATED, TRANSFER_PENDING, TRANSFERRED, CONTROLLED, DELETION_PENDING, DELETED
Possible Actions : INJECT, TRANSFER, DELETE, BURN
Possible States : PENDING, CONFIRMED, KO, DELETION_PENDING, DELETED, REGISTRATION_PENDING, CANCELLED, FAILED

S360 Ticket Status	S360 Blockchain Status (history)
Not printed	NA
Printed	(after injection) INJECTED No Action/Status as long as the user does not have a wallet
	(after download) RECEIVED Action/Status : Inject/Confirmed
	(after assignment) RECEIVED Holder/Assignee fields are set Action/Status : Inject/Confirmed
	(after transfer initiated) TRANSFER_PENDING Action/Status : Inject/Confirmed
	(after transfer cancelled by sender) RECEIVED ... or ... (after transfer rejected by receiver) RECEIVED Action/Status : Inject/Confirmed
	(after transfer accepted) TRANSFERRED Action/Status : Transfer/Confirmed
	(after ticket activation) ACTIVATED No specific Action/Status
Controlled → ACS control → Ticket check (BO)	(after control BUT before feedback from TIXNGO) ACTIVATED (after control and feedback from TIXNGO) CONTROLLED No specific Action/Status
Invalidated → Reprint ticket → Post ticket on resale	If the ticket was already existing in TIXNGO ... DELETION_PENDING (after sending the "cancelled/invalidated" status to TIXNGO and receiving feedback from TIXNGO) DELETED (after successful blockchain deletion and feedback from TIXNGO) If the ticket was never sent to TIXNGO → NA
Cancelled → Cancel ticket (manually or by batch)	If the ticket was already existing in TIXNGO ... DELETION_PENDING (after sending the "cancelled/invalidated" status to TIXNGO and receiving feedback from TIXNGO) DELETED (after successful blockchain deletion and feedback from TIXNGO) If the ticket was never sent to TIXNGO → NA

Page tree

4. Retrieve ticket status from TIXnGO