Per aggiungere i pagamenti Stripe a un'app creata con l'IA, scegliete il prodotto Stripe adatto a ciò che vendete (un Payment Link, Checkout oppure Checkout con abbonamento), tenete la chiave segreta di Stripe sul server in una edge function e lasciate che sia un webhook, non la pagina di successo, a scrivere lo stato "pagato" nel database. Poi testate tutto nella modalità test di Stripe prima di passare al live. Un creatore di app con IA può scrivere tutto il codice, ma queste decisioni vanno indicate esplicitamente, un passo alla volta.
Questa guida copre le tre opzioni di Stripe, la configurazione lato server, il webhook, il portale clienti, i test e i prompt esatti da inviare. Per il contesto più ampio sulla creazione dell'app, vedete la nostra guida a come creare un'app con l'IA.
Payment Link, Checkout o abbonamenti: quale scegliere
Usate un Payment Link quando vendete qualcosa di semplice e la vostra app non deve reagire in tempo reale, usate Checkout quando è la vostra app a decidere cosa addebitare e chi paga, e usate una sessione Checkout in modalità abbonamento quando l'accesso dipende da un piano ricorrente. Secondo la documentazione di Stripe sui Payment Link, un Payment Link è una pagina ospitata da Stripe che create senza codice e condividete tramite link, codice QR o un pulsante di acquisto incorporabile. Può vendere un prodotto, un abbonamento o raccogliere donazioni, con una personalizzazione grafica limitata.
Checkout è lo stesso tipo di pagina di pagamento, ma è il vostro codice a crearla tramite le Checkout Sessions API, come descritto nella documentazione di Stripe su Checkout. Per questo la vostra app può associare il pagamento a un utente connesso, scegliere il prezzo dal database e rimandare il cliente alla schermata giusta. Checkout può essere una pagina ospitata da Stripe o un modulo incorporato nel vostro sito.
| Opzione | Codice necessario | Sa quale utente ha pagato | Ideale per | Limite principale |
|---|---|---|---|---|
| Payment Link | Nessuno per crearlo | Solo associando in seguito l'email o un parametro dell'URL | Una prima vendita, un prodotto singolo, una donazione, una prevendita | Personalizzazione limitata; la vostra app non è coinvolta a meno di aggiungere un webhook |
| Checkout (pagamento singolo) | Una funzione server | Sì, passate l'id dell'utente alla creazione della sessione | Acquisto di crediti, un report a pagamento, una caparra per una prenotazione | Dovete mantenere la funzione e il webhook |
| Checkout (modalità abbonamento) | Una funzione server più la gestione dei webhook | Sì | Piani SaaS, abbonamenti associativi, tutto ciò che si fattura ogni mese o anno | Rinnovi, pagamenti non riusciti e cancellazioni arrivano tutti in un secondo momento e vanno gestiti |
La chiave segreta non va mai nel browser
La chiave segreta di Stripe deve stare solo su un server, perché chiunque la possieda può creare addebiti, emettere rimborsi e leggere i dati dei clienti. Al browser serve soltanto un URL di Checkout di breve durata, che il vostro server restituisce dopo aver chiamato Stripe. Un creatore di app con IA che inserisce la chiave segreta in un file React ha reso l'app insicura, ed è la prima cosa da verificare in qualsiasi codice di pagamento generato.
Lo schema standard è una edge function, un piccolo pezzo di codice server che gira accanto al database. Il browser la chiama con il login dell'utente, la funzione verifica chi è, crea la sessione Checkout con la chiave segreta e restituisce l'URL. La chiave stessa è conservata come variabile d'ambiente, mai nel codice. La nostra guida alla sicurezza del vibe coding elenca gli altri controlli da eseguire sul codice generato.
Perché il database si aggiorna dal webhook e non dalla pagina di successo
Segnate un ordine come pagato solo quando è Stripe a comunicarlo al vostro server tramite un webhook, mai quando il cliente arriva sulla pagina di successo. La pagina di successo è solo una scheda del browser: può essere chiusa prima che si carichi, aperta da qualcuno che ha digitato l'indirizzo, o non essere mai raggiunta perché la connessione del cliente è caduta dopo il pagamento. Un webhook è Stripe che chiama direttamente il vostro server, e la documentazione di Stripe sui webhook lo descrive come il modo di reagire a eventi asincroni come la conferma di un pagamento da parte della banca, una contestazione o l'esito positivo di un pagamento ricorrente.
Un gestore di webhook deve avere quattro proprietà:
- Verifica la firma. Ogni richiesta porta un'intestazione
Stripe-Signature. Il gestore la controlla con il segreto del vostro endpoint, così un estraneo che invia falsi eventi "pagato" viene respinto. Anche il timestamp contenuto nell'intestazione limita i replay. - Risponde in fretta con un codice di successo. Stripe si aspetta una risposta 2xx. In modalità live continua a riprovare una consegna non riuscita fino a tre giorni, con ritardi crescenti; in modalità test fa tre tentativi nell'arco di alcune ore.
- Si può eseguire due volte senza danni. Con i nuovi tentativi lo stesso evento può arrivare più di una volta. Conservate l'id dell'evento, oppure scrivete lo stato in modo da ottenere lo stesso risultato alla seconda esecuzione.
- È raggiungibile senza login utente. Stripe non è un utente connesso della vostra app, quindi questa funzione deve accettare richieste senza il normale controllo di login e affidarsi invece alla firma.
Cosa conservare nel database
Conservate l'id cliente Stripe, l'id dell'abbonamento, il piano e lo stato dell'abbonamento accanto a ciascun utente, e aggiornateli solo dagli eventi dei webhook. La vostra app legge così una sola riga locale per decidere cosa può fare un utente, senza chiamare Stripe a ogni pagina. Per gli abbonamenti, la guida di Stripe ai webhook degli abbonamenti elenca gli eventi e gli stati da gestire:
| Segnale di Stripe | Cosa significa | Cosa fa la vostra app |
|---|---|---|
invoice.paid | Una fattura, compreso un rinnovo, è stata pagata | Concede o prolunga l'accesso (Stripe consiglia di verificare prima che lo stato dell'abbonamento sia active) |
invoice.payment_failed | Un tentativo di pagamento non è riuscito | Avvisa il cliente e gli chiede di aggiornare la carta |
customer.subscription.updated | Sono cambiati il piano, il rinnovo o lo stato | Copia il nuovo piano e lo stato nella vostra tabella |
customer.subscription.deleted | L'abbonamento è terminato | Rimuove l'accesso a pagamento |
Stato past_due | L'ultimo pagamento non è riuscito, Stripe può riprovare | Avvisa il cliente; decidete per quanto tempo mantenere l'accesso |
Stato canceled o unpaid | Non sta più pagando | Revoca l'accesso, secondo le indicazioni di Stripe |
Poiché gli utenti leggono il proprio piano da questa tabella, serve la row level security: un utente può leggere la propria riga e nessuno può scrivere nella tabella dal browser. Scrive solo la funzione webhook, che gira con una chiave lato server. La nostra guida alla row level security di Supabase spiega la policy.
Lasciate che i clienti disdicano dal portale clienti
Usate il portale clienti di Stripe per le disdette, gli aggiornamenti della carta e le fatture, invece di costruire quelle schermate. Secondo la documentazione di Stripe sul portale clienti, i clienti possono aggiornare i dati di fatturazione e i metodi di pagamento, cambiare o sospendere un abbonamento, disdire subito o alla fine del periodo di fatturazione, e vedere o pagare le fatture. Si configura nella Stripe Dashboard.
La vostra app ha bisogno di un solo pulsante, "Gestisci la fatturazione", che chiama una seconda edge function. La funzione crea una sessione del portale per l'id cliente Stripe dell'utente connesso e restituisce un URL. Due limiti della stessa pagina contano: il portale non può essere mostrato dentro un iframe, e il link di una nuova sessione scade dopo 5 minuti, quindi createlo quando l'utente clicca, non in anticipo. Le disdette fatte lì arrivano al vostro database attraverso gli stessi eventi dei webhook, quindi non serve altro codice.
Modalità test e carte di test
Testate tutto con le chiavi di test di Stripe prima di toccare la modalità live, perché gli ambienti di test sono isolati e non muovono denaro reale. Secondo la guida di Stripe ai test, nei test non si devono mai usare dati reali di una carta. Queste sono le carte da provare:
| Scenario | Numero della carta |
|---|---|
| Pagamento riuscito | 4242 4242 4242 4242 |
| Rifiuto generico | 4000 0000 0000 0002 |
| Fondi insufficienti | 4000 0000 0000 9995 |
| 3D Secure, autenticazione richiesta salvo configurazione già fatta | 4000 0025 0000 3155 |
Come scadenza usate una qualsiasi data futura, come CVC tre cifre qualsiasi, e un valore qualsiasi per gli altri campi. Eseguite almeno quattro scenari: un pagamento riuscito, una carta rifiutata, una disdetta dal portale e un webhook consegnato due volte. Controllate la riga del database dopo ciascuno.
Commissioni, imposte e fatture
La commissione standard di Stripe sulle carte è una percentuale di ogni pagamento più un importo fisso, ed entrambi variano da paese a paese, quindi leggete la cifra per il vostro paese su stripe.com/pricing prima di fissare i prezzi. Nelle pagine che abbiamo potuto leggere a novembre 2026 non abbiamo trovato una tariffa per gli Stati Uniti, quindi qui non indichiamo alcuna commissione sulle carte. La stessa pagina mostra Billing, il prodotto per gli abbonamenti, come costo separato sul volume ricorrente (0,7% con pagamento a consumo, verificato a novembre 2026 nella pagina prezzi francese), e Stripe Tax come un'altra voce facoltativa.
In sintesi: Checkout e Payment Link supportano entrambi Stripe Tax, che calcola per voi l'imposta sulle vendite o l'IVA, e Stripe può inviare automaticamente ricevute e fatture. Stabilire se dovete registrarvi e riscuotere l'imposta dipende da dove vi trovate voi e da dove si trovano i vostri clienti, quindi chiedete a un commercialista prima del lancio invece di chiederlo a un creatore di app con IA.
I prompt da inviare, un passo alla volta
Inviate questi prompt in ordine e controllate ogni risultato prima del successivo, perché un unico prompt che chiede pagamenti, webhook e portale insieme produce codice difficile da correggere. Create prima il vostro account Stripe, un prodotto e un prezzo in modalità test, e tenete a portata di mano l'id del prezzo. Sostituite le parti tra [parentesi quadre].
- Checkout. "Aggiungi una pagina Prezzi con un piano [Pro] a [$19 al mese]. Il pulsante Abbonati chiama una funzione server che verifica che l'utente sia connesso, crea una sessione Stripe Checkout in modalità abbonamento per l'id prezzo [price_xxx] con l'id dell'utente allegato, e restituisce l'URL. Reindirizza il browser verso di esso. La chiave segreta di Stripe deve essere usata solo dentro quella funzione."
- Database. "Crea una tabella subscriptions con id utente, id cliente Stripe, id abbonamento, piano, stato e fine del periodo corrente. Aggiungi la row level security in modo che un utente possa leggere solo la propria riga e nulla possa essere scritto dal browser."
- Webhook. "Crea una funzione webhook Stripe che verifica l'intestazione Stripe-Signature con il segreto del webhook, poi gestisce checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated e customer.subscription.deleted aggiornando la tabella subscriptions. Deve poter ricevere due volte lo stesso evento senza problemi e non deve richiedere il login di un utente."
- Accesso. "Leggi la tabella subscriptions per decidere cosa può usare un utente. Mostra uno stato bloccato con un pulsante di upgrade su [funzionalità] per gli utenti il cui stato non è active o trialing. Non fidarti mai della pagina di successo per sbloccare qualcosa."
- Portale. "Aggiungi nelle impostazioni un pulsante Gestisci la fatturazione che chiama una funzione server che crea una sessione del portale clienti Stripe per l'utente corrente e ne restituisce l'URL."
- Errori di pagamento. "Quando un pagamento fallisce, mostra un banner che chiede all'utente di aggiornare la carta, con un link al portale."
Il primo messaggio è quello che conta di più; la nostra guida su come scrivere i prompt per costruire un'app ne spiega il motivo.
Come lo fa Cadrant
Cadrant, il nostro creatore di app, genera web app React con un backend Supabase e gestisce Stripe tramite edge function Supabase nel vostro progetto Supabase. Chiedete l'integrazione in chat, ad esempio "Aggiungi il pagamento Stripe per gli abbonamenti". Cadrant scrive il codice della edge function e lo distribuisce nel vostro progetto Supabase. Secondo la nostra documentazione sulle edge function, il browser chiama la funzione tramite l'API di Supabase e le chiavi non lo raggiungono mai.
La chiave la aggiungete voi nel pannello Environment del progetto, sotto il pannello Database, come variabile del tipo STRIPE_SECRET_KEY, e il segreto del webhook come seconda variabile. Secondo la pagina sulle variabili d'ambiente, le variabili sono disponibili solo al codice server e si possono modificare senza ridistribuire l'app. Non incollate mai una chiave segreta nella chat. L'IA scrive anche le migrazioni del database con la row level security, quindi la tabella subscriptions del passo 2 segue le stesse regole del resto dei vostri dati.
Cadrant non è l'unico modo per farlo. Qualsiasi creatore di app che genera funzioni server può seguire gli stessi passi, e se volete il pieno controllo sulla logica di fatturazione, far rivedere il codice generato a uno sviluppatore prima del lancio resta una buona idea. In ogni caso Stripe gestisce il denaro e i dati delle carte; il vostro codice decide soltanto chi ottiene l'accesso.
Quando i pagamenti funzionano, pubblicate sul vostro dominio; la nostra guida su come pubblicare una web app copre quel passaggio.