Rollback Procedures — Hostwebo Billing V2 #

Procedure di rollback per ogni scenario di emergenza durante la migrazione Upmind → V2. Tutte le procedure sono reversibili senza perdita di dati.

Filosofia rollback #

1. MAI cancellare dati durante un rollback. Solo cambiare il flusso.
2. MAI disattivare il plugin hostwebo-billing: i webhook in arrivo devono continuare a essere processati per gli ordini V2 già esistenti.
3. SEMPRE loggare la motivazione del rollback in audit (hwbi_audit).
4. DOPO il rollback: investigare via audit log → fixare bug → re-promuovere modalità.

Scenario 1: Rollback rapido modalità #

Il rollback più comune. Da qualsiasi modalità → torna a “Solo Upmind”.

Quando usarlo #

• Bug critico in V2 segnalato da cliente
• Errore massivo provisioning Plesk
• Webhook Stripe/PayPal in errore continuo
• Fatturazione SDI Aruba in errore
• Qualsiasi situazione di “non so cosa sta succedendo, fermo tutto”

Procedura (30 secondi) #

1. Login admin: https://www.hostwebo.it/wp-admin
2. Menu laterale: Hostwebo Billing → Cutover
3. Sezione “Modalità attuale” → click 🔵 Solo Upmind
4. Conferma popup
5. Done. Tutti i nuovi visitatori vanno su Upmind. Ordini V2 esistenti restano in DB ma il flow checkout è disabilitato.

Verifica post-rollback #

# Frontend: verifica che CTA "Acquista" puntino a Upmind
curl -sL https://www.hostwebo.it/cloud-eco/ | grep -o 'href="[^"]*acquista[^"]*"'
# → deve mostrare URL Upmind, non /v2-checkout/

# Backend: verifica modalità salvata
wp option get hwbi_billing_mode --allow-root
# → "upmind_only"

Impact su clienti #

• Nuovi visitatori: non si accorgono di niente, vanno su Upmind come sempre
• Clienti con subscription V2 attiva: i loro rinnovi continuano normalmente via webhook (V2 codice NON disattivato, solo il flow checkout)
• Clienti che stavano facendo checkout V2 in quel momento: errore 503 → riprovano e vanno su Upmind

Scenario 2: Rollback Stripe sync (prodotti) #

Se hai fatto “Sync to Stripe” e Stripe è in stato inconsistente.

Procedura #

1. Stripe Dashboard → Products
2. Identifica i Products creati erroneamente (cercali per name Hostwebo *)
3. Archive ogni Product (NON delete — Stripe non permette delete su Products con Prices)
4. Su WP: Hostwebo Billing → Piani
5. Per ogni piano: edita → cancella campo stripe_product_id e stripe_price_id_*
6. Salva
7. Re-sync quando hai capito il problema

Note #

• I Prices possono essere “Inactivated” ma non cancellati
• Subscription già attive in Stripe continuano ad usare il vecchio Price
• È SICURO archiviare un Product/Price: nessun cliente attivo viene impattato

Scenario 3: Rollback PayPal sync #

Procedura #

1. PayPal Developer → Products
2. Identifica i Products creati erroneamente
3. Non puoi cancellare un Product PayPal (limitation API), ma puoi marcarli come inactive
4. Su WP: edita ogni piano → svuota paypal_product_id + paypal_plan_id_*
5. Salva

Scenario 4: Cliente paga ma il provisioning Plesk fallisce #

Sintomi #

• Pagamento Stripe/PayPal OK in audit log
• Cliente riceve email “Pagamento ricevuto” ma NON “Hosting attivato”
• Plesk subscription non creata

Procedura recovery #

1. Hostwebo Billing → Provisioning Jobs (Phase futura UI, per ora DB direct)
2. Cerca il job nello stato failed o retrying
3. Verifica il last_error: di solito è

• “Plesk API timeout” → retry automatico
• “Service plan not found” → fix mapping in Impostazioni piano
• “Customer already has subscription” → cliente è in stato edge case

1. Recovery manuale:

• Login Plesk: https://srv1.hostwebo.cloud:8443
• Crea subscription manuale per il cliente
• Su WP: Hostwebo Billing → Ordini (Phase futura) → mark order active
• Invia email manuale al cliente con credenziali

1. Refund se grave:

• Stripe Dashboard → Payment → Refund (full)
• PayPal Dashboard → Transaction → Refund
• Su WP: ordine → mark refunded (Phase futura)

Prevenzione futura #

• Verificare sempre che il Plesk service plan sia attivo prima del go-live
• Aggiungere alert in Cutover dashboard per provisioning_jobs.status = failed > 0

Scenario 5: Fattura emessa ma con dati errati #

Sintomi #

• Cliente ha ricevuto la fattura PDF
• Cliente segnala “P.IVA errata” o “ragione sociale errata”

Importante #

Una fattura emessa NON può essere modificata (compliance fiscale italiana). Bisogna emettere una nota di credito + nuova fattura.

Procedura #

1. Hostwebo Billing → Fatture → cerca la fattura
2. Identifica il numero (es. 2026/0042)
3. Per ora gestione manuale (Phase futura: pulsante “Emit credit note”):

• Crea fattura nota di credito sul commercialista
• Emetti nuova fattura corretta sul commercialista
• Su WP: nota in metadata sull’ordine “Fattura 2026/0042 sostituita da 2026/0043”

1. Aruba SDI: se la fattura è già stata trasmessa, va inviata anche la nota di credito
2. Email cliente con entrambi i PDF

Scenario 6: Webhook arriva ma payment_intent è “orphan” (no ordine collegato) #

Sintomi #

• Audit log: webhook_stripe_received + webhook_orphan_payment
• Cliente segnala “Ho pagato ma non vedo niente”

Cause possibili #

• Cliente ha pagato direttamente con Payment Link Stripe (non checkout V2)
• Bug nel client_reference_id durante checkout creation

Procedura recovery #

1. Stripe Dashboard → Payment → vedi metadata
2. Cerca email del cliente in WP utenti
3. Se utente esiste: crea manualmente un ordine V2 in DB con dati pagamento
4. Trigger manuale do_action('hwbi_order_paid', $order_id) (Phase futura: pulsante UI)
5. Provisioning si avvia
6. Email cliente

Scenario 7: Bulk-mark Upmind ha marcato utenti sbagliati #

Sintomi #

• Dopo “Marca tutti come legacy Upmind” alcuni clienti che NON dovrebbero stare su Upmind sono finiti su Upmind
• Es: hai applicato bulk a 500 utenti, ma 50 di loro erano nuovi e dovevano andare su V2

Procedura recovery #

Per singolo utente (chirurgico):

1. Login admin → Utenti
2. Edit utente → scroll a “Hostwebo Billing”
3. Campo _upmind_account_id → cancella valore
4. Salva
5. Cliente al prossimo checkout va su V2

Bulk recovery via WP-CLI (per molti utenti):

# Lista utenti marcati legacy
wp user list --meta_key='_upmind_account_id' --meta_value='legacy-pre-v2-*' --format=ids

# Unmark singolo utente
wp user meta delete <user_id> _upmind_account_id

# Unmark TUTTI quelli marcati come "legacy-pre-v2-*" (DANGEROUS)
wp user list --meta_key='_upmind_account_id' --format=ids | xargs -I {} wp user meta delete {} _upmind_account_id

Prevenzione #

• PRIMA di fare bulk-mark, leggi la lista candidates in Hostwebo Billing → Cutover
• Esegui bulk-mark SOLO quando sei pronto al passaggio MODE_V2_NEW
• Idealmente: filtra prima i candidates (utenti con plesk_client_id, ordini >0, etc.)

Scenario 8: Disastro totale — Restore DB #

Quando #

• Corruzione tabelle wp_hwbi_*
• Cancellazione accidentale di un ordine/fattura
• Hack o malfunzionamento gravissimo

Procedura #

1. STOP tutti i webhook:

• Stripe Dashboard → Webhooks → disable temporaneamente
• PayPal Developer → Webhooks → disable

1. Plesk → Database → Backup Manager → restore
2. IMPORTANTE: ripristina SOLO le tabelle wp_hwbi_*, NON tutto wp

   -- Esempio: ripristina solo hwbi_orders
   USE hostwebo_wp;
   DROP TABLE wp_hwbi_orders;
   SOURCE /backups/wp_hwbi_orders_2026-01-15.sql;
   

1. Re-enable webhooks
2. Audit log review per gli ultimi N giorni: cerca eventi mancanti
3. Re-process eventi mancanti se necessario via WP-CLI o pulsante manuale

Prevenzione #

• Backup giornaliero automatico delle tabelle wp_hwbi_* (cron Plesk)
• Audit log salva ogni evento → ricostruzione sempre possibile

Quick reference #

Contatti emergenza #

• Stripe support: https://support.stripe.com (response SLA 24h)
• PayPal Merchant: https://www.paypal.com/businesshelp (telefonico)
• Aruba SDI: support@aruba.it (slow)
• Plesk: già ospitato su srv1.hostwebo.cloud → support interno

Checklist post-incident #

Dopo OGNI rollback, completa questa checklist:

• [ ] Rollback eseguito e verificato
• [ ] Causa root identificata (via audit log o stack trace)
• [ ] Patch sviluppato e testato in staging
• [ ] Clienti impattati contattati con email scuse + spiegazione
• [ ] Aggiornata documentazione docs/architecture.md con il nuovo edge case
• [ ] Aggiunto test di regressione
• [ ] Post-mortem scritto in docs/incidents/AAAA-MM-DD-titolo.md (Phase futura)
• [ ] Re-promosso modalità target solo quando sei sicuro