Sposta e scollega il flusso per i biglietti Motics in Google Wallet
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
In questa pagina viene descritta l'implementazione di un flusso di ticket di spostamento e scollegamento per i ticket Motics. Per offrire una buona esperienza utente, un utente deve essere in grado di spostare il proprio biglietto per Motics da un dispositivo all'altro, entro determinati limiti definiti dall'emittente. L'emittente deve limitare i biglietti a un solo dispositivo. L'utente deve eliminare il ticket originale prima di salvarlo su un nuovo dispositivo. Se l'utente non riesce a eliminare
il biglietto originale (ad esempio perché ha perso il dispositivo), l'emittente deve
scollegare il biglietto dal vecchio dispositivo.
Requisiti del flusso per spostare e scollegare
Il flusso di trasferimento e scollegamento deve soddisfare i seguenti requisiti:
- Un biglietto Motics deve essere utilizzabile su un solo dispositivo alla volta.
- L'utente deve essere in grado di spostare il ticket Motics su un nuovo dispositivo nei seguenti casi:
- Accesso a un dispositivo precedente, ad esempio in caso di upgrade a un nuovo dispositivo.
- Nessun accesso al vecchio dispositivo, ad esempio in caso di smarrimento o furto di un dispositivo.
- Il numero di mosse o attivazioni di biglietti deve essere limitato da adeguati controlli sul lato emittente dei biglietti Motics, come definito dai requisiti aziendali della PTO.
Esperienza utente
Questa sezione descrive in maggiore dettaglio i due diversi scenari dell'esperienza utente, a seconda che l'utente abbia ancora accesso al vecchio dispositivo quando tenta di spostare un ticket Motics.
L'utente ha accesso al vecchio dispositivo
In questi casi, l'utente può avviare il flusso di trasferimento dal dispositivo precedente:
- L'utente elimina il ticket Motics dall'app Wallet sul precedente dispositivo.
- L'utente trova l'email di conferma dell'emittente sul suo nuovo dispositivo o accede al webshop o al portale di vendita di biglietti e fa clic su un link Salva in Google Wallet per salvare nuovamente il biglietto nell'app Google Wallet.
L'utente non ha accesso al vecchio dispositivo
Se l'utente non ha accesso al dispositivo precedente, deve avviare il flusso di scollegamento e spostamento dal portale di vendita dei biglietti del webshop oppure contattando l'assistenza clienti dell'emittente, che può avviare il flusso di scollegamento per conto dell'utente.
- L'utente trova l'email di conferma dell'emittente con le istruzioni per chiamare l'assistenza clienti per ricevere assistenza o avvia un flusso di scollegamento dal sito web o dal portale della biglietteria dell'emittente. Potrebbe essere un pulsante di scollegamento sul
portale per la vendita di biglietti.
- L'emittente scollega il ticket dal precedente dispositivo per conto dell'utente (maggiori dettagli nella sezione Responsabilità dell'emittente).
- Il biglietto sarà inutilizzabile (il codice a barre non verrà scansionato) sul dispositivo originale non appena l'emittente lo scollega.
- L'emittente dovrebbe inserire il biglietto precedente nella lista bloccata per assicurarsi che non possa più essere scansionato dai dispositivi di ispezione.
- Il ticket verrà eliminato automaticamente dal dispositivo originale non appena tornerà online (best effort).
- L'utente trova l'email di conferma dell'emittente sul suo nuovo dispositivo o accede al webshop o al portale di vendita di biglietti e fa clic su un link Salva in Google Wallet per salvare nuovamente il biglietto nell'app Google Wallet.
Responsabilità dell'emittente
- Durante la configurazione iniziale, l'emittente deve inserire transitClass con
multipleDevicesAndHoldersAllowedStatus=ONE_USER_ONE_DEVICE.
- L'email di conferma che l'emittente invia all'utente al momento dell'acquisto deve contenere le istruzioni su come spostare il biglietto su un nuovo dispositivo.
- L'email di conferma deve contenere un identificatore per il ticket per l'assistenza nel processo di assistenza.
- Per mantenere al minimo il volume dei contatti, l'emittente deve anche avere un pulsante di scollegamento nel webshop o nel portale di biglietti in cui l'utente può gestire il biglietto.
- L'emittente è responsabile di limitare il numero di volte in cui è possibile attivare un biglietto. Questo consente di evitare che gli utenti spostino lo stesso biglietto da un dispositivo all'altro (entrambi hanno eseguito l'accesso allo stesso account su Wallet) a tempo indeterminato.
- L'emittente deve tenere traccia del numero di volte in cui l'endpoint di attivazione viene chiamato per lo stesso objectId e rifiutare la richiesta di attivazione se il limite viene superato.
- Poiché ogni emittente ha le proprie regole sul numero di volte in cui è possibile trasferire un biglietto, Google richiede che gli emittenti gestiscano direttamente la limitazione dei movimenti dei biglietti.
- Se l'utente vuole scollegare il ticket contattando l'assistenza clienti:
- Se l'utente non riesce a rimuovere il biglietto dal vecchio dispositivo, l'emittente
scollega il biglietto chiamando
transitObject:patch con
{hasLinkedDevice:false} per il objectId del biglietto.
- L'emittente dovrà trovare l'ID oggetto del ticket in questione. Dovrebbe
effettuare la ricerca in base all'identificatore assegnato all'utente
nell'email di conferma.
- Se l'utente avvia il flusso di scollegamento sul webshop o sul portale di biglietti:
- L'emittente scollega il biglietto chiamando
transitObject:patch con {hasLinkedDevice:false} per il objectId del biglietto.
- L'emittente dovrebbe inserire il biglietto precedente nella lista bloccata, in modo che non possa più essere scansionato dai dispositivi di ispezione.
Responsabilità di Google
In risposta alla ricezione della chiamata transitObject:patch con {hasLinkedDevice:false}, Google revocherà il certificato esistente (se presente) con il server Motics. Se l'utente possiede ancora il vecchio dispositivo con il biglietto originale, il codice a barre non funzionerà più e verrà eliminato dal vecchio dispositivo finché sarà online o se tornerà online.
Diagramma sequenza
Figura 1. Flusso di scollegamento del ticket Motics 
La figura 1 mostra le chiamate transitObject:patch e pruneTree() che vengono effettuate per scollegare un ticket quando l'utente non ha più accesso al dispositivo precedente.
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-08-29 UTC.
[null,null,["Ultimo aggiornamento 2025-08-29 UTC."],[[["\u003cp\u003eMotics tickets are designed for single-device use, requiring users to move a ticket from their old device to a new one when switching devices.\u003c/p\u003e\n"],["\u003cp\u003eUsers with access to their old device can move a ticket by deleting it from the old device and then resaving it to their new device via a confirmation email or the issuer's platform.\u003c/p\u003e\n"],["\u003cp\u003eIf the old device is inaccessible, users must initiate an unlink flow through the issuer's customer support or online portal, after which they can resave the ticket to their new device.\u003c/p\u003e\n"],["\u003cp\u003eIssuers are responsible for implementing controls to limit the number of times a ticket can be moved and for unlinking tickets from lost or stolen devices using the \u003ccode\u003etransitObject:patch\u003c/code\u003e API call.\u003c/p\u003e\n"],["\u003cp\u003eGoogle assists in the unlink flow by revoking the old ticket's certificate and ensuring it's unusable, with the old ticket automatically deleted from the device when it comes online.\u003c/p\u003e\n"]]],["Motics ticket issuers must enable users to move tickets between devices, limiting usage to one device at a time. When a user has access to the old device, they must delete the ticket before saving it to a new device. Without access, the issuer must unlink the ticket via a web portal or customer support. The issuer updates the ticket status via an API call, which revokes the old device's ticket certificate, deletes the ticket from the old device and then should also denylist it to prevent it from being scanned. The issuer is also responsible for limiting the number of ticket moves.\n"],null,["# Move & Unlink Flow for Motics tickets in Google Wallet\n\nThis page describes implementing a move and unlink ticket flow for Motics\ntickets. To provide a good user experience, a user should be able to move their\nMotics ticket from one device to another, within certain limits defined by the\nissuer. The issuer has to restrict a ticket to one device. The user must delete\nthe original ticket before saving it to a new device. If the user cannot delete\nthe original ticket (perhaps because they lost the device), the issuer must\nunlink the ticket from the old device.\n\nMove \\& Unlink Flow Requirements\n--------------------------------\n\nThe Move \\& Unlink flow has to fulfil the following requirements:\n\n- A Motics ticket must only be usable on one device at a time.\n- The user must be able to move the Motics ticket to a new device in these cases:\n - Access to old device, for example when upgrading to a new device.\n - No access to old device, for example when a device is lost or stolen.\n- The number of moves or ticket activations should be limited by suitable controls on the Motics ticket issuer side, as defined by the PTO's business requirements.\n\nUser Experience\n---------------\n\nThis section describes in more detail the two different scenarios for the User\nExperience, depending on whether the user still has access to their old device\nwhen attempting to move a Motics ticket.\n\n### User has access to old device\n\nIn such cases, the user can initiate the move flow from their old device:\n\n1. The user deletes the Motics ticket from the Wallet app on their old device.\n2. The user finds the confirmation email from the issuer on their new device or logs in to the ticketing webshop or portal and clicks a Save to Google Wallet link to resave the ticket to the Google Wallet app.\n\n### User does not have access to old device\n\nWhen the user does not have access to their old device, they need to initiate\nthe unlink and move flow from either the webshop ticketing portal, or by\ncontacting the customer support of the issuer, that can initiate the unlink flow\non the user's behalf.\n\n1. The user finds the confirmation email from the issuer with instructions to call customer service for assistance or starts an unlink flow from the issuer website or ticketing portal. This could be an unlink button on the ticketing portal.\n2. The issuer unlinks the ticket from the old device on behalf of the user (more details in the [Issuer Responsibilities](#issuer-responsibilities) section).\n3. The ticket will be unusable (barcode won't scan) on the original device as soon as the issuer unlinks it.\n4. The issuer should denylist the old ticket, to ensure it can no longer be scanned by inspection devices.\n5. The ticket will automatically be deleted from the original device as soon as it comes online again (best-effort).\n6. The user finds the confirmation email from the issuer on their new device or logs in to the ticketing webshop or portal and clicks a Save to Google Wallet link to resave the ticket to the Google Wallet app.\n\nIssuer Responsibilities\n-----------------------\n\n- During initial setup the issuer must [insert the transitClass](/wallet/tickets/transit-passes/qr-code/motics/technical-details#transitClassInsert) with `multipleDevicesAndHoldersAllowedStatus=ONE_USER_ONE_DEVICE`.\n- The confirmation email that the issuer sends to the user at purchase time has to contain instructions for how to move the ticket to a new device.\n- The confirmation email has to contain an identifier for the ticket to the help in the support process.\n- To keep contact volume to a minimum, the issuer should also have an unlink button on their webshop or ticket portal where a user can manage their ticket.\n- The issuer is responsible for limiting the number of times a ticket can be activated. This is to avoid users moving the same ticket back and forth between devices (both logged into the same account on Wallet) indefinitely.\n - The issuer has to keep track of how many times the activation endpoint is called for the same objectId, and reject the activation request if it exceeds the limit.\n - Since each issuer has its own rules on how many times a ticket can be moved, Google requires that issuers handle limiting ticket moves on their end.\n- If the user wants to unlink the ticket through contacting customer support:\n - If the user cannot remove the ticket from the old device, the issuer unlinks the ticket by calling `transitObject:patch` with `{hasLinkedDevice:false}` for the `objectId` of the ticket.\n - The issuer will need to find the objectId for the given ticket. They should look this up based on the identifier given to the user in the confirmation email.\n- If the user initiates the unlink flow on the webshop or ticket portal:\n - The issuer unlinks the ticket by calling `transitObject:patch` with `{hasLinkedDevice:false}` for the `objectId` of the ticket.\n- The issuer should denylist the old ticket, so that it can no longer be scanned by inspection devices.\n\nGoogle Responsibilities\n-----------------------\n\nIn response to receiving the `transitObject:patch` with\n`{hasLinkedDevice:false}` call, Google will revoke the existing certificate (if\nthere is one) with the Motics server. If the user does still have their old\ndevice with the original ticket, the barcode will no longer work as it will be\ndeleted from the old device as long as it is online or comes online again.\n\n### Sequence Diagram\n\n**Figure 1.** Motics Ticket Unlink Flow\n\nFigure 1 shows the `transitObject:patch` and `pruneTree()` calls that take place\nto unlink a ticket when the user no longer has access to their old device."]]
