Ehi — ho visto il tuo messaggio stamattina, lo screenshot di qualcuno che chiede "come faccio a pagarti per questo" nella casella di supporto della tua app. Congratulazioni, sinceramente. Quello è il momento in cui un side project smette di essere una demo. È anche il momento in cui un centinaio di piccole decisioni che hai potuto rimandare finora si presentano tutte lo stesso martedì. Mi hai chiesto di dirti semplicemente cosa fare. Lo farò, ma prima voglio spiegarti il perché, perché il "perché" è ciò che ti evita di dovermelo richiedere tra tre mesi, quando sarà Lemon Squeezy invece di Stripe, o abbonamenti invece di acquisto una tantum.
La decisione che stai davvero prendendo
L'hai posta come "quale payment provider dovrei usare", ma in realtà sono due decisioni sovrapposte. Primo: vuoi essere tu il merchant of record, o vuoi che lo sia qualcun altro? Secondo: qual è la forma della tua fatturazione — acquisto una tantum, abbonamento, o a consumo? Se sbagli la prima, tra sei mesi passerai un weekend a registrarti per l'IVA in un paese che non hai mai visitato. Se sbagli la seconda, è una migrazione fastidiosa, non legale, quindi è la meno spaventosa delle due.
Essere il merchant of record significa che sei tu, legalmente, a vendere il prodotto. Incassi il denaro, sei responsabile di calcolare le imposte sulle vendite e l'IVA in ogni giurisdizione in cui vivono i tuoi clienti, e devi presentare le relative dichiarazioni. Stripe calcolerà volentieri quell'imposta per te (Stripe Tax), ma calcolare non è versare — devi comunque registrarti e presentare dichiarazioni in ogni luogo in cui superi una soglia. Un servizio merchant of record come Lemon Squeezy o Paddle toglie completamente il problema dal tuo tavolo: sono loro, legalmente, il venditore, raccolgono e versano le imposte ovunque, e ti pagano il netto. In cambio, cedi una parte del margine.
| Opzione | Chi è il venditore | Commissione tipica | Gestione delle imposte | Ideale per |
|---|---|---|---|---|
| Stripe (diretto) | Tu | ~2,9% + 0,30 $/transazione, +0,5% per Stripe Tax | Ti registri e fai la dichiarazione, Stripe si limita a calcolare | Prevedi di superare qualche migliaio al mese e vuoi commissioni più basse nel lungo periodo |
| Lemon Squeezy | Lemon Squeezy | ~5% + 0,50$/transazione | Completamente gestito, sono loro il venditore ufficiale | Sviluppatore solo, primo prodotto, non vuoi pensare minimamente alle tasse |
| Paddle | Paddle | ~5% + commissioni variabili in base alla regione | Completamente gestito, più orientato all'enterprise | SaaS con abbonamenti e alcune esigenze di fatturazione |
| PayPal | Tu | ~3,5-4,5%, contestazioni favorevoli all'acquirente | Te ne occupi tu | Clienti che si fidano specificamente di PayPal, non una scelta predefinita |
Per il punto in cui ti trovi ora — un cliente, un prodotto semplice, ancora nessuna idea se questo diventerà un business — ti consiglierei Lemon Squeezy o Paddle rispetto a Stripe diretto. I due punti percentuali in più di commissione sono un'assicurazione economica contro il rischio di diventare un contribuente accidentale in uno stato in cui non hai mai messo piede. Potrai migrare a Stripe diretto più avanti, quando il volume giustificherà il cambio e avrai lo stomaco per la burocrazia. Nessuno cambia provider di pagamento per divertimento, ma è un problema risolvibile in un martedì, non in un anno.
Ho fatto io stesso questo errore in un progetto precedente — sono andato dritto su Stripe perché "usano tutti Stripe", ho incassato qualche centinaio di dollari al mese da una manciata di clienti europei, e diciotto mesi dopo ho ricevuto un'email molto educata ma molto confusa sulla registrazione VAT MOSS. Mi è costato un pomeriggio di un commercialista e quaranta minuti di puro panico a cercare su Google "devo dei soldi all'Olanda". Non catastrofico. Anche del tutto evitabile.
Prima di toccare le chiavi live
Qualunque cosa tu scelga, non collegarla prima in modalità produzione. Ognuno di questi provider ha una modalità test/sandbox con numeri di carta fittizi che innescano esiti specifici — addebito riuscito, carta rifiutata, richiesta di 3D Secure, fondi insufficienti. Provali tutti prima di toccare una chiave reale. I percorsi di errore sono quelli che incontrerai davvero nella prima settimana, ed è molto meno divertente eseguirne il debug dal vivo con la carta di una persona reale collegata.
Nella tua chat di build, sii esplicito sul fatto che vuoi procedere per fasi: chiedi che l'integrazione sia collegata prima in modalità test, con un banner o un flag ben visibile in modo che nessuno — te compreso, quello futuro — addebiti per sbaglio una carta reale durante i test. Poi prevedi un secondo passaggio deliberato per inserire le chiavi live. Due prompt, non uno, anche se sarebbe più veloce dire semplicemente "aggiungi i pagamenti" e lasciare che indovini quale modalità usare. L'attrito è proprio il punto.
Devi anche decidere cosa succede quando un webhook scatta e il tuo server è offline, o lento, o l'evento arriva due volte. Non è un'ipotesi — succede regolarmente nella prima settimana. Gli eventi che devi assolutamente gestire, come minimo:
checkout.session.completed(o l'equivalente) — concedi l'accesso, questo è il momento in cui il cliente diventa clienteinvoice.payment_failed— per gli abbonamenti, decidi ora se si tratta di un blocco immediato o di un periodo di grazia, perché "blocco immediato" è una pessima prima impressione per una carta che ha appena avuto un intoppo temporaneocustomer.subscription.deleted— qualcuno ha annullato, revoca l'accesso alla fine del periodo, non immediatamente, a meno che i tuoi termini non dicano diversamente- Un evento di rimborso — decidi una volta per tutte, per iscritto a te stesso, quale sia davvero la tua politica di rimborso, prima che la prima richiesta di rimborso ti costringa a deciderla in diretta
L'idempotenza conta qui più che quasi ovunque altro nella tua app. Se un webhook arriva due volte — e succederà, i provider ritentano su qualsiasi risposta non-200 — non puoi concedere l'accesso due volte o, peggio, addebitare due volte lo stato interno. Salva l'ID dell'evento e verifica di non averlo già elaborato prima di agire.
La domanda sui prezzi che stai evitando
Nel tuo messaggio hai detto di non essere sicuro se addebitare 9$/mese o 49$ una tantum. Non credo che nessuna delle due sia sbagliata, ma nota cosa stai davvero evitando: la conversazione con il cliente su quale sia il valore ricorrente. Un prezzo una tantum è più facile da accettare per il cliente ed è più facile da costruire per te (niente dunning, niente gestione di rinnovi falliti, niente flusso di cancellazione). Un abbonamento è una scommessa sul fatto che continuerai a migliorare il prodotto abbastanza da evitare l'abbandono — un impegno reale, non solo una casella nella pagina dei prezzi. Se non sei sicuro di lavorarci ancora attivamente tra sei mesi, un prezzo una tantum è l'offerta più onesta. Puoi sempre aggiungere un livello in abbonamento più avanti, quando ci sarà qualcosa di continuativo a cui abbonarsi.
Un'ultima cosa, poi ti lascio tornare al lavoro: metti una vera politica di rimborso e cancellazione sulla pagina prima di incassare il primo dollaro, anche se sono solo tre frasi. Non perché qualcuno ti farà causa per un addebito da 9$, ma perché scriverla ti costringe a deciderla davvero, e "ci penserò quando qualcuno me lo chiederà" è il modo in cui finisci per prendere una decisione politica nel mezzo di un'email arrabbiata invece che in un pomeriggio tranquillo.
Vai a collegare prima la sandbox. Scrivimi quando avrai fatto passare una carta rifiutata fittizia — quella è la versione di "funziona" che conta davvero.
