| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Info |
|---|
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. |
New concept: “Transfer Group”
...
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.
New Transfer Level computation
As of TIXNGO V3, the number of transfers allowed for a ticket is determined by the combination of its :
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, the a ticket’s transfer level is 0.
Transfer Level and New Transfer Counters in TIXNGO V4
To enhance visibility and understanding of transfer behavior on a ticket is 0 (zero).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
Forward transfer
Context: Spectator A want wants to transfer his ticket to Spectator B.
...
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:
ticket Current Owner is now Spectator B
ticket The current owner becomes Spectator B.
The previous owner becomes Spectator A.
The initial owner remains unchanged.
The transfer level is now 1
ticket Previous Owner is Spectator A
ticket Initial Owner remains the same.
The forwardTransfers count is 1.
The backwardTransfers count is 0.
Backward transfer
Context: Spectator B want wants to return his ticket to Spectator A.
Because 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 Ownerowner (Spectator B).
The recipient is the Previous Owner (if he accepts the transfer)
previous owner (Spectator A), if they accept the transfer.
The transfer direction is set to
BACKWARD.
Once accepted by Spectator A accepted accepts the transfer:
...
NEUTRAL
...
Backward transfer does not count against the transfer limit
...
ticket Current Owner is now The current owner becomes Spectator Aticket Previous Owner is .
The previous owner becomes Spectator B
ticket Initial Owner remains the same
ticket transfer level is depending of the Ticket Rule setting “Transfer backward”
...
Transfer backward setting
...
Transfer level Computation
...
Transfer level change
...
Transfer level
.
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 |
|
Consistent behavior for transfer acceptance
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).