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
| Table of Contents |
|---|
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 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.
| Info | ||
|---|---|---|
| ||
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.
...
TIXNGO Ticket Status
...
Printed
...
(after transfer cancelled by sender) FAILURE_TRANSFER
(after transfer rejected by receiver) FAILURE_TRANSFER
...
(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.
...
Work in progress → Final version will be uploaded when developement will be completed.
- BeaconName & ExtraInfoX
Jira showSummary false server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-129962 - Cultural Contact creation
Jira showSummary false server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-130794
...
07 Feb 2023
...
S360-TNG_Mapping_20230207.xlsx
...
Fixing nationality
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
S360-TNG_Mapping_20221007.xlsx
...
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
With the history mode (legacy behaviour), we synchronize the tickets from a "blockchain transaction" perspective
History mode (legacy behaviour)
- 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 Blockchain Status (history)
...
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 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)
...