Pagamenti per un'attività individuale: Stripe, Paddle, Lemon Squeezy o WeChat Pay

Avvertenza: questo testo non offre consulenza fiscale, legale, societaria, valutaria o di eleggibilità. Per Merchant of Record, VAT/GST/sales tax, entità nazionali o estere e versamenti, consulta termini e professionisti qualificati.

Il tuo pricing.ts definisce starter_monthly, pro_yearly, lifetime_license e wechat_one_time, ma il database ha solo is_paid. Arriva checkout.session.completed e il cliente torna da success_url, però entitlements resta vuoto. Non è un problema del pulsante: il sistema non collega prodotti, ordini, abbonamenti e accessi.

Prima di scegliere bisogna rispondere a cinque domande: cosa vendere, come fatturare, a chi, chi risponde della transazione e delle imposte sulle vendite, e chi abilita l’accesso dopo il pagamento. I quattro servizi coprono livelli diversi.

Definire il modello di vendita prima del provider

L’acquisto singolo ruota intorno a ordine e consegna. Un abbonamento SaaS richiede tutto il billing lifecycle. Il consumo richiede anche dati tracciabili. Porta prima il modello in products, prices e tabelle locali.

Modello di vendita	Punti di partenza	Eventi asincroni chiave	Tabelle locali
Prodotto digitale singolo	Stripe / Paddle / Lemon Squeezy	checkout.session.completed / transaction.completed / order_created	orders + entitlements
Abbonamento SaaS	Stripe Billing / Paddle Billing / Lemon Squeezy	customer.subscription.* / subscription.*	subscriptions + entitlements + usage_events se serve
Abbonamento e acquisto singolo	Stripe Billing / Paddle Billing	Più eventi	orders + subscriptions + entitlements
Cina continentale o WeChat	WeChat Pay (JSAPI/H5/Native)	Callback e query ordine	orders + wechat_prepay

Tre punti importanti:

• Un prodotto singolo richiede ordine, consegna, rimborso e reinvio, non l’intero ciclo di abbonamento.
• Un SaaS ricorrente richiede subscriptions con current_period_start/end, cancel_at e status; il consumo aggiunge usage_events verificabili.
• WeChat Pay è un metodo di pagamento e sistema commerciale, non un Merchant of Record globale o una piattaforma SaaS billing.

Le capacità cambiano. Prima di integrare, controlla regione dell’account, modalità prodotto, metodi, versione API e termini.

Un Merchant of Record non elimina ogni responsabilità

Il Merchant of Record, o MoR, è il venditore registrato della transazione. Paddle e Lemon Squeezy usano questo modello per prodotti digitali idonei e gestiscono pagamento, imposte sulle vendite, rimborsi o contestazioni nel relativo ambito. Il lavoro fiscale globale diminuisce, ma restano obblighi su reddito, entità, prodotto, dati e contabilità.

Con Stripe, il commerciante resta di solito il venditore registrato. Stripe Tax aiuta a calcolare sales tax, VAT e GST e offre strumenti di monitoraggio e registrazione, ma non trasforma Stripe in Merchant of Record. Registrazione e dichiarazione dipendono da giurisdizione e transazione.

Non scegliere un MoR con una soglia fissa di ricavi. Confronta:

Dimensione	Stack payment e billing proprio	Merchant of Record
Personalizzazione	Combinare Checkout, Billing, Tax, fatture e processi interni	Seguire politica prodotto, checkout, contratto e versamenti
Operazioni fiscali e billing	Il venditore verifica registrazione, dichiarazione, fatture, rimborsi e contestazioni	Il MoR assume imposte, pagamento e parte della compliance nelle transazioni coperte
Costo	Sommare strumenti fiscali, sviluppo, finanza e supporto alla commissione	Valutare versamenti, rimborsi, extra e limiti, non solo percentuale
Quando conviene	Molta personalizzazione, operazioni esistenti o contratti speciali	Meno lavoro fiscale globale e sugli abbonamenti per prodotti idonei

Il confine contrattuale e fiscale dipende da entità, territorio, prodotto e cliente. Una pagina marketing non sostituisce termini o consulenza.

Scegliere Stripe, Paddle, Lemon Squeezy o WeChat Pay

