Ticket transfers are at the core of the TIXNGO experience—they’re what make secure, digital ticketing truly flexible and user-centric. With V4, we've reimagined the transfer process from the ground up, introducing a more robust and transparent framework. This new foundation brings greater consistency, improved control, and enhanced clarity for both spectators and organizers, while preserving the secure and trusted principles that define TIXNGO. |
We've introduced a new internal concept called 'Transfer Group' when a transfer is initiated. This concept enables TIXNGO to organize and process tickets transfer more intuitively, leading to:
Enhanced transfer performances
Improved Wallet user experience by simplifying the display of tickets and transfers on mobile, starting with grouping and ordering on transfer-related screens
We’ve introduced a new internal concept called ‘Transfer Direction’, together with the ‘Transfer Backward’ setting in the V4 Usage Rule, to improve transfer level computation and simplify related mobile processes (e.g. Return Ticket, Edit Transfer Recipient).
Transfer Direction supports two values:
FORWARD – when a ticket is transferred from Spectator A to Spectator B.
BACKWARD – when a ticket is transferred back from Spectator B to Spectator A, either via the "Return to sender" button or by manually entering the original sender’s email and re-initiating the transfer.
As of TIXNGO V3, the number of transfers allowed for a ticket is determined by the combination of:
The transfer level (i.e., the number of successful transfers already completed)
The transfer limit, defined in the Ticket Usage Rule (also known as the "Maximum number of transfers allowed").
By default, after injection, a ticket’s transfer level is 0.
To enhance visibility and understanding of transfer behavior on a single ticket, the V4 ticket model maintains the transfer level and introduces two new dedicated counters:
forwardTransfers — Total number of Forward transfers successfully completed
backwardTransfers — Total number of Backward transfers successfully completed
Context: Spectator A wants to transfer his ticket to Spectator B.
His ticket is newly injected and its the transfer level is 0 and its transfer limit at 3 via the Usage Rule applied.
Because the tra
a unique transfer group is generated
for this transfer group:
sender is the current Owner
recipient is the future Owner (if he accepts the transfer)
the transfer direction is FORWARD.
Once accepted by Spectator B accepted the transfer:
The current owner becomes Spectator B.
The previous owner becomes Spectator A.
The initial owner remains unchanged.
The transfer level is 1.
The forwardTransfers count is 1.
The backwardTransfers count is 0.
Context: Spectator B wants to return his ticket to Spectator A.
Since the transfer level (1) is below the transfer limit (3), the transfer can be initiated
a unique transfer group is generated
for this transfer group:
The sender is the current owner (Spectator B).
The recipient is the previous owner (Spectator A), if they accept the transfer.
The transfer direction is set to BACKWARD.
Once Spectator A accepts the transfer:
The current owner becomes Spectator A.
The previous owner becomes Spectator B.
The initial owner remains unchanged.
The forwardTransfers count is 1.
The backwardTransfers count is 1.
The transfer level update depends on the “Transfer backward” setting defined in the Ticket Usage Rule.
“Transfer backward” Setting | Description | Transfer Level Change | Example |
|---|---|---|---|
| The backward transfer does not count toward the transfer limit. | No change |
|
| The backward transfer restores the transfer level to its state prior to the last forward transfer. | −1 |
|
| The backward transfer counts as a new transfer, like any other transfer. | +1 |
|
With TIXNGO V4, the existing setting to enable or disable transfer acceptance has been retained.
The key change from V3 is that transfer acceptance now applies to all transfer directions—both forward and backward.
When the setting is enabled:
For FORWARD transfers (Spectator A → Spectator B), Spectator B must accept the transfer (as in V3).
For BACKWARD transfers (Spectator B → Spectator A), Spectator A must now accept the transfer (new in V4).