# Quoi de neuf dans l'Accept SDK : septembre 2026

> Huit versions en quatre semaines. Votre propre image de marque sur les écrans de paiement, l'encaissement sur double écran, des liens vers les tickets dès le premier événement, la prise en charge des lecteurs de carte externes et un parcours de paiement qui n'attend plus la localisation. Tour d'horizon des nouveautés de l'Accept SDK pour Android, de la 1.10 à la 1.15.

Septembre a été jusqu'ici notre mois le plus chargé pour l'Accept SDK. Nous avons publié huit versions, de la 1.10.0 le 3 septembre à la 1.15.0 le 23 septembre. La plupart des changements viennent directement de partenaires qui utilisent le SDK en production : terminaux de comptoir, appareils à double écran, magasins équipés de leurs propres lecteurs de carte et plateformes où l'étape de paiement doit ressembler au reste du produit.

L'idée de fond reste la même. Un partenaire intègre une seule fois et l'expérience du commerçant reste dans son produit, tandis que Tapaya gère en coulisses la complexité des paiements. Voici ce que cela a signifié concrètement ce mois-ci.

## Votre image de marque sur les écrans de paiement

![Icône de palette](/images/posts/whats-new-in-the-accept-sdk-september-2026-branding.svg)

La **1.14.0** introduit `Accept.setTheme()`. Le SDK permet désormais de transmettre les couleurs et les logos d'un partenaire à Tapaya Terminal, qui les affiche sur les écrans d'activation, de statut et de paiement. Le commerçant voit un seul et même produit du début de la vente jusqu'au ticket, sans passer par un écran qui ressemble à celui de quelqu'un d'autre.

Le thème s'applique à toute la session. Il est défini une seule fois, avant ou après `initialize()`, et reste actif jusqu'à ce qu'il soit modifié ou effacé. Pour les logos choisis dans la galerie du téléphone plutôt qu'hébergés en ligne, `Accept.createLocalThemeImageUri()` convertit l'image locale en une URI que l'application terminal peut lire.

## Prise en charge de l'encaissement sur double écran

![Icône d'écran et de téléphone](/images/posts/whats-new-in-the-accept-sdk-september-2026-dualscreen.svg)

La **1.10.0** prend en charge les appareils à double écran (« double face »). `Accept.displays` indique les écrans dont dispose l'appareil, et la nouvelle option `PaymentDisplay` permet d'afficher l'interface de paiement sur l'écran du client pendant que l'application du partenaire reste sur celui du commerçant.

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

Si l'appareil ne peut pas satisfaire la demande, par exemple `CustomerFacing` sur un téléphone à un seul écran, le SDK se rabat sur l'écran par défaut. Le même code fonctionne donc sur tous les appareils pris en charge. La nouvelle application d'exemple `:dualscreen` présente un encaissement complet sur deux écrans.

## Des liens vers les tickets dès le premier événement

![Icône de lien](/images/posts/whats-new-in-the-accept-sdk-september-2026-receipt-link.svg)

La **1.12.0** rend l'URL du ticket hébergé disponible directement dans le parcours de paiement. `PaymentEvent.Created` inclut désormais `receiptUrl` à côté du jeton de paiement, si bien que le lien est disponible avant même l'ouverture de Tapaya Terminal. `PayResult.Success` et `PayResult.Declined` l'incluent aussi : un paiement terminé contient tout le nécessaire, et un appel séparé à `status()` n'est plus requis pour afficher un ticket.

Le lien fonctionne dès la création du paiement et affiche le ticket définitif une fois le paiement réglé. Les deux champs peuvent valoir `null`, qui est aussi leur valeur par défaut ; les intégrations existantes continuent donc de compiler sans modification.

## Prise en charge des lecteurs de carte externes

![Icône de carte](/images/posts/whats-new-in-the-accept-sdk-september-2026-external-reader.svg)

La **1.11.0** ajoute `NfcPositionConfig.ExternalReader` pour les configurations où le lecteur de carte est un appareil séparé : un lecteur sur le comptoir, un pinpad sur le côté, une station tournée vers le client. Il n'y a aucun emplacement du téléphone à désigner ; Tapaya Terminal masque donc l'animation de paiement sans contact et affiche le montant avec une courte invite en dessous. L'invite par défaut peut être remplacée par un `message` personnalisé.

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

Cette fonctionnalité nécessite Tapaya Terminal 1.5.2 ou une version ultérieure. Les versions plus anciennes ignorent ce réglage et continuent de fonctionner comme avant.

## Des paiements qui n'attendent plus la localisation

![Icône d'épingle de localisation avec une flèche vers une icône d'éclair](/images/posts/whats-new-in-the-accept-sdk-september-2026-location.svg)

De nombreux partenaires utilisent le SDK sur des terminaux de comptoir, et certains de ces appareils disposent d'un service de localisation peu fiable ou non fourni par Google. Les versions **1.14.1**, **1.14.2** et **1.15.0** ont réglé ce problème une fois pour toutes.

- `pay()` n'attend plus une nouvelle localisation. Il utilise immédiatement la dernière position connue et l'actualise en arrière-plan si elle date de plus d'une heure. Un terminal posé sur un comptoir ne bouge pas entre deux paiements : une position vieille d'une heure est donc aussi précise qu'une nouvelle.
- Lorsque le SDK a besoin d'une nouvelle localisation, il interroge désormais toutes les sources disponibles en même temps et utilise la première réponse. Auparavant, un appareil dont le service de localisation principal semblait fonctionner mais ne répondait jamais échouait avec `LocationUnavailable`, même lorsque le GPS et la localisation réseau fonctionnaient.
- Au démarrage à froid, le SDK réutilise d'abord la position déjà connue d'Android. Seul un terminal qui n'a encore jamais eu de position en attend une, et jamais plus de 30 secondes.

Pour les commerçants, cela signifie des paiements plus rapides et beaucoup moins d'erreurs de localisation en pleine vente.

## Autres améliorations

- **Des erreurs d'activation du terminal plus claires (1.10.0, 1.14.0).** `activateTerminal()` renvoie désormais `NoTidsAvailableForMerchant` lorsqu'un commerçant n'a plus d'identifiant de terminal disponible, au lieu d'un `Unknown` générique. Si le commerçant n'a pas terminé son onboarding, l'appel s'arrête tôt avec `MerchantOnboardingIncomplete`, ce qui permet de le renvoyer à la bonne étape.
- **Plus de blocage de l'interface lors de la connexion à l'application terminal (1.14.0).** Les appels à Tapaya Terminal s'exécutent désormais hors du thread principal. Auparavant, une première connexion lente lancée depuis `viewModelScope.launch` pouvait figer l'écran ou provoquer un ANR.
- **Un diagnostic `PluginUnavailable` plus précis (1.13.0).** Le SDK journalise désormais le cas concerné : Tapaya Terminal n'est pas installé, il est désactivé, il a été supprimé pour l'utilisateur actuel, ou il manque dans le manifeste de l'application l'entrée `<queries>` requise par Android 11+. Le journal indique aussi la version de l'application terminal et sa source d'installation. Nous avons également corrigé une fuite de connexion en cas d'échec de liaison, une `SecurityException` qui atteignait le code de l'application au lieu de `PluginUnavailable`, et une attente jusqu'au délai d'expiration complet lorsque le processus de l'application terminal s'arrêtait pendant la connexion.

## Mettre à jour

Toutes les versions de ce mois-ci sont rétrocompatibles. Il suffit de mettre à jour la dépendance :

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

Pour les déploiements sur des terminaux déjà en service, nous recommandons tout particulièrement la 1.15.0 en raison des correctifs de localisation. Le journal des modifications complet se trouve dans le [dépôt de l'Accept SDK sur GitHub](https://github.com/tapayadot/accept-android/blob/master/CHANGELOG.md), et les guides d'intégration sur [docs.tapaya.com](https://docs.tapaya.com). La documentation peut aussi être connectée à un IDE ou à un agent IA via le [serveur MCP de Tapaya](https://docs.tapaya.com/mcp-server).

Il manque au SDK quelque chose dont les partenaires ont besoin ? Faites-le-nous savoir. La plupart des nouveautés de septembre sont nées d'une conversation avec un partenaire.