Банківський термінал друкує «АНУЛЬОВАНО» або «ВІДХИЛЕНО», а продаж у Торгсофт закривається: як перевірити результат оплати

Під час інтегрованої карткової оплати Торгсофт передає суму покупки на банківський POS-термінал, отримує відповідь банку та після успішної операції фіксує безготівкову оплату. Підприємці звертаються до фахівців, коли термінал друкує «АНУЛЬОВАНО», «ВІДХИЛЕНО» або інший негативний статус, а реалізація в Торгсофт уже закрилася; коли покупцеві прийшло повідомлення про списання, але програма не отримала результат; коли в Торгсофт з’являється повідомлення «Не отримано RRN»; або коли незрозуміло, чи можна запускати оплату повторно. У таких випадках потрібно окремо перевірити банківську транзакцію, оплату в Торгсофт і фіскальний чек ПРРО. Повторний платіж запускають тільки після того, як встановлено результат першої операції.

Як проходить карткова оплата через Торгсофт

Якщо використовується опція «Інтеграція з банківським терміналом», звичайний продаж проходить так:

1. Касир формує реалізацію в Торгсофт.

2. Вибирає безготівкову оплату.

3. Торгсофт передає суму на POS-термінал.

4. Покупець прикладає картку або телефон і підтверджує операцію.

5. Термінал звертається до банку.

6. Банк повертає результат.

7. POS-термінал передає результат у Торгсофт.

8. Після успішної авторизації Торгсофт фіксує оплату на відповідному розрахунковому рахунку.

9. За підключеного ПРРО дані карткової операції можуть потрапити до фіскального чека. 

У нормальному сценарії всі три контури повинні відповідати один одному:

Проблема виникає, коли один із цих етапів завершився інакше.

Що означають «АНУЛЬОВАНО» і «ВІДХИЛЕНО»

Напис на банківському сліп-чеку показує результат, який сформував платіжний термінал.

«ВІДХИЛЕНО» зазвичай означає, що банк або платіжна система не підтвердили операцію.

«АНУЛЬОВАНО» може з’являтися після скасування операції або коли термінал не зміг завершити весь технічний обмін із касовою системою.

Для Торгсофт окремо описаний сценарій, коли при роботі через RDP через нестабільний канал термінал може друкувати «АНУЛЬОВАНО». Для таких підключень у довідці рекомендовано використовувати BPOS1 з очікуванням підтвердження від каси та, за можливості, підключення термінала через Ethernet. 

Сам напис на сліп-чеку потрібно враховувати, але при суперечливих ознаках варто перевірити операцію в журналі термінала або банківському сервісі.

Чому повідомлення про списання на телефоні покупця недостатньо

Покупець може показати push-повідомлення або SMS про списання суми. Це корисна інформація, але вона не повинна бути єдиною підставою для рішення касира.

Карткова операція проходить кілька етапів. У банківському застосунку покупця може відобразитися авторизація або резервування суми ще до остаточного завершення обміну між банком, терміналом і касовою програмою.

Тому при суперечності:

• телефон показує списання;

• POS друкує «АНУЛЬОВАНО»;

• Торгсофт показує тайм-аут,

потрібно встановити остаточний статус самої транзакції. Не слід одразу проводити картку повторно.

Що таке RRN і навіщо він потрібен

RRN — ідентифікатор банківської транзакції, який платіжний сервіс може повернути разом із результатом операції.

У документації monobank, наприклад, у відповіді успішної термінальної операції окремо передаються:

• status;

• responseCode;

• approvalCode;

• rrn;

• ідентифікатори транзакції;

• маска картки;

• дата та час.

Це добре показує принцип: RRN — один із реквізитів транзакції, а результат операції визначається сукупністю отриманих даних, зокрема статусом.

Тому неправильне правило: «Є RRN — гроші точно отримано».

RRN допомагає знайти ідентифіковану операцію, провести повернення та звірити дані з банком. Для остаточної перевірки потрібно дивитися статус операції та дані еквайра.

Код авторизації, RRN і код відповіді — це різні дані

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

Точні коди залежать від:

• банку;

• моделі термінала;

• протоколу;

