Novità dell'Accept SDK: settembre 2026

Settembre è stato finora il nostro mese più intenso per l'Accept SDK. Abbiamo pubblicato otto release, dalla 1.10.0 del 3 settembre alla 1.15.0 del 23 settembre. La maggior parte delle modifiche è nata direttamente dai partner che utilizzano l'SDK in produzione: terminali da banco, dispositivi a doppio schermo, negozi con i propri lettori di carte e piattaforme in cui il passaggio di pagamento deve avere lo stesso aspetto del resto del prodotto.

L'idea di fondo resta la stessa. Un partner integra una sola volta e l'esperienza dell'esercente rimane nel suo prodotto, mentre Tapaya gestisce dietro le quinte la complessità dei pagamenti. Ecco cosa ha significato in pratica questo mese.

Branding personalizzato sulle schermate di pagamento

La 1.14.0 introduce Accept.setTheme(). L'SDK consente ora di passare i colori e i loghi di un partner a Tapaya Terminal, che li mostra sulle schermate di attivazione, di stato e di pagamento. L'esercente vede un unico prodotto dall'inizio della vendita fino alla ricevuta, senza passaggi a una schermata che sembra appartenere a qualcun altro.

Il tema dura per l'intera sessione. Si imposta una sola volta, prima o dopo initialize(), e resta attivo finché non viene modificato o rimosso. Per i loghi scelti dalla galleria del telefono anziché ospitati online, Accept.createLocalThemeImageUri() trasforma l'immagine locale in un URI leggibile dall'app del terminale.

Supporto per il checkout su doppio schermo

La 1.10.0 aggiunge il supporto per i dispositivi a doppio schermo ("double-sided"). Accept.displays indica quali schermi ha il dispositivo e la nuova opzione PaymentDisplay consente di mostrare l'interfaccia di pagamento sullo schermo del cliente mentre l'app del partner resta su quello dell'esercente.

Accept.payments.pay(
    amount = 1500,
    currency = "CZK",
    display = PaymentDisplay.CustomerFacing,
)

Se il dispositivo non può soddisfare la richiesta, ad esempio CustomerFacing su un telefono con un solo schermo, l'SDK ripiega sullo schermo predefinito. Lo stesso codice funziona quindi su tutti i dispositivi supportati. La nuova app di esempio :dualscreen mostra un checkout completo su due schermi.

Link alle ricevute fin dal primo evento

La 1.12.0 rende disponibile l'URL della ricevuta ospitata direttamente dal flusso di pagamento. PaymentEvent.Created include ora receiptUrl accanto al token di pagamento, quindi il link è disponibile ancora prima che Tapaya Terminal si apra. Anche PayResult.Success e PayResult.Declined lo includono, così un pagamento concluso contiene tutto il necessario e non serve più una chiamata separata a status() per mostrare una ricevuta.

Il link funziona dal momento in cui il pagamento viene creato e mostra la ricevuta definitiva una volta regolato il pagamento. Entrambi i campi possono essere null e hanno questo valore predefinito, quindi le integrazioni esistenti continuano a compilare senza modifiche.

Supporto per lettori di carte esterni

La 1.11.0 aggiunge NfcPositionConfig.ExternalReader per le configurazioni in cui il lettore di carte è un dispositivo separato: un lettore sul bancone, un pinpad laterale, una base rivolta verso il cliente. Non c'è un punto del telefono da indicare, quindi Tapaya Terminal nasconde l'animazione del tap e mostra l'importo con un breve messaggio sotto. Il messaggio predefinito può essere sostituito con un message personalizzato.

Accept.payments.setOptions(
    nfcPosition = NfcPositionConfig.ExternalReader(message = "Tap your card on the reader"),
)

Richiede Tapaya Terminal 1.5.2 o versioni successive. Le versioni precedenti ignorano l'impostazione e continuano a funzionare come prima.

Pagamenti senza attendere la posizione

Molti partner utilizzano l'SDK su terminali da banco e alcuni di questi dispositivi hanno un servizio di localizzazione debole o non Google. La 1.14.1, la 1.14.2 e la 1.15.0 hanno risolto il problema in modo definitivo.

• pay() non attende più un nuovo rilevamento della posizione. Utilizza subito l'ultima posizione nota e la aggiorna in background se è più vecchia di un'ora. Un terminale su un bancone non si sposta tra un pagamento e l'altro, quindi una posizione di un'ora fa è precisa quanto una nuova.
• Quando l'SDK ha davvero bisogno di un nuovo rilevamento, ora interroga contemporaneamente tutte le fonti di localizzazione disponibili e utilizza la prima risposta. Prima, un dispositivo il cui servizio di localizzazione principale sembrava funzionare ma non rispondeva mai falliva con LocationUnavailable, anche quando GPS e localizzazione di rete funzionavano.
• All'avvio a freddo, l'SDK riutilizza prima la posizione già nota ad Android. Solo un terminale che non ha mai avuto una posizione la attende, e mai per più di 30 secondi.

Per gli esercenti questo significa pagamenti più rapidi e molti meno errori di localizzazione nel bel mezzo di una vendita.

Ulteriori miglioramenti

• Errori di attivazione del terminale più chiari (1.10.0, 1.14.0). activateTerminal() restituisce ora NoTidsAvailableForMerchant quando un esercente non ha più ID terminale liberi, invece di un generico Unknown. Se l'esercente non ha completato l'onboarding, la chiamata si interrompe subito con MerchantOnboardingIncomplete, così è possibile rimandarlo al passaggio corretto.
• Niente più blocchi dell'interfaccia durante la connessione all'app del terminale (1.14.0). Le chiamate a Tapaya Terminal vengono ora eseguite fuori dal thread principale. Prima, una prima connessione lenta avviata da viewModelScope.launch poteva bloccare lo schermo o causare un ANR.
• Diagnostica di PluginUnavailable più precisa (1.13.0). L'SDK ora registra nel log quale caso si applica: Tapaya Terminal non è installato, è disattivato, è stato rimosso per l'utente corrente oppure nel manifest dell'app manca la voce <queries> richiesta da Android 11+. Il log include anche la versione dell'app del terminale e la fonte da cui è stata installata. Abbiamo inoltre corretto una perdita di connessione in caso di bind non riusciti, una SecurityException che raggiungeva il codice dell'app invece di PluginUnavailable e un'attesa fino al timeout completo quando il processo dell'app del terminale terminava durante la connessione.

Aggiornamento

Tutte le release di questo mese sono retrocompatibili. Basta aggiornare la dipendenza:

dependencies {
    implementation("com.tapaya:accept:1.15.0")
}

Per le installazioni su terminali già in uso sul campo, consigliamo in particolare la 1.15.0 per via delle correzioni sulla localizzazione. Il changelog completo si trova nel repository dell'Accept SDK su GitHub e le guide all'integrazione su docs.tapaya.com. La documentazione può anche essere collegata a un IDE o a un agente AI tramite il server MCP di Tapaya.

Manca qualcosa nell'SDK di cui i partner hanno bisogno? Ce lo faccia sapere. Gran parte di ciò che abbiamo rilasciato a settembre è nato da una conversazione con un partner.