TIXnGO is the lading leading secure mobile wallet solution provided by the SecuTix company.
...
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: Push al the tickets that have been controlled to TIXnGO, so the new status in TIXnGO will be assigned. Please note that when a ticket has been controlled is not transferable anymore.
Retrieve status from TIXnGO: Returns the current status of the ticket to S- 360 to TIXnGO.
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 TIXnGO Customization of the data injected by SecuTix)
2.) Fill in the API URL provided by TIXnGO in the URL fiekdfield. It must end by organizer/tickets
...
The field "Email notification...." allows you to receive emails when one of the asynchronous processes described below is failing.
Ticket injection / Tickets external printing (both names designates the same thing)
The ticket injection process pushes the designated tickets to the TIXnGO system, 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
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)
File number filtering
This one is exclusive of 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's values filled will be sent to TIXnGO.
Main applicant
Will send the mainApplicant 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.
AFUF : Customization of data sent to TIXnGO using the template editor
Please refer to that specific page for the data customization
To which contacts are the tickets assigned?
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.
It does not offer a lot of filtering possibilities.
The tickets extracted are all the ones updated (cancelled/invalidated) since the last execution ending OK or Warning.
Recommended frequency
Every 5 minutes.
Date from
This value allows to override the date of the last execution OK or Warning. If you keep it defined in a regular execution, the same tickets will be extracted and pushed over and over.
Batch size
Keep it empty.
What if tickets appears to be missing?
Create another schedule with a Date from defined before the cancellation and run it once.
Push controlled tickets
This batch pushes the controlled status of the tickets to TIXnGO
The tickets extracted are all the ones updated (controlled) since the last execution ending OK or Warning.
Recommended frequency
Every 5 minutes.
Date from
This value allows to override the date of the last execution OK or Warning. If you keep it defined in a regular execution, the same tickets will be extracted and pushed over and over.
Batch size
Keep it empty.
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
Recommended frequency
Every 5 minutes.
Pagination key
Do not touch this value if you do not know what you are doing.
Batch size
Recommended value: 500
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
| Jira | ||||||
|---|---|---|---|---|---|---|
|
| Info | ||
|---|---|---|
| ||
Please do not set up different interfaces on the same organization, else the push cancelled tickets and push will not work. |
Which products can be injected into TIXnGO?
- Event/ Competions
- Passes
- Services
¡NEW!
- Memberships
- Season TIckets
For more detailed info, please refer to the specific site:
| Children Display |
|---|
...