• платіжного сервісу.

Тому касиру не потрібно запам’ятовувати таблицю числових кодів. Якщо на терміналі з’явився незрозумілий код, його потрібно перевіряти за документацією конкретного банку або через його технічну підтримку.

Найважливіше правило для касира: не повторювати платіж до перевірки

При нестандартному завершенні операції касир повинен зупинитися на поточному продажі.

Не потрібно:

• ще раз натискати «Оплатити»;

• просити покупця прикласти картку повторно;

• створювати другу реалізацію;

• вручну змінювати тип оплати;

• відпускати товар тільки за повідомленням банківського застосунку покупця.

Спочатку потрібно встановити стан першої транзакції.

Інакше можливий сценарій:

1. перша карткова операція фактично успішна;

2. Торгсофт не отримав відповідь через втрату зв’язку;

3. касир запускає другу оплату;

4. банк проводить обидві транзакції.

Саме другого списання потрібно уникнути.

Покроковий алгоритм, якщо POS показує «АНУЛЬОВАНО» або «ВІДХИЛЕНО»

Не викидайте документ термінала.

Зафіксуйте:

• суму;

• дату;

• час;

• Merchant ID, якщо він надрукований;

• ідентифікатор термінала;

• RRN;

• код авторизації;

• код або текст результату операції.

Для різних банків склад реквізитів може відрізнятися.

Подивіться, чи зник поточний продаж із форми реалізації та чи створена фінансова оплата. Якщо Торгсофт залишив продаж неоплаченим, це один сценарій. Якщо реалізація вже закрита як безготівкова, ситуація інша.

Якщо використовується Програмний РРО, відкрийте: Налаштування → Програмний РРО → Аналітика за програмним РРО.

Перевірте:

• чи сформувався чек;

• дату та час;

• суму;

• форму оплати;

• дані банківської транзакції.

За чинними вимогами ДПС при картковій оплаті через термінал, з’єднаний або поєднаний із РРО/ПРРО, у фіскальному чеку передбачені реквізити еквайра, термінала, платіжного засобу та код, що ідентифікує операцію в платіжній системі. 

Якщо результат залишається незрозумілим, потрібно перевірити транзакцію на боці банку.

Залежно від моделі термінала та банку це можна зробити:

• через журнал операцій POS;

• через функцію перевірки останньої операції;

• у кабінеті еквайрингу;

• через службу підтримки банку.

Передайте банку:

• суму;

• час;

• Merchant ID;

• Terminal ID;

• RRN;

• код авторизації, якщо він є.

Після цього можна встановити, чи операція завершилася успішно, була відхилена або була скасована.

Це найпростіший випадок.

Наприклад:

• POS надрукував «ВІДХИЛЕНО»;

• Торгсофт не закрив реалізацію;

• ПРРО-чек не сформувався;

• банк підтверджує, що покупки немає.

Після цього можна повторно запропонувати покупцеві оплатити товар:

• тією самою карткою;

• іншою карткою;

• іншим способом.

Нова операція буде окремою банківською транзакцією.

Це саме той випадок, через який власник магазину потім бачить розбіжність:

• Торгсофт показує безготівковий продаж;

• товар списано;

• банк грошей не отримав.

У версії Торгсофт 2026.0.5 виправлено окремий сценарій, за якого при неуспішній оплаті через термінал оплата все одно могла прив’язуватися до рахунку в «Торгівлі з випискою рахунка». Також додано контроль тайм-ауту для JSON WebSocket. 

Якщо така ситуація вже сталася, потрібно перевірити два документи:

1. оплату в Торгсофт;

2. фіскальний чек ПРРО.

Якщо фіскального чека немає

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

Конкретна дія залежить від режиму продажу та документа, тому при вже закритій реалізації краще не видаляти пов’язані фінансові записи навмання.

Якщо фіскальний чек уже зареєстрований

Потрібно також виправити фіскальну операцію. Не можна просто видалити фінансовий документ Торгсофт і залишити фіскальний чек як успішну карткову оплату.

Спочатку перевіряють стан зміни та конкретний чек, після чого використовують передбачений сценарій скасування або повернення.

Це зворотна ситуація.

