TIXnGO is the leading secure mobile wallet solution provided by the SecuTix company.
Please refer to this page for the functionalities of the product.
To set up product that can use this interface, please refer this page
The document describes the features and the setup steps of the interface between SecuTix 360 and TIXnGO
| Table of Contents |
|---|
Data streams
Ticket Injection: External printing. When executing this function, the ticket will pass to "printed" status on Secutix, and it will be injected on TIXnGO
Cancelled ticket: Push that has been cancelled in Secutix into TIXnGO. So the new status of the processed ticket will be cancelled on TIXnGO
Controlled ticket:
Global setup of the interface
As for SecuTix 360, the TixNGo system is perceived as an external printing system. Tickets injected into TIXnGO are considered as printed.
| Note |
|---|
| In case of multi organization, the organization must be set up in the organization owing the inventory of the tickets (the organization where the catalog is defined) |
To set it up:
1.) In Organization/Tools/Interfaces create a new External Printing Interface of type "TIXnGO" or "TixnGO with ticket template" (If you want to use the Ticket Template Editor to custom the data send to TIXNGO /wiki/spaces/CF/pages/40576543)
2.) Fill in the API URL provided by TIXnGO in the URL field. It must end by organizer/tickets
3.) Fill in the username provided by TIXnGO (I guess the value does not matter)
4.) In the password field, fill in the API key provided by TIXnGO
5.) Inject some test tickets.
The field "Email notification...." allows you to receive emails when one of the asynchronous processes described below is failing.
Should we set up different interfaces for given organization to speed the things up?
No. Else the push cancelled tickets and push will not work.
Don't.
Ticket injection / Tickets external printing (both names designates the same thing)
The ticket injection process pushes the designated tickets to the TIXnGO system, and then to the wallets of the final users.
To activate it, create a schedule to choose which tickets to process.
Recommended frequency
Every 5 minutes.
Batch size
Recommended value: 1000
Multilingual Feature
Add the custom parameter sendMultilingualAsJsonObject=true in the General tab when you configure an External printing interface.
Set up multilingual event fields in the ticket template
Prepare your ticket template and use this template when scheduling a Tickets external printing function
Example: event.name = ${Performance_hostTeam} - ${Performance_opposingTeam}
Other available multilingual fields:
...
Organisation > Catalogue > Ordinary admissions > Competition
...
Organisation > Initialisation > Organisation parameters > Teams
...
Institution > Venue > Venue parameters > Space
...
Institution > Venue > Venue parameters > Sites (General)
...
Institution > Venue > Venue parameters > Sites (Address)
Multilingual value has not been supported in S-360 yet but can update this value in TIXNGO
...
Set up multilingual ticket detail values in the ticket template
...
Static values
Hospitality, Entrance, Gate, Block, Row, Seat,...
...
Multilingual value has not been supported in S-360 yet but can update this value in TIXNGO
...
${Hospitality_seatRoomName}, ${External_Entrance_externalName}, ${Entrance_externalName}, ${Seat_block}, ${Seat_row}, ${Seat_nb},...
...
Static values
Category, Order number, ticket number, target group, No re-entry,...
...
Ticket details hidden
(Not displayed in the mobile ticket app)
...
*sequence: the order of information will be displayed on TIXNGO, the sequence is started from 0 and is independent in each section.
Initialize an S360 event and ticket detail label in TIXNGO Back Office
Prepare sample ticket per each kind of ticket for each event, and inject those tickets to TIXNGO system
All available labels will be displayed in the Edit event screen on TIXNGO Back Office
Can choose a language on the top right of the Edit event screen to view and edit the event fields and ticket labels in multilingual.
Non-dated ticket injection
This new feature has been built in order to be able to inject other products such as Services in TIXnGO.
For non-dated ticket injection, please set custom variables in the chosen product following the format on the following table. Then try to inject tickets, as usual, filtering by the product instead of an activity.
Comfort variables affecting TIXnGO data.
...
start_of_season
end_of_season
+1d/-1w
dd/mm/yy hh:mm
...
If not defined, nothing special happens
Parts in blue will be implemented with : Jira Legacy server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-128539
...
start_of_season
end_of_season
+1d/-1w
dd/mm/yy hh:mm
...
start_of_season
end_of_season
2w
22/10/23 21:15
...
If comfort variable is not defined, then the value is taken from the start time of the performance or the start validity date of the ticket.
Parts in blue will be implemented with : Jira Legacy server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-128539
...
start_of_season
end_of_season
+1d/-1w
dd/mm/yy hh:mm
...
start_of_season
end_of_season
2w
22/10/23 21:15
...
If comfort variable is not defined, then the value is taken from the end date of the performance + duration (or +24 hours if duration not defined), or the end validity date of the ticket.
Parts in blue will be implemented with : Jira Legacy server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-128539
Further information and more detail:
Point of sales configuration
As this schedule must mark some tickets as printed, as if it had been done by a point of sales, you must set up (once) the sales channel and point of sales codes that will be used for that task.
Filtering
Many filtering options exist by-product(s), by performance(s), by tariff or category code... They are all cumulative (AND logical relation)
Barcode format
Allows adding a prefix/post-fix to the barcode
File number filtering
This one is exclusive to all the other ones. If a file number (file id) is provided, it will exclude all the other fields.
Mandatory ticket holder fields
Please enter here one or many of the following values, separated by commas
FIRSTNAME,LASTNAME,BIRTHDATE,ID_NUMBER,COUNTRY_CODE,BIRTH_REGION,BIRTH_PLACE
Only the tickets having those beneficiary values filled will be sent to TIXnGO.
Main Applicant
Will send the main applicant flag to true to TIXnGO only when the beneficiary's first name, last name and email (and NOT the cultural contact's) are matching those of the buyer.
Simulation mode
If this box is checked, the tickets won't be sent to TIXnGO.
File and contact filter
If file or contact filter are selected, only the tickets associated to the file (resp. tickets associated to the contact) are exported.
Customization of data sent to TIXnGO using the template editor
If you use the ticket template editor to inject tickets, you must configure the following on the Technical tab.
Check the custom ticket details and put {"":""} in the fields.
/wiki/spaces/CF/pages/40576543 TIXnGO.
To which contacts are the tickets assigned?
- The tickets are assigned to the person defined in the spectatorDetails data pushed to TIXnGO, identified through its email.
- By default, the tickets are assigned to the cultural contact, with fallback to the purchaser contact..
- But, IF the tickets has been reprinted, it will be assigned to its last known holder, as retrieved from TIXnGO.
In which orders are the ticket pushed?
The tickets are pushed ordered by ticket id. This likely means that ticket from a same order will come together.
Push cancelled and invalidated tickets
This batch pushes the cancelled and invalidated tickets to TIXnGO.
The tickets pushed are all the ones that:
- Have been injected
- Have been cancelled/invalidated
- Comply with the filter (shipment mode)
- Have not been already pushed by that function for that given interface
Recommended frequency
Every 5 minutes.
Date from
Can be used to force the sending of all cancelled tickets as if the last successful execution of the function was at the given date..
Do not use it if you don't understand clearly the usage, it may trigger thousands of unwanted notifications on remote cell phones.
Batch size
Recommended value: 1000
Ticket visibility rule
S-360 is pushing cancelled and invalidated tickets using an TIXnGI Api parameter called showDeletedTicket which defines its visibility.
The visibility for deleted tickets is following the rules:
- if the cancellation cause is in the list of overrideVisibilityFlagForInvalidationReasons (default value: empty), the the visibility is true. (showDeletedTicket =true)
- Else, if the checkbox "Notify spectator" is checked, the the visibility is set to true. (showDeletedTicket =true)
- Else default visbility is used. Default: false (showDeletedTicket =false), Can be altered using custom parameter: visibilityFlagDefaultValue.
Push controlled tickets
This batch pushes the controlled status of the tickets to TIXnGO
The tickets pushed are all the ones that:
- Have been injected
- Have been controlled
- Comply with the filter (shipment mode)
- Have not been already pushed by that function for that given interface
Recommended frequency
Every 5 minutes. Can run every minute during event.
Date from
Can be used to force the sending of all controlled tickets as if the last successful execution of the function was at the given date..
Do not use it if you don't understand clearly the usage.
Batch size
Recommended value: 1000
Retrieve ticket status from TIXnGO
This function retrieves information from TIXnGO about the ticket holder and stores it inside SecuTix.
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
Custom parameters
...
This custom parameter is used for the Tickets external printing/ Push cancelled and validate tickets/ Push controlled tickets. To support larger batch sizes, split them into smaller calls to blockchain to send smaller batches, one after the other inside the same execution. The default split size is 50
Note: The TIXnGO side supported only 50 tickets/times, so that should be kept as default.
...
This custom parameter is used for the Retrieve tickets status from TIXnGO batch. To support larger batch sizes, split them into smaller calls to blockchain to retrieve smaller batches, one after the other inside the same execution. The default split size is 1000
Example: Batch size in the Retrieve tickets status from TIXnGO = 5000, batchSplitSize = 1000. It will split 5000 to 5 calls in the same execution with 1000 per call
...
This custom parameter is used for the Tickets external printing to allow injecting mobile tickets to the latest ticket holder contact or cultural contact based on the invalidation reason, i.e., reseating
Example: After injecting ticket into TnG for contact A (cultural contact) then contact A open mobile app and transfer the ticket to contact B (latest mobile owner). On the STX side, the operator reprinted that ticket with invalidation reason THEFT and reinject it into TnG, this ticket will reinject back to contact A. If there is no invalidation reason here, the new ticket will be reinjected back to contact B
Note: All the cancellation reasons are those which appear on the list of values in the BO [Institution > Initialisation > List of values > Ticket (Cancellation cause)]. With validation reason Theft , rESEATING will work too because the invalidation causes will be modified in order to remove the spaces and to be all set in upper cases
...
Both custom parameters are used for putting blockchain tickets into the resale platform and specified for Push cancelled and validate ticket batch. The purpose of those parameters is to update the invalidation reason to TnG after putting the ticket on the resale platform or tickets is resold.
Example: excludeTicketResale=true, overrideVisibilityFlagForInvalidationReason=RESALE_PENDING, RESOLD
After putting the ticket on the resale platform, the old ticket is invalidated and the validation reason will be updated into TnG side by the Push cancelled and validate ticket with invalidation set at overrideVisibilityFlagForInvalidationReason
For more information, please refer to the US STX-110559
...
Default value: true. Set it to false to skip the rule: But, IF the tickets has been reprinted, it will be assigned to its last known holder, as retrieved from TIXnGO.
The parameter is spelled with "Spectatir" (typo included) not "Spectator" as you may expect.
...
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
To inject tickets to TIXNGO from S360 or by CSV with multilingual support
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
Default value: false. Set it to true to use the deprecated query to get the list of cancelled/invalidated tickets. DEPRECATED. Either set it explicitly to false or remove completely the custom parameter.
...
| Table of Contents | ||
|---|---|---|
|
Overview
Interface role
While S-360 handles ticket sales and issuing, TIXNGO, as a Secure Mobile Ticket Delivery solution, functions as an External Printing System. Once tickets are injected into TIXNGO:
- They are marked as PRINTED in S-360.
- They can be assigned, transferred, posted for resale, and more via TIXNGO.
- TIXNGO will keep a track record of all actions performed on the mobile tickets.
The primary role of the S-360 TIXNGO interface is to ensure that once tickets are issued and injected into TIXNGO, their status and details are synchronized between S-360 and TIXNGO.
Supported S-360 products
| Tickets | Digital Privileges |
|---|---|
|
|
Interface functions & data streams
| Function | Objectives | Outcome in TIXNGO | Outcome in S-360 |
|---|---|---|---|
Tickets (Event / Performance, Match / Competition, Open Passes, Services) | |||
| Tickets external printing aka Tickets injection | Create an Event (if does not exist yet) and add the designated NOT_PRINTED S-360 tickets into TIXNGO |
|
|
Retrieve ticket status from TIXNGO | Retrieve TIXNGO tickets details (status, wallet owner, ticket holder) | NA |
|
Push cancelled and invalidated tickets | Invalidate tickets in TIXNGO |
|
|
Push controlled tickets | Mark as Controlled tickets in TIXNGO | Ticket status updated to CONTROLLED |
|
| Digital Privileges (Memberships Cards, Season Tickets – Cards Only) | |||
Inject digital privileges | Create a Privilege Definition (if does not exist yet) and add the designated NOT_PRINTED S-360 membership and season cards into TIXNGO as Digital Privileges instance |
|
|
To learn more about the TIXNGO interfaces (functions, parameters, ...) :
| Child pages (Children Display) |
|---|