Collegare sito pubblico, pagamento, attivazione account, area riservata, documenti e comunicazioni in un unico flusso operativo controllato.
Cosa e stato studiato
Il lavoro e partito dal percorso reale dell'utente: arrivo sul sito, scelta del servizio, pagamento, attivazione del profilo, ricezione delle credenziali e primo accesso. Sono stati isolati i punti in cui comunicazioni manuali, stati incoerenti o notifiche duplicate potevano generare attrito. L'analisi ha separato tre superfici diverse: racconto pubblico, processo transazionale e area protetta, per evitare che marketing, pagamento e gestione operativa finissero nello stesso blocco indistinto.
Cosa e stato fatto
Sono stati collegati dashboard, area riservata, transazioni, notifiche email, WhatsApp e servizi esterni. Il sistema registra lo stato dell'utente e coordina le azioni post-pagamento, riducendo passaggi manuali senza esporre dati personali o informazioni non pubblicabili. Il flusso e stato trattato come processo a stati: pagamento ricevuto, profilo disponibile, credenziali inviate, accesso possibile, comunicazioni successive tracciabili.
Come e stato fatto
La soluzione usa una base PHP custom con MariaDB, integrazioni PayPal, componenti Node.js, WhatsApp Business e Firebase. Le scelte tecniche sono state guidate dalla necessita di tracciare stati e comunicazioni, mantenendo il racconto pubblico separato dai dati sensibili. PHP governa dashboard, dati e flussi applicativi; Node.js e Firebase supportano aspetti realtime o notifiche; PayPal e WhatsApp sono stati integrati come servizi esterni controllati da stati interni.
Architettura e tecnologie
Come lo stack e stato usato nel progetto
Architettura a superfici separate
Nexumed e stato trattato come piattaforma verticale composta da superfici diverse: sito pubblico, area riservata, dashboard amministrativa, endpoint applicativi e integrazioni esterne. Questa separazione e stata sfruttata per non mescolare contenuti commerciali, dati riservati e processi operativi. Il sito spiega e converte, la dashboard governa, l'area riservata serve l'utente, le integrazioni agiscono solo dentro passaggi controllati.
Flusso transazionale guidato dagli stati
Il pagamento non e stato considerato un evento finale, ma l'inizio di un processo applicativo. La transazione PayPal aggiorna stati interni che determinano attivazione profilo, invio credenziali, accesso all'area riservata e comunicazioni successive. L'architettura a stati e stata sfruttata per ridurre duplicazioni e omissioni: una notifica parte perche il sistema riconosce uno stato, non perche un operatore ricorda di inviarla.
PHP custom e MariaDB come nucleo applicativo
La base PHP custom gestisce logiche di dominio, viste operative, controlli e processi amministrativi, mentre MariaDB conserva utenti, transazioni, servizi, comunicazioni e configurazioni. Questa scelta e stata sfruttata per mantenere un nucleo applicativo semplice da interrogare e da correggere, con dati relazionali utili a ricostruire cosa e successo dopo un acquisto o durante una richiesta dell'utente.
Node.js, Socket.IO e Firebase per eventi e notifiche
I componenti Node.js e Firebase sono stati usati dove servono reattivita, notifiche o aggiornamenti piu vicini al tempo reale. L'architettura separa questi aspetti dal core PHP: il processo principale resta governato dal backend applicativo, mentre i servizi realtime distribuiscono eventi, notifiche o segnali verso le interfacce. In questo modo non si blocca il flusso transazionale per ottenere un aggiornamento live.
WhatsApp Business e storico operativo
WhatsApp Business e stato integrato come canale operativo, non come chat esterna scollegata. Messaggi, contesto e stati possono essere ricondotti alla piattaforma, cosi l'azienda evita che le conversazioni importanti restino fuori dal sistema. La scelta tecnica serve a trasformare un canale informale in un punto leggibile del servizio, mantenendo pero controlli su privacy, tracciabilita e contenuti pubblicabili.
Privacy, demo e racconto pubblico
Il progetto gestisce informazioni sensibili, quindi l'architettura editoriale del caso studio e parte del lavoro tecnico. Dati reali, dettagli personali e schermate non pubblicabili devono essere filtrati o sostituiti da demo. La separazione tra superfici pubbliche e operative consente di raccontare metodo, stack e flussi senza esporre contenuti riservati o trasformare il caso studio in documentazione interna.
Pattern implementativi
Dettagli tecnici che hanno guidato le scelte
Macchina a stati per pagamento e onboarding
Il cuore tecnico e una state machine applicativa: il cliente non passa genericamente da 'pagato' a 'attivo', ma attraversa stati intermedi verificabili come transazione ricevuta, profilo creato, credenziali generate, email inviata, accesso abilitato e servizio disponibile. Questo consente di ragionare su transizioni, invarianti e casi limite: doppio pagamento, callback ripetuta, email fallita, utente gia esistente o sessione non ancora inizializzata.
Webhook idempotenti e anticorruzione verso provider esterni
PayPal, WhatsApp e Firebase sono provider esterni, quindi non devono contaminare il dominio interno. L'approccio corretto e usare adapter e layer anticorruzione: il payload del provider viene validato, normalizzato e tradotto in eventi applicativi. Le callback devono essere idempotenti, perche un webhook puo arrivare piu volte o fuori ordine; il sistema deve riconoscere transaction id, stato corrente e side effect gia eseguiti.
Outbox logica per notifiche e side effect
Le notifiche post-pagamento non dovrebbero essere un effetto collaterale fragile agganciato a una singola richiesta HTTP. La progettazione ragiona in termini di outbox applicativa: prima si registra lo stato e l'intenzione di comunicare, poi si eseguono invii email, WhatsApp o push con possibilita di retry, logging e controllo duplicati. Questo separa la consistenza del dato dalla riuscita immediata del canale.
Separazione tra dati sensibili, log e superficie pubblica
La piattaforma lavora con informazioni delicate, quindi serve data minimization: nei log, nelle schermate pubbliche e negli asset demo devono passare solo dati necessari. Questo implica redazione, separazione dei contesti, permessi granulari e attenzione a cosa viene serializzato verso frontend o integrazioni. Il caso studio puo parlare di architettura senza esporre PII, payload sanitari o dettagli operativi riservati.
Risultati e apprendimenti
Piattaforma verticale online con pagamento, onboarding, accesso riservato, comunicazioni e notifiche collegate nello stesso processo.
- l'onboarding post-pagamento va progettato come processo unico
- le notifiche devono dipendere da stati verificabili
- privacy e oscuramento degli asset sono parte del progetto editoriale