What's new in the Accept SDK: September 2026

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

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

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.

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

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

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.

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

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:

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, and the integration guides are at docs.tapaya.com. The docs can also be connected to an IDE or AI agent through the Tapaya 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.