Pagamenti · mobile
Sostituire le fondamenta sotto un’app di pagamento, mentre la gente ci pagava.
Paytec costruisce sistemi di pagamento per distributori automatici. OPTO è l’applicazione che i loro clienti tengono in mano davanti alla macchina. Nel 2025 girava su un framework che Microsoft aveva già smesso di supportare — e non si poteva permettere che smettesse di funzionare per un solo giorno.
- Dal
- 2025
- Cliente
- Paytec
- Team
- 2
- Stato
- in produzione
Il prodotto
Che cos’è OPTO, e perché la stabilità non è un dettaglio estetico
OPTO è la soluzione di pagamento digitale di Paytec per il vending. Il telefono comunica con la macchina per via ottica — attraverso la luce del proprio schermo, non NFC e non un codice QR — verso un piccolo lettore installato sulla macchina, con un sensore ottico e un modulo Bluetooth, senza modem e senza SIM. L’utente tiene un saldo nell’applicazione, lo ricarica con carta o in contanti e, sulle macchine adeguatamente attrezzate, seleziona il prodotto dal telefono e paga con un solo gesto. La parte monetaria è in capo a un emittente di moneta elettronica autorizzato nell’Unione europea.
Tutto questo è la descrizione che Paytec pubblica del proprio prodotto, ed è su questa pagina per un motivo: fissa lo standard che il software deve raggiungere. Un’applicazione a volte lenta è una seccatura. Un’applicazione che fallisce nel momento del pagamento, davanti a una macchina, con un saldo già caricato, è una chiamata all’assistenza, un rimborso e un cliente che torna alle monete. Qui l’affidabilità non è un attributo di qualità. È il prodotto.
La situazione nel 2025
Il framework era morto da un anno
Paytec è venuta da noi con un’applicazione funzionante e un problema non ancora visibile ai suoi utenti. OPTO era costruita su Xamarin. Microsoft ha chiuso il supporto a Xamarin il 1 maggio 2024.
Un framework mobile fuori supporto non si annuncia. L’applicazione continua a funzionare, continua a incassare pagamenti e continua ad apparire in ordine — mentre in silenzio tre cose smettono di essere vere. Non ci sono più correzioni per i difetti del framework stesso. Non c’è supporto per il comportamento delle nuove versioni dei sistemi operativi, che arrivano ogni autunno indipendentemente dal fatto che siate pronti. E poi c’è il cricchetto degli store: Google Play richiede che le nuove app e gli aggiornamenti abbiano come target Android 15 dal 31 agosto 2025 e Android 16 dal 31 agosto 2026. Un’applicazione che non si può più compilare su un target attuale è un’applicazione che non si può più pubblicare — compreso il giorno in cui vi serve urgentemente rilasciare una correzione.
Questo è il vero rischio di un framework morto, ed è il motivo per cui questo non è mai stato un progetto di ammodernamento in senso decorativo. Era una scadenza già passata.
Che cosa abbiamo fatto
Prima la migrazione, poi tutto ciò che la migrazione ha reso possibile
Siamo entrati in un codice che non avevamo scritto, per un prodotto che non avevamo progettato, senza la possibilità di metterlo in pausa. L’incarico aveva due parti, e non erano equivalenti: portare OPTO da Xamarin a .NET MAUI, e uscirne più stabile di come era entrata. Una migrazione che approda a un framework supportato e a un tasso di crash peggiore è fallita, qualunque cosa dicano le note di rilascio.
La cosa utile da capire di questo tipo di migrazione è dove sta davvero il lavoro. La logica di business — saldi, transazioni, le regole che li governano — si porta in modo relativamente pulito, perché è codice ordinario. Quello che non si porta da sé è il livello di piattaforma: come l’applicazione parla con il lettore, come si comporta quando il sistema operativo la sospende, come si chiedono i permessi su ciascuna versione di ciascuna piattaforma e quanto tutto questo cambi tra un telefono Android di quattro anni e un iPhone attuale. In un’applicazione di pagamento, a quel livello non è consentito essere approssimativamente corretto.
Il team è stato di due persone per tutta la durata: un ingegnere mobile che portava sia iOS sia Android su .NET MAUI e un ingegnere backend su un servizio PHP. Citiamo la dimensione perché è la forma onesta di questo tipo di lavoro. Una migrazione non diventa più sicura aggiungendo persone; diventa più sicura se le stesse due teste tengono insieme tutto il sistema in una volta.
L’instabilità non era tutta nell’applicazione
Questa è la parte che vale la pena portarsi via da questa pagina. Il sintomo visibile era l’applicazione: crash, blocchi, l’app terminata in background, utenti che perdevano il filo in mezzo a un acquisto. La conclusione ovvia era che la colpa fosse del codice client, e in parte lo era.
Ma una parte dei guasti si concentrava nelle ore di punta — e questa è una forma, non una coincidenza. Invece di discuterne, l’abbiamo riprodotta sotto carico, e la causa si è rivelata dall’altra parte: l’applicazione perdeva la connessione al backend quando la domanda si concentrava. Nessuna quantità di lavoro sul codice mobile l’avrebbe risolto. Si è risolto aumentando la capacità del backend, ed è il motivo per cui l’incarico aveva un ingegnere backend e non soltanto uno mobile.
L’altra cosa che è cambiata per gli utenti è poco vistosa e conta ogni singola volta: ora l’applicazione si apre più in fretta da freddo. Davanti a un distributore automatico, con qualcuno in attesa dietro di voi, i secondi prima che compaia la prima schermata sono tutta l’esperienza.
OPTO come la vedono i suoi utenti, dalla scheda store pubblicata da Paytec. La migrazione deliberatamente non ha cambiato questo: l’incarico era sostituire ciò su cui l’applicazione si appoggia, non il suo aspetto.
La seconda fase è arrivata dopo che la prima si era dimostrata valida: Paytec ci ha chiesto di continuare, e abbiamo portato l’applicazione da .NET 9 a .NET 10, migliorando per strada parti del suo comportamento. Quell’aggiornamento sembra manutenzione di routine e non lo è. Un’applicazione .NET MAUI corre su due orologi, e quello più corto è facile da non vedere: .NET MAUI 9 è uscito dal supporto il 12 maggio 2026, sei mesi prima che .NET 8 e .NET 9 stessi arrivino a fine supporto il 10 novembre 2026. .NET 10 è una release a supporto a lungo termine, portata fino a novembre 2028. Spostarci quando lo abbiamo fatto è stata la differenza tra pianificare un aggiornamento ed esservi costretti.
Oggi manteniamo la generazione che è in produzione mentre ne costruiamo accanto la successiva. L’applicazione distribuita resta supportata e rilasciabile per tutta la durata — che è l’unico assetto che funziona quando la cosa che state sostituendo è anche la cosa che incassa i soldi. La prossima generazione avrà una pagina propria quando sarà nelle mani delle persone; preferiamo scriverla dopo piuttosto che annunciarla ora.
Lo schema
Quattro cose di cui questo incarico è la prova
01 · Codice ereditato
Non eravamo gli autori originali e gli autori originali non erano disponibili. Prendere in carico il codice di produzione di qualcun altro — leggerlo, stabilizzarlo, poi cambiarne le fondamenta — è una competenza distinta dal partire da zero, ed è la maggior parte di ciò in cui consiste davvero il lavoro di ammodernamento.
02 · Abbiamo guardato oltre il colpevole ovvio
Il sintomo era nell’applicazione; una parte della causa era nel backend, e si manifestava solo sotto carico di punta. Trovarlo ha richiesto di riprodurlo invece di tirare a indovinare, e un team in grado di lavorare su entrambi i lati del filo.
03 · Siamo ancora qui
La migrazione è stata nel 2025. L’aggiornamento a .NET 10 è arrivato dopo, perché il cliente ci ha chiesto di continuare. Oggi manteniamo la generazione attuale e stiamo costruendo la successiva. Proseguire un incarico è più difficile da conquistare che iniziarne uno.
04 · L’orologio è pubblico
Ogni data su questa pagina si può verificare sulle politiche pubblicate da Microsoft e da Google. Preferiamo argomentare a partire da documenti che potete verificare piuttosto che da aggettivi che non potete verificare.
Domande
Che cosa si chiede su un lavoro come questo
Perché migrare invece di riscrivere da zero?
Perché la parte costosa di un’applicazione di pagamento non sono le sue schermate — sono gli anni di comportamenti accumulati attorno al denaro, ai dispositivi e ai casi limite che nessuno ha messo per iscritto. Una riscrittura butta via tutto questo e lo riscopre in produzione, davanti a utenti che pagano. Una migrazione conserva la logica di business e sostituisce le fondamenta sottostanti: è più lenta da pianificare e molto più rapida da portare a termine in sicurezza.
Che cosa succede davvero a un’app su un framework fuori supporto?
All’inizio nulla — ed è questa la parte pericolosa. Continua a funzionare e continua a vendere. Quello che si ferma è tutto ciò che le sta attorno: nessuna correzione dei difetti del framework, nessun supporto per il comportamento dei nuovi sistemi operativi e nessun modo di soddisfare i requisiti annuali di target API degli app store. Google Play richiede che le nuove app e gli aggiornamenti abbiano come target Android 16 dal 31 agosto 2026. Un’applicazione che non può più essere ricompilata su un target attuale prima o poi non può più essere pubblicata affatto — e la prima volta che questo conta è di solito il giorno in cui vi serve urgentemente rilasciare una correzione.
Se non c’erano metriche, come sapete che è migliorata?
Onestamente: non con la fermezza che vorremmo. Quando l’abbiamo ereditata, l’applicazione non aveva analytics né crash reporting, quindi non esiste un numero prima-e-dopo — e inventarne uno sarebbe peggio che non averlo. Quello che abbiamo è che le segnalazioni di crash, blocchi ed esaurimento di memoria che arrivavano dal cliente e dai suoi utenti hanno smesso di arrivare, e che i guasti nelle ore di punta che avevamo riprodotto sotto carico non si riproducono più. Preferiamo dirvelo così, piuttosto che pubblicare una percentuale di cui non possiamo indicare la fonte.
È .NET MAUI pronto per i pagamenti in produzione?
Nella nostra esperienza sì — con l’avvertenza che il livello specifico di piattaforma è dove il lavoro vive davvero. La logica di business si porta senza problemi. La comunicazione con il dispositivo, il comportamento in background, i permessi e le differenze tra le versioni di iOS e Android non si portano da sé, e sono esattamente le parti su cui un flusso di pagamento non può essere approssimativamente corretto. Dimensionate il budget del progetto attorno a quel livello, non attorno alle schermate.
Una migrazione come questa interrompe il servizio?
Non dovrebbe, ed è una decisione di pianificazione più che tecnica. L’applicazione già rilasciata resta supportata e rilasciabile per tutta la durata, quindi una correzione urgente può comunque uscire mentre la migrazione è in corso. È esattamente per questo che manteniamo la generazione di OPTO in distribuzione insieme allo sviluppo della successiva.
Di chi è il risultato?
Del cliente. Lavoriamo nel repository del cliente, il codice è suo dal primo commit e il passaggio di consegne è scritto nel contratto all’inizio, non negoziato alla fine.
Abbiamo ancora un’applicazione Xamarin. Quanto è urgente?
Xamarin non è più supportato dal 1 maggio 2024. Se la vostra applicazione è ancora in distribuzione, lo è su un framework che non riceve aggiornamenti da oltre due anni, e le scadenze degli store sono pubbliche e annuali. Il primo passo utile è piccolo: qualche giorno di valutazione che stabilisca cosa si porta meccanicamente, cosa va riscritto e quale sia l’intervallo realistico. Quel documento potete portarlo a qualsiasi fornitore.
Se questa è la vostra situazione
Probabilmente sapete già se avete un problema Xamarin
Il framework non è più supportato dal 1 maggio 2024, e le scadenze degli store sono annuali e pubbliche. La domanda non è se spostarsi, ma quanto costa.
Valutazione della migrazione
Cosa si porta meccanicamente, cosa va riscritto e un intervallo con le sue ipotesi scritte accanto. Il documento è vostro — portatelo a qualsiasi fornitore.
AltroAltri sistemi in produzione
Monitoraggio della compliance normativa per una holding finanziaria, rilevamento delle minacce nel traffico SMS e una piattaforma comunale al servizio di circa 80.000 residenti.