Наприклад:

• покупець приклав картку;

• банк підтвердив операцію;

• термінал має успішну транзакцію;

• Торгсофт отримав тайм-аут;

• реалізація залишилася неоплаченою.

Повторно проводити POS-операцію не потрібно.

У Торгсофт передбачений сценарій ручного внесення параметрів вже виконаної банківської транзакції.

Якщо банківський термінал тимчасово не використовується через інтегроване підключення, на формі оплати можна вимкнути «Використовувати зв’язок із банківським терміналом». Тоді Торгсофт відкриває форму «Параметри оплати банківським терміналом», куди вносять дані зі сліп-чека.

Це дозволяє:

• не відправляти другу команду покупки на POS;

• провести існуючу оплату в Торгсофт;

• передати реквізити карткової транзакції у ПРРО, якщо відповідні налаштування активні.

Перед таким проведенням потрібно переконатися, що банк справді підтвердив першу операцію.

Це суперечливий результат. У такому випадку касир не повинен самостійно вирішувати, що головніше: паперовий сліп або повідомлення покупця. Потрібно перевірити операцію в еквайра за її реквізитами.

Якщо банк підтверджує, що операція успішна і не була скасована, далі дійте як при вже проведеній банківській оплаті: не запускайте другу транзакцію, а правильно завершіть продаж у Торгсофт.

Якщо банк підтверджує, що операція скасована або відхилена, карткової оплати в обліку залишатися не повинно.

Чи означає наявність RRN, що оплату можна вважати успішною

Ні. RRN дуже важливий для пошуку операції, але сам по собі не замінює її статус.

Наприклад, у сучасних API банків окремо повертаються:

• status;

• RRN;

• код авторизації;

• код відповіді.

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

Чому Торгсофт може повідомити «Не отримано RRN»

Причина залежить від термінала та банківської бібліотеки.

На офіційній сторінці Торгсофт зазначено, що для деяких Verifone, зокрема X990, бібліотека банку може не передавати RRN автоматично. Під час повернення в такому випадку може використовуватися код авторизації з чека. 

Тому повідомлення про відсутність RRN не завжди означає, що покупка в банку не відбулася. Потрібно перевірити банківський статус.

Чому важливо зберігати дані термінала

Торгсофт використовує реквізити початкової карткової операції і для подальших операцій.

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

У версії 2026.0.5 окремо виправлено передавання RRN, PAN та інших параметрів термінала у фінансовий документ при оплаті замовлення. 

Чому такі ситуації виникають при роботі через RDP

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

Якщо POS підключений локально через COM/USB, а дані передаються до віддаленого сеансу через RDP, у схемі з’являється додатковий канал зв’язку.

Довідка Торгсофт прямо зазначає, що при нестабільному RDP можливі:

• «Помилка №3»;

• проблеми підключення;

• друк чека «АНУЛЬОВАНО».

Для BPOS офіційна документація Торгсофт рекомендує:

• BPOS1 з очікуванням підтвердження від каси;

• Ethernet-підключення термінала. 

Це зменшує залежність платіжного обміну від перенаправлення COM/USB через віддалений сеанс.

Навіщо терміналу підтвердження від каси

Деякі протоколи передбачають завершальний обмін між POS і касовою програмою.

У налаштуваннях BPOS Торгсофт є:

• «Використовувати підтвердження каси»;

• «Ігнорувати підтвердження каси».

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

Ці параметри не потрібно змінювати касиру під час роботи. Налаштування повинне відповідати протоколу термінала та конфігурації банку.

Тайм-аут: чому Торгсофт може перестати чекати відповідь

Банківська транзакція займає певний час:

• покупець прикладає картку;

• вводить PIN;

• банк обробляє запит;

• термінал отримує відповідь;

• дані повертаються в Торгсофт.

Якщо зв’язок втрачається на останньому етапі, банк і Торгсофт можуть мати різне уявлення про стан операції.

У версії 2026.0.5 для JSON WebSocket додано контроль тайм-ауту очікування відповіді та можливість налаштовувати його значення. Також створюється окремий журнал роботи термінала, який можна використовувати під час діагностики. 

Тому при повторюваних тайм-аутах варто перевірити:

• версію Торгсофт;

• протокол POS;

• мережу;

• тайм-аут;

• журнали термінала;

• налаштування банківського обладнання.

Що робити, якщо касир випадково скасував очікування

Якщо програма ще чекала відповідь POS, а касир перервав процес, результат банківської операції може залишитися невизначеним для Торгсофт.

Правило те саме: не запускайте нову оплату, доки не перевірена попередня.

Спочатку:

1. подивіться сліп;

2. перевірте журнал POS;

3. знайдіть операцію у банку;

4. перевірте реалізацію в Торгсофт;

5. перевірте ПРРО.

Лише після цього визначайте наступну дію.

Як перевірити фіскальний чек після карткової оплати

За чинним Положенням про форму розрахункових документів, коли використовується картковий POS, з’єднаний або поєднаний із РРО/ПРРО, фіскальний чек містить блок платіжних реквізитів.

Серед них передбачені:

• ідентифікатор еквайра та торговця;

• ідентифікатор платіжного пристрою;

• вид операції;

• реквізити електронного платіжного засобу;

• платіжна система;

• код авторизації або інший ідентифікатор операції;

• форма оплати. 

Тому після суперечливої POS-операції фіскальний чек є ще одним джерелом для звірки, але він показує те, що було передано до ПРРО. Остаточний банківський стан потрібно перевіряти в еквайра.

Сліп-чек POS і фіскальний чек ПРРО виконують різні функції

Сліп POS описує платіжну транзакцію. Фіскальний чек описує розрахункову операцію продажу. Тому ситуація, коли один документ є, а іншого немає, цілком можлива при технічному збої.

Саме через це під час діагностики потрібно перевіряти обидва.

Якщо Торгсофт уже створив неправильну оплату

Не потрібно компенсувати її:

• касовим ордером;

• службовим внесенням;

• службовим вилученням;

• другою картковою транзакцією.

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

Якщо операція вже фіскалізована, окремо перевіряється ПРРО.

Якщо один термінал працює з кількома ФОП

При суперечливому результаті потрібно додатково перевірити Merchant ID.

У Торгсофт зв’язок повинен відповідати схемі: Merchant ID → розрахунковий рахунок → ФОП. Неправильний мерчант може призвести до того, що оплата піде іншому підприємцю або повернення не знайде початкової транзакції. 

Після тестової оплати доцільно перевірити Merchant ID у термінальному чеку та банківську виписку.

Як налаштувати роботу касирів

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

Внутрішня інструкція може містити такі дії:

1. Не натискати «Оплатити» вдруге.

2. Зберегти сліп POS.

3. Перевірити статус реалізації в Торгсофт.

4. Перевірити ПРРО.

5. Перевірити банківську транзакцію.

6. Якщо банк підтверджує успіх — завершити облік уже проведеної оплати без нового запиту на POS.

7. Якщо банк підтверджує відмову — повторити оплату як нову операцію.

8. Якщо Торгсофт і банк містять різні результати — передати дані адміністратору або технічній підтримці.

Що перевірити власнику при повторюваних випадках

Якщо ситуація виникає регулярно, проблема вже не стосується одного продажу.

Перевірте:

• актуальну версію Торгсофт;

• модель POS;

• банк;

• протокол підключення;

• COM/USB, Ethernet або Wi-Fi;

• використання RDP;

• налаштування підтвердження каси;

• тайм-аут;

• Merchant ID;

• розрахунковий рахунок;

• ФОП;

• журнал роботи термінала.

Для JSON WebSocket у Торгсофт 2026.0.5 додано окремий контроль тайм-ауту, а для неуспішних оплат виправлено окремі сценарії прив’язування фінансових документів. 

Короткий алгоритм: чи можна повторювати карткову оплату

Головне правило роботи з такими випадками: результат карткової оплати визначають за статусом банківської транзакції, а RRN, код авторизації, сліп-чек, фінансовий документ Торгсофт і чек ПРРО використовують для її ідентифікації та звірки. Якщо результати різняться, касир спочатку з’ясовує стан першої операції й лише після цього повторює оплату або коригує документи.