Se servono abbonamenti e WeChat Pay, separa i problemi. Ciclo dell’abbonamento, pagamenti globali e Cina possono usare servizi diversi. Un metodo elencato non funziona necessariamente in ogni regione, modalità Checkout o ricorrenza.

Servizio	Responsabilità	Abbonamenti e acquisti singoli	Pagamenti Cina	Licenza nativa	Buon punto di partenza
Stripe	Payment, Billing e Tax; di solito non MoR	Checkout e Billing personalizzabili	Alipay/WeChat Pay dipendono da regione, valuta e modalità	Nessun License Key generale	SaaS che controlla pagamenti, abbonamenti, imposte e processi
Paddle	Merchant of Record	Paddle Billing e Checkout	Controllare Dashboard e documentazione per account e regione	L’app gestisce accesso	Software che riduce imposte globali e operazioni ricorrenti
Lemon Squeezy	Merchant of Record	Digitali, abbonamenti semplici e consumo	Alipay/WeChat Pay per acquisti singoli; ricorrenza limitata	License Keys	Digitali, licenze e primi abbonamenti
WeChat Pay	Metodo di pagamento e sistema commerciale	JSAPI/H5/Native; billing proprio	Cina continentale e WeChat	Nessuna	Acquisti singoli in RMB e checkout WeChat

La documentazione ufficiale confermava il 18 luglio 2026:

• Stripe Checkout offre pagine hosted, embedded e componenti combinabili. I metodi dipendono da regione, valuta e modalità Checkout.
• Paddle consegna webhook almeno una volta. Senza 200 in cinque secondi riprova. Gli eventi possono duplicarsi o arrivare fuori ordine; usa event_id e occurred_at.
• Lemon Squeezy elenca Cards, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay, Cash App Pay e bank debits. Gli abbonamenti accettano solo Cards, Apple Pay, Google Pay e PayPal.
• WeChat Pay H5 richiede ordine server, callback e query attiva. Il ritorno del browser non è definitivo.

Commissioni, metodi, versamenti, paesi e politiche cambiano. Consulta prezzi e contratti correnti per il budget.

Il webhook è il confine della sincronizzazione degli accessi

Due errori comuni:

1. checkout.session.completed arriva e success_url si apre, ma entitlements non cambia e il cliente non accede.
2. Lo stesso evento entra due volte in webhook_events e l’handler emette due licenze.

Entrambi trattano una richiesta HTTP o una pagina di successo come verità finale. Gli eventi possono duplicarsi, ritardare o arrivare fuori ordine; alcuni stati richiedono query o eventi successivi.

Principi per l’endpoint webhook

Principio	Stripe	Paddle	Lemon Squeezy	WeChat Pay
HTTPS endpoint	Obbligatorio	Obbligatorio	Obbligatorio	Obbligatorio
Verifica firma	Stripe-Signature	Paddle-Signature	X-Signature	Firma WeChat Pay API v3
Chiave idempotente	ID evento o oggetto	event_id	Tipo + ID oggetto o chiave unica	out_trade_no e ID transazione
Risposta	Verificare e salvare, rispondere subito, elaborare in asincrono	200 entro cinque secondi	Rispondere successo e procedere in asincrono	Seguire il contratto attuale
Compensazione	Query pagamento o abbonamento	Query entità e reconciliation	Query ordine o abbonamento	Query, riconciliazione e recupero manuale

Regole operative:

• Webhook o callback avvia la sincronizzazione. success_url mostra soltanto l’elaborazione.
• Verifica la firma e salva evento o campi in webhook_events; sposta il lavoro complesso in un job asincrono.
• Imposta un vincolo univoco e registra event_id, source, occurred_at, processed_at, status e payload_hash.
• Per l’ordine confronta orario, aggiornamento oggetto o versione di stato, non solo l’arrivo.
• Esegui reconciliation, interroga ordine o abbonamento e conserva il recupero manuale.

Tabelle per ordini, abbonamenti, accessi ed eventi

Tabella	Campi principali	Stripe	Paddle	Lemon Squeezy
orders	provider_order_id, customer_id, amount, currency, status, created_at	Checkout Session / PaymentIntent	transaction	order
subscriptions	provider_subscription_id, customer_id, status, current_period_end, cancel_at	subscription	subscription	subscription
entitlements	user_id, product_id, feature_key, source, status, expires_at	Derivato da order o subscription	Derivato da transaction o subscription	Derivato da order, subscription o license
webhook_events	provider, event_id, occurred_at, processed_at, status, payload_hash	Idempotenza e audit	Idempotenza e ordine	Idempotenza e audit

Non copiare ogni oggetto API. Definisci campi stabili per l’accesso e conserva gli ID del provider per query e reconciliation.

Strategie di sincronizzazione degli accessi

Strategia	Quando usarla	Implementazione
Lean cache	La maggior parte dei SaaS ricorrenti	Salvare customer, subscription, status, price e product necessari e aggiornare con gli eventi
State mirror	Viste offline o pannelli operativi complessi	Replicare più dati, registrare aggiornamento e prevenire differenze con reconciliation
License key	Prodotto digitale singolo o desktop	Salvare instance ID e verificare store, product, variant e customer; la chiave non è un sistema utenti

Paddle consiglia lean cache per la maggior parte delle app. Usa state mirror solo per query locali necessarie. Anche le chiavi Lemon Squeezy richiedono la verifica di prodotto e cliente e l’associazione dell’instance ad account e dispositivo.

Punti di integrazione per ogni servizio

Questi punti delimitano la prima implementazione e non sostituiscono la documentazione completa.

Integrare Stripe

Un SaaS iniziale può usare Checkout hosted e Customer Portal anziché mantenere un modulo carta. Stripe Billing gestisce abbonamenti, fatture, consumo e revenue recovery. Stripe Tax è uno strumento fiscale, non un MoR.

Prodotti e prezzi vanno mappati agli accessi: product_id è prodotto o pacchetto; price_id mensile, annuale, seat o usage. Non lasciare solo is_paid in users.

Il tutorial Next.js su carrello e Stripe copre Checkout Session, endpoint webhook e ordini.

Integrare Paddle

Verifica che il tutorial usi Paddle Billing, non Paddle Classic. Cambiano API, webhook, Paddle.js e Product/Price.

Paddle Checkout mostra la cassa, ma l’app esegue provisioning. Di solito bastano customer, subscription, status, price, product e scheduled change. Crea state mirror solo se servono dati completi.

Aggiorna via webhook ed esegui reconciliation. Un MoR non sa automaticamente chi può usare ogni funzione.

Integrare Lemon Squeezy

Lemon Squeezy è adatto a prodotti digitali, licenze e abbonamenti semplici. Offre MoR, checkout, subscriptions, usage-based billing, webhooks e License Keys. Verifica costi e ambito nello store plan corrente.

Dopo l’attivazione salva instance ID e verifica store_id, product_id, variant_id e customer. Una chiave altrui o rivenduta non deve attivare Pro.

Per un abbonamento WeChat Pay controlla separatamente i metodi ricorrenti. La documentazione elenca WeChat Pay e Alipay, ma gli abbonamenti accettano Cards, Apple Pay, Google Pay e PayPal.

Limiti di WeChat Pay

WeChat Pay funziona in Cina continentale e WeChat, ma non è MoR globale né ciclo SaaS completo. Il venditore gestisce stato, firma, query, rimborsi, reconciliation, fatture e accessi.

H5, JSAPI, Mini Program e Native sono scenari di pagamento. In H5 il backend crea l’ordine e passa h5_url; al ritorno del browser interroga e applica il callback allo stesso out_trade_no.

Controlla autorizzazioni, entità, domini, commissioni e parametri nella documentazione WeChat Pay attuale.

Passo successivo: trasformare il pulsante in una macchina a stati testabile

Dopo la scelta, dividi l’integrazione in attività verificabili:

1. Crea orders, subscriptions, entitlements e webhook_events; aggiungi usage_events per il consumo.
2. Implementa firma, idempotenza, ordine inverso, risposta rapida e recupero per ogni webhook o callback.
3. Fai interrogare lo stato locale alla pagina di successo invece di scrivere is_paid=true.
4. Aggiungi test di query, reconciliation, rimborso, rinnovo fallito e recupero manuale.
5. Reinvia eventi e inverti aggiornamenti nella sandbox; l’accesso non deve duplicarsi o tornare indietro per errore.

Per backend e database continua con Supabase Edge Functions e gli articoli backend e dati della serie. Completare non significa tornare dalla pagina di pagamento: ordini, abbonamenti e accessi devono convergere nonostante duplicati, ritardi, disordine e rimborsi.