tgpay cryptoAPI
crypto-payapisubscriptionsrecurring

Riferimento API: abbonamenti

3 min di letturaAggiornata il 22 ago 2026

Fatturazione ricorrente: un’estensione rispetto a Crypto Bot. Crei un piano (importo + periodo), mandi agli utenti il suo link di approvazione, e la piattaforma li addebita sul saldo del portafoglio a ogni periodo, accreditando il saldo della tua app al netto della commissione. Le convenzioni comuni stanno nella pagina Riferimento della Merchant API.

Come è fatto

Un piano è immutabile: il mandato che l’utente approva è esattamente questo importo per questo periodo. Per cambiare il prezzo crei un piano nuovo e archivi il vecchio; chi è già abbonato continua a rinnovare alle condizioni che aveva approvato. Il primo periodo si addebita all’approvazione.

I rinnovi si fatturano da soli alla fine di ogni periodo. Quando un rinnovo non riesce (saldo insufficiente, account limitato), l’abbonamento entra in grace e la piattaforma riprova ogni ora entro il periodo di tolleranza (adesso 48 ore); se ancora non riesce a incassare, l’abbonamento diventa expired. Per l’esercente il termine dell’accesso è current_period_end.

Ogni evento del ciclo di vita ha un webhook facoltativo: subscription_activated, subscription_charged, subscription_cancelled, subscription_expired.

createSubscriptionPlan

POST /pay/api/createSubscriptionPlan — ambito subscriptions.

ParametroTipoObbligatorioDescrizione
namestringada 1 a 64 caratteri, mostrato a chi si abbona
assetstringail codice dell’asset
amountstringal’addebito per periodo, stringa decimale positiva
period_daysinteroil periodo di fatturazione in giorni, dal minimo della piattaforma (adesso 7) a 365

Il risultato è l’oggetto piano: plan_id, name, asset, amount, amount_minor, period_days, archived, mini_app_subscribe_url — il link t.me che mandi agli utenti per l’approvazione — e created_at.

Errori: 404 unknown_asset, 400 invalid_amount, 409 invalid_period, 503 subs_disabled (la funzione è disattivata lato piattaforma).

getSubscriptionPlans

GET /pay/api/getSubscriptionPlans — ambito read, nessun parametro. Restituisce {"items": [piano, …]}, dal più recente, ciascuno con un campo in più: active_subscribers, cioè il numero di abbonamenti in corso (active + grace) su quel piano.

archiveSubscriptionPlan

POST /pay/api/archiveSubscriptionPlan — ambito subscriptions. Un parametro solo: plan_id. Ferma le nuove approvazioni; gli abbonamenti esistenti continuano a rinnovarsi alle condizioni che avevano approvato (li chiudi uno a uno con cancelSubscription). L’archiviazione non si annulla dall’API. Il risultato è l’oggetto piano aggiornato, con archived: true. Errore: 404 plan_not_found.

getSubscriptions

GET /pay/api/getSubscriptions — ambito read. Filtri: plan_id, user_id, status (active / grace / cancelled / expired), più offset / count (al massimo 500). Restituisce {"items": [abbonamento, …]}, dal più recente.

L’oggetto abbonamento: subscription_id, plan_id, user_id (l’ID Telegram di chi si è abbonato), le condizioni approvate (asset, amount, amount_minor, period_days), status, auto_renew, period_no (i periodi pagati finora), current_period_start / current_period_end, created_at, cancelled_at, cancelled_by (user oppure merchant), expired_at.

cancelSubscription

POST /pay/api/cancelSubscription — ambito subscriptions. Un parametro solo: subscription_id. Ferma i rinnovi (cancelled_by: "merchant"); il periodo pagato resta utilizzabile fino a current_period_end, lo stato passa subito a cancelled e chi era abbonato viene avvisato. Un abbonamento disdetto si può riattivare più avanti dallo stesso link del piano. Il risultato è l’oggetto abbonamento aggiornato.

Errori: 404 sub_not_found, 409 sub_not_active (già disdetto o già scaduto).