Skip to main content
Il Kotlin SDK consente alle applicazioni Kotlin di accedere con tipi espliciti alla REST API di Dodo Payments. Usa i tipi Kotlin in tutto il codice: valori nullable per i campi che possono mancare, Sequence per iterare sui risultati e funzioni suspend per le chiamate asincrone.

Installazione

Gradle (Kotlin DSL)

Aggiungi la dipendenza al tuo build.gradle.kts:
build.gradle.kts

Maven

Aggiungi la dipendenza al tuo pom.xml:
pom.xml
Le nuove versioni dell’SDK aggiungono il supporto alle modifiche dell’API. Per trovare la versione più recente, consulta Maven Central.
L’SDK richiede Java 8 o versione successiva. Funziona sulla JVM e su Android e include le regole keep per ProGuard e R8.

Inizio Veloce

Crea un client, quindi crea una checkout session:
fromEnv() si connette alla modalità live, a meno che DODO_PAYMENTS_BASE_URL o dodopayments.baseUrl indichi diversamente. Per usare la modalità test, consulta Test Mode. Una chiave API della modalità test funziona solo nella modalità test.
Conserva le chiavi API nelle variabili d’ambiente o in un secrets manager. Non inserirle mai nel version control.

Funzionalità principali

Coroutines

I metodi del client asincrono sono funzioni suspend che puoi chiamare da una coroutine.

Null Safety

I campi che possono mancare sono nullable types, non Optional.

Sequences

Nel client sincrono, autoPager() restituisce un Sequence che recupera altre pagine durante l’iterazione. Nel client asincrono restituisce un Flow.

Immutable Models

Le classi model sono immutabili e toBuilder() restituisce un builder per una copia modificata.

Configurazione

Dalle variabili d’ambiente

fromEnv() legge le impostazioni dalle variabili d’ambiente o dalle system properties. Le system properties hanno la precedenza:
La chiave API proviene da DODO_PAYMENTS_API_KEY o dodopayments.apiKey. Il webhook signing secret proviene da DODO_PAYMENTS_WEBHOOK_KEY o dodopayments.webhookKey, mentre la base URL proviene da DODO_PAYMENTS_BASE_URL o dodopayments.baseUrl. Crea un solo client e riutilizzalo, perché ogni client dispone del proprio connection pool e dei propri thread pool. Per verificare un webhook, passa il raw request body e gli headers a client.webhooks().unwrap(UnwrapWebhookParams.builder().body(rawBody).headers(headers).build()), dove headers è un com.dodopayments.api.core.http.Headers. Controlla la signature con la tua webhook key e restituisce l’evento analizzato oppure genera DodoPaymentsWebhookException. Senza headers, unwrap non verifica la signature. client.webhooks().unsafeUnwrap(rawBody) analizza il body senza verificarlo, quindi usalo solo per i test. Consulta Webhooks.

Configurazione manuale

Imposta ogni opzione nel builder:

Modalità test

Per usare la modalità test (https://test.dodopayments.com), chiama testMode() sul builder:

Timeout e retry

Per impostazione predefinita, il client esegue due retry e va in timeout dopo 1 minuto. Ripete le richieste in caso di errori di connessione e di risposte con status 408, 409, 429 o 500 e superiori, usando un exponential backoff. Imposta i valori predefiniti sul client oppure passa RequestOptions a una singola chiamata:

Operazioni comuni

Gli esempi di questa sezione usano client da Quick Start.

Creare una Checkout Session

Crea una checkout session, quindi reindirizza il cliente all’URL di checkout restituito:
checkoutUrl() restituisce un String? nullable. Ogni URL di checkout funziona una sola volta e scade dopo 24 ore. Per tutte le opzioni della sessione, consulta Checkout Sessions.

Creare un prodotto

Crea un prodotto subscription mensile con prezzo di $29.99:
price è espresso nell’unità più piccola della valuta. discountBps imposta lo sconto in basis points e sostituisce il campo discount deprecato.

Attivare una license key

Attiva una license key per un dispositivo o un’installazione. Se la chiave ha raggiunto il limite di attivazioni, l’API restituisce 422 e l’SDK genera UnprocessableEntityException. Una chiave inattiva restituisce 403 (PermissionDeniedException), mentre una chiave sconosciuta restituisce 404 (NotFoundException):

Gestire le subscription

Crea una subscription, quindi addebitala se si tratta di una subscription on-demand.
POST /subscriptions (il metodo subscriptions().create() dell’SDK) è deprecato. Continua a funzionare per le integrazioni esistenti, ma per le nuove integrazioni devi creare le subscription tramite una Checkout Session.
billing richiede solo country, un codice paese ISO di due lettere. Usa AttachExistingCustomer per collegare un cliente esistente oppure NewCustomer per crearne uno. charge è destinato alle subscription on-demand, mentre productPrice è espresso nell’unità più piccola della valuta.

Fatturazione basata sull’utilizzo

Registrare eventi di utilizzo

Invia un evento di utilizzo per un cliente. I meter che monitorano eventName aggregano l’evento:
eventId è la chiave di idempotenza, quindi assegna a ogni evento un valore univoco. Una richiesta accetta fino a 1.000 eventi.

Operazioni asincrone

Client asincrono

Il client asincrono dispone degli stessi metodi del client sincrono, ma la maggior parte di essi è costituita da funzioni suspend. Chiamale da una coroutine:
Puoi anche chiamare client.async() su un client sincrono per ottenere la relativa versione asincrona.

Gestione degli errori

In caso di status di errore, l’SDK genera una sottoclasse di DodoPaymentsServiceException, che dispone di statusCode(), headers() e body(). Le sottoclassi sono BadRequestException (400), UnauthorizedException (401), PermissionDeniedException (403), NotFoundException (404), UnprocessableEntityException (422), RateLimitException (429), InternalServerException (5xx) e UnexpectedStatusCodeException per gli altri status, come 409:
I problemi di rete generano DodoPaymentsIoException, mentre le risposte che l’SDK non riesce a interpretare generano DodoPaymentsInvalidDataException. Tutte le eccezioni dell’SDK estendono DodoPaymentsException.

Gestione funzionale degli errori

Usa Result per la gestione funzionale degli errori:
runCatching intercetta ogni eccezione, incluse quelle dell’SDK, e le restituisce come un Result non riuscito.

Integrazione con Android

Il Kotlin SDK è un SDK server. Esegue l’autenticazione con la tua secret API key e chiunque disponga del tuo APK può estrarre una key compilata al suo interno, quindi non usarlo mai all’interno di un’app Android. Per accettare pagamenti in un’app Android:
  1. Sul tuo server, crea la checkout session con questo SDK (vedi Integrazione Ktor) e restituisci il relativo checkout_url.
  2. Nell’app, recupera quel checkout_url dal tuo server e aprilo con l’Android SDK, che non contiene alcuna API key.

Validazione della response

Per impostazione predefinita, l’SDK genera DodoPaymentsInvalidDataException solo quando leggi una property con un tipo imprevisto. Per verificare l’intera response in anticipo, abilita la validazione per una request oppure chiama validate() su una response:

Funzionalità avanzate

Configurazione del proxy

Per inviare le request tramite un proxy, passa un java.net.Proxy al builder:

Configurazione temporanea

withOptions restituisce un client con impostazioni modificate che condivide i connection pool e i thread pool del client originale. Il client originale non cambia:

Integrazione Ktor

Crea il client una volta e chiamalo da una route:

Risorse

GitHub Repository

Codice sorgente, release e elenco completo dei metodi.

API Reference

Ogni endpoint, parametro e response.

Discord Community

Fai domande e parla con altri sviluppatori.

Report Issues

Segnala bug o richiedi nuove funzionalità.

Supporto

Per assistenza con il Kotlin SDK:

Contribuire

Per contribuire, leggi le linee guida per i contributi.
Ultima modifica il 28 settembre 2026