---
title: "What's new in the Accept SDK: September 2026"
description: "Eight releases in four weeks. Custom branding on the payment screens, dual-screen checkout, receipt links from the first event, support for external card readers, and a payment path that no longer waits on location. An overview of what changed in the Accept SDK for Android, from 1.10 to 1.15."
url: "https://tapaya.com/en/blog/whats-new-in-the-accept-sdk-september-2026"
lang: "en"
last_updated: "2026-09-26"
---

# What's new in the Accept SDK: September 2026

> Eight releases in four weeks. Custom branding on the payment screens, dual-screen checkout, receipt links from the first event, support for external card readers, and a payment path that no longer waits on location. An overview of what changed in the Accept SDK for Android, from 1.10 to 1.15.

September was our busiest month for the Accept SDK so far. We shipped eight releases, from 1.10.0 on 3 September to 1.15.0 on 23 September. Most of the changes came straight from partners running the SDK in production: countertop terminals, dual-screen devices, stores with their own card readers, and platforms where the payment step should look like the rest of the product.

The idea behind all of it stays the same. A partner integrates once and the merchant experience stays in their product, while Tapaya handles the payments complexity underneath. Here is what that meant in practice this month.

## Custom branding on the payment screens

![Palette icon](/images/posts/whats-new-in-the-accept-sdk-september-2026-branding.svg)

**1.14.0** introduces `Accept.setTheme()`. The SDK now makes it possible to pass a partner's colors and logos to Tapaya Terminal, which shows them on the activation, status and payment screens. The merchant sees one product from the start of a sale to the receipt, with no handoff to a screen that looks like someone else's.

The theme lasts for the whole session. It is set once, before or after `initialize()`, and stays active until it is changed or cleared. For logos picked from the phone gallery rather than hosted somewhere, `Accept.createLocalThemeImageUri()` turns the local image into a URI the terminal app can read.

## Support for dual-screen checkout

![Monitor and phone icon](/images/posts/whats-new-in-the-accept-sdk-september-2026-dualscreen.svg)

**1.10.0** adds support for dual-screen ("double-sided") devices. `Accept.displays` reports which screens the device has, and the new `PaymentDisplay` option makes it possible to show the payment UI on the customer's screen while the partner's app stays on the merchant's.

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

If the device can't fulfil the request, for example `CustomerFacing` on a phone with one screen, the SDK falls back to the default screen. The same code therefore works on every supported device. The new `:dualscreen` sample app shows a full two-screen checkout.

## Receipt links from the first event

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

**1.12.0** makes the hosted receipt URL available straight from the payment flow. `PaymentEvent.Created` now includes `receiptUrl` next to the payment token, so the link is available before Tapaya Terminal even opens. `PayResult.Success` and `PayResult.Declined` include it too, so a finished payment carries everything needed and a separate `status()` call is no longer required to show a receipt.

The link works from the moment the payment is created and shows the final receipt once the payment settles. Both fields can be `null` and default to it, so existing integrations keep compiling unchanged.

## Support for external card readers

![Card icon](/images/posts/whats-new-in-the-accept-sdk-september-2026-external-reader.svg)

**1.11.0** adds `NfcPositionConfig.ExternalReader` for setups where the card reader is a separate device: a reader on the counter, a pinpad on the side, a dock facing the customer. There is no spot on the phone to point at, so Tapaya Terminal hides the tap animation and shows the amount with a short prompt below it. The default prompt can be replaced with a custom `message`.

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

This requires Tapaya Terminal 1.5.2 or newer. Older versions ignore the setting and keep working as before.

## Payments without waiting on location

![Location pin icon with an arrow to a lightning bolt icon](/images/posts/whats-new-in-the-accept-sdk-september-2026-location.svg)

Many partners run the SDK on countertop terminals, and some of those devices have a weak or non-Google location service. **1.14.1**, **1.14.2** and **1.15.0** fixed that for good.

- `pay()` no longer waits for a fresh location fix. It uses the last known location right away and refreshes it in the background when it is older than an hour. A terminal on a counter doesn't move between payments, so an hour-old location is as accurate as a new one.
- When the SDK does need a new fix, it now asks every available location source at once and uses the first answer. Before, a device whose main location service looked fine but never answered failed with `LocationUnavailable`, even when GPS and network location worked.
- On a cold start, the SDK first reuses the location Android already knows. Only a terminal that has never had a location waits for one, and never longer than 30 seconds.

For merchants this means faster payments and far fewer location errors in the middle of a sale.

## Further improvements

- **Clearer terminal activation errors (1.10.0, 1.14.0).** `activateTerminal()` now returns `NoTidsAvailableForMerchant` when a merchant has no free terminal ID left, instead of a generic `Unknown`. If the merchant hasn't finished onboarding, the call stops early with `MerchantOnboardingIncomplete`, which makes it possible to send them back to the right step.
- **No more UI freezes when connecting to the terminal app (1.14.0).** Calls to Tapaya Terminal now run off the main thread. Before, a slow first connection started from `viewModelScope.launch` could freeze the screen or cause an ANR.
- **More precise `PluginUnavailable` diagnostics (1.13.0).** The SDK now logs which case applies: Tapaya Terminal is not installed, it is disabled, it was removed for the current user, or the app's manifest is missing the `<queries>` entry Android 11+ needs. The log also includes the terminal app's version and where it was installed from. We also fixed a connection leak on failed binds, a `SecurityException` that reached app code instead of `PluginUnavailable`, and a full timeout wait when the terminal app's process died while connecting.

## Upgrading

Every release this month is backward compatible. Bumping the dependency is all it takes:

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

For deployments on terminals in the field, we especially recommend 1.15.0 because of the location fixes. The full changelog is in the [Accept SDK repository on GitHub](https://github.com/tapayadot/accept-android/blob/master/CHANGELOG.md), and the integration guides are at [docs.tapaya.com](https://docs.tapaya.com). The docs can also be connected to an IDE or AI agent through the [Tapaya MCP server](https://docs.tapaya.com/mcp-server).

Is something missing from the SDK that partners need? Let us know. Most of what shipped in September started as a conversation with a partner.

## Sitemap

- [Sitemap](https://tapaya.com/sitemap.md): every page on tapaya.com, as markdown links