Що нового в Accept SDK: вересень 2026

Вересень став нашим найнасиченішим місяцем в історії Accept SDK. Ми випустили вісім релізів: від 1.10.0 3 вересня до 1.15.0 23 вересня. Більшість змін прийшла безпосередньо з досвіду партнерів, які використовують SDK у продакшні: настільні термінали, пристрої з двома дисплеями, магазини з власними зчитувачами карток і платформи, де оплата має виглядати так само, як решта продукту.

Ідея за всім цим незмінна. Партнер інтегрується один раз, і досвід мерчанта залишається в його продукті, а всю складність платежів під капотом бере на себе Tapaya. Ось що це означало на практиці цього місяця.

Власний брендинг платіжних екранів

Версія 1.14.0 додає Accept.setTheme(). Відтепер SDK дає змогу передати в Tapaya Terminal кольори й логотипи партнера, і вони з'являються на екранах активації, статусу та оплати. Мерчант бачить один продукт від початку продажу до чека, без переходу на екран, що виглядає як чужий застосунок.

Тема діє протягом усієї сесії. Вона задається один раз, до або після initialize(), і залишається активною, доки її не змінять або не скинуть. Для логотипів, вибраних із галереї телефона, які ніде не розміщені онлайн, доступний Accept.createLocalThemeImageUri(): він перетворює локальне зображення на URI, яке термінальний застосунок може прочитати.

Підтримка оплати на двох дисплеях

Версія 1.10.0 додає підтримку пристроїв із двома дисплеями («двосторонніх»). Accept.displays повідомляє, які екрани є на пристрої, а нова опція PaymentDisplay дає змогу показати платіжний інтерфейс на екрані клієнта, поки застосунок партнера залишається на екрані мерчанта.

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

Якщо пристрій не може виконати запит, наприклад CustomerFacing на телефоні з одним екраном, SDK використовує екран за замовчуванням. Тож один і той самий код працює на всіх підтримуваних пристроях. Новий демо-застосунок :dualscreen показує повну оплату на двох екранах.

Посилання на чек уже з першої події

Версія 1.12.0 робить URL розміщеного чека доступним прямо в платіжному потоці. PaymentEvent.Created тепер містить receiptUrl поруч із платіжним токеном, тож посилання доступне ще до того, як відкриється Tapaya Terminal. PayResult.Success і PayResult.Declined теж його містять, тому завершений платіж має все потрібне, і окремий виклик status() для показу чека більше не потрібен.

Посилання працює з моменту створення платежу, а після розрахунку показує фінальний чек. Обидва поля можуть бути null і мають це значення за замовчуванням, тож наявні інтеграції й далі компілюються без змін.

Підтримка зовнішніх зчитувачів карток

Версія 1.11.0 додає NfcPositionConfig.ExternalReader для випадків, коли зчитувач карток є окремим пристроєм: зчитувач на прилавку, пінпад збоку чи док, повернутий до клієнта. На телефоні немає точки, на яку можна вказати, тож Tapaya Terminal ховає анімацію прикладання й показує суму з короткою підказкою під нею. Стандартний текст підказки можна замінити власним через message.

Accept.payments.setOptions(
    nfcPosition = NfcPositionConfig.ExternalReader(message = "Прикладіть картку до зчитувача"),
)

Для цього потрібен Tapaya Terminal 1.5.2 або новіший. Старіші версії ігнорують це налаштування й працюють як раніше.

Платежі без очікування на геолокацію

Багато партнерів використовують SDK на настільних терміналах, і деякі з цих пристроїв мають слабку або не-Google службу геолокації. Версії 1.14.1, 1.14.2 і 1.15.0 остаточно це виправили.

• pay() більше не чекає на свіжу геолокацію. Він одразу використовує останнє відоме місцезнаходження й оновлює його у фоні, коли воно старше за годину. Термінал на прилавку не рухається між платежами, тож геолокація годинної давності така ж точна, як нова.
• Коли SDK все ж потрібна нова геолокація, він опитує всі доступні джерела одночасно й бере першу відповідь. Раніше пристрій, основна служба геолокації якого виглядала справною, але так і не відповідала, завершувався помилкою LocationUnavailable, навіть коли GPS і мережева геолокація працювали.
• Під час холодного старту SDK спершу використовує місцезнаходження, яке Android уже знає. На геолокацію чекає лише термінал, який її ніколи не мав, і не довше ніж 30 секунд.

Для мерчантів це означає швидші платежі й значно менше помилок геолокації посеред продажу.

Інші покращення

• Зрозуміліші помилки активації термінала (1.10.0, 1.14.0). activateTerminal() тепер повертає NoTidsAvailableForMerchant, коли в мерчанта не залишилося вільного ID термінала, замість загального Unknown. Якщо мерчант не завершив онбординг, виклик одразу завершується з MerchantOnboardingIncomplete, що дає змогу повернути його на потрібний крок.
• Жодних зависань UI під час підключення до термінального застосунку (1.14.0). Виклики до Tapaya Terminal тепер виконуються поза головним потоком. Раніше повільне перше підключення, запущене з viewModelScope.launch, могло заморозити екран або спричинити ANR.
• Точніша діагностика PluginUnavailable (1.13.0). SDK тепер логує, який саме це випадок: Tapaya Terminal не встановлено, його вимкнено, його видалено для поточного користувача або в маніфесті застосунку бракує запису <queries>, якого вимагає Android 11+. Лог також містить версію термінального застосунку та джерело, з якого його встановлено. Ми також виправили витік з'єднання при невдалому підключенні, SecurityException, що потрапляв у код застосунку замість PluginUnavailable, і очікування повного тайм-ауту, коли процес термінального застосунку падав під час підключення.

Оновлення

Усі вересневі релізи зворотно сумісні. Достатньо підняти версію залежності:

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

Для розгортань на терміналах у полі через виправлення геолокації особливо рекомендуємо версію 1.15.0. Повний changelog є в репозиторії Accept SDK на GitHub, а інструкції з інтеграції на docs.tapaya.com. Документацію також можна під'єднати до IDE або AI-агента через Tapaya MCP server.

Бракує в SDK чогось, що потрібно партнерам? Напишіть нам. Більшість того, що ми випустили у вересні, почалася з розмови з партнером.