# Novità dell'Accept SDK: settembre 2026

> Otto release in quattro settimane. Branding personalizzato sulle schermate di pagamento, checkout su doppio schermo, link alle ricevute fin dal primo evento, supporto per lettori di carte esterni e un flusso di pagamento che non attende più la posizione. Una panoramica delle novità dell'Accept SDK per Android, dalla 1.10 alla 1.15.

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

![Icona di una tavolozza](/images/posts/whats-new-in-the-accept-sdk-september-2026-branding.svg)

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

![Icona di un monitor e di un telefono](/images/posts/whats-new-in-the-accept-sdk-september-2026-dualscreen.svg)

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.

```kotlin
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

![Icona di un link](/images/posts/whats-new-in-the-accept-sdk-september-2026-receipt-link.svg)

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

![Icona di una carta](/images/posts/whats-new-in-the-accept-sdk-september-2026-external-reader.svg)

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.

```kotlin
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

![Icona di un segnaposto con una freccia verso l'icona di un fulmine](/images/posts/whats-new-in-the-accept-sdk-september-2026-location.svg)

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:

```kotlin
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](https://github.com/tapayadot/accept-android/blob/master/CHANGELOG.md) e le guide all'integrazione su [docs.tapaya.com](https://docs.tapaya.com). La documentazione può anche essere collegata a un IDE o a un agente AI tramite il [server MCP di Tapaya](https://docs.tapaya.com/mcp-server).

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.