Pagamenti nella tua app fatta con l'AI: 7 controlli prima di attivarli

La tua app fatta con Lovable, Cursor o Bolt sta per attivare Stripe o un altro sistema di pagamento? Allora è il momento giusto per rileggere il codice. Con i pagamenti, un errore costa soldi veri: tuoi o dei tuoi clienti.

In un'app che ho letto, il piano Pro si sbloccava dal browser: bastava cambiare una variabile per usarlo senza pagare. In più, il webhook dei pagamenti non verificava la firma. Li ho corretti entrambi: ora è il server a verificare l'abbonamento e la firma. Sono due errori facili da fare nelle app fatte con l'AI, e si possono controllare prima del lancio.

I 7 controlli da fare prima di attivare i pagamenti

1. Il server decide chi ha pagato

Il browser può mostrare il piano Pro, ma non deve essere lui a deciderlo. Chi ha pagato lo scrive solo il server, quando arriva la conferma dal sistema di pagamento.

Prova così: entra con un utente gratuito e cambia nel browser il valore del piano. Se l'app ti fa usare davvero le funzioni a pagamento, non solo vederle, il controllo sul server manca.

2. Il webhook verifica la firma

Il webhook è il messaggio con cui Stripe avvisa la tua app che un pagamento è andato a buon fine. Stripe firma ogni messaggio. Il server deve controllare la firma prima di fidarsi: senza questo controllo, chiunque può mandare un falso «pagato».

3. Le chiavi segrete restano sul server

Stripe ti dà una chiave pubblicabile e una chiave segreta. La chiave pubblicabile può stare nel browser. La chiave segreta e il segreto del webhook devono stare solo nelle variabili d'ambiente del server.

Cerca nel codice che arriva al browser e nel repository. Se trovi una chiave che inizia con sk_ o rk_, o un segreto che inizia con whsec_, rigeneralo subito dal pannello di Stripe.

4. Le prove usano un ambiente di test

Stripe ha una modalità di test, con chiavi diverse da quelle vere. Finché provi, usa le chiavi di test e un database di prova. Così una prova non crea abbonamenti veri e un errore non tocca i clienti.

5. Decidi cosa succede se un pagamento fallisce

Una carta scade, un rinnovo non passa, un utente annulla. Decidi prima cosa vede l'utente e cosa succede al suo accesso in ognuno di questi casi. Poi prova ogni caso in modalità test.

6. Ogni pagamento si registra una volta sola

Stripe può mandare lo stesso webhook più di una volta. Il server deve riconoscere un evento già ricevuto e registrare il pagamento una volta sola. Altrimenti un abbonamento può risultare attivato due volte.

Gli avvisi possono anche arrivare in ordine diverso: per esempio la disdetta prima del rinnovo. Il server deve controllare lo stato attuale dell'abbonamento invece di fidarsi dell'ultimo avviso arrivato.

7. Rimborsi e registri sono pronti

Prima del primo pagamento, sappi come fare un rimborso e dove lo vedi nell'app. Tieni anche un registro di ogni evento di pagamento ricevuto. Quando un cliente ti scrive «ho pagato, ma non vedo niente», trovi la risposta in quel registro.

Cosa questi controlli non coprono

Questi controlli trovano gli errori più evidenti, non tutti. Se la tua app ha più piani, coupon o prove gratuite, la logica dei pagamenti si complica e gli errori stanno nei dettagli. Prima di aprire i pagamenti a clienti veri, conviene far rileggere il codice a qualcuno che non l'ha scritto.

Con il Check-up Codice AI controllo anche i pagamenti della tua app: chi decide se un utente ha pagato, i webhook, le chiavi segrete e i casi in cui qualcosa va storto. Ti dico cosa sistemare prima di attivarli. Il prezzo è fisso. Prima di vedere il codice, firmiamo insieme un accordo di riservatezza, e leggo il codice senza modificarlo. La pagina del Check-up Codice AI