Для SCT Inst десятисекундний строк починається з time of receipt, який за загальним правилом збігається з авторизацією платника. Усередині схеми діють контрольні 5–7–9-second sub-timelines. Якщо до десятої секунди Originator PSP не має confirmation, він має відновити рахунок і повідомити клієнта, але пізня позитивна відповідь усе ще потребує окремої обробки.
Користувач натискає «Підтвердити» о 12:00:00, бачить spinner 12 секунд і повторює платіж. За цей час перша instruction могла успішно пройти, а app не встиг показати confirmation. Правило потрібне не для рекламного stopwatch, а для узгодженої поведінки PSP при positive, negative та timeout outcomes.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | власник рахунку або компанія, що ініціює платіж у євро |
| Кому | фізична чи юридична особа з рахунком у зоні доступності схеми |
| Мета | перевірка схеми SEPA, швидкості, VOP і правил конкретного PSP |
| Валюта / інструмент | SCT, SCT Inst, VOP або миттєвий переказ СЕП України залежно від теми |
| Що змінює висновок | країна PSP, участь у схемі, валюта рахунку, effective date і доступність у провайдера |
Що потрібно знати до платежу
Timer стартує з receipt of order
2025 SCT Inst rulebook пов’язує початок maximum execution timeline з отриманням instant instruction; за загальним правилом цей момент дорівнює authorization Originator. (EPC — SCT Inst Rulebook)
Внутрішні checkpoints стали 5–7–9 seconds
Після IPR попередню схему 10–20–25 seconds замінено sub-timelines 5–7–9, щоб весь flow умістився в hard maximum десять секунд. (EPC — SCT Inst Rulebook)
Timestamp має містити milliseconds
Rulebook вимагає однозначний AT-T056 Timestamp of the SCT Inst Transaction із milliseconds, оскільки від нього залежить timeout decision. (EPC — SCT Inst Rulebook)
No confirmation веде до account restoration
Коли Originator PSP не отримав confirmation за десять секунд, він негайно відновлює рахунок і інформує платника; subsequent positive або negative message також має бути повідомлене клієнту. (EPC — SCT Inst Rulebook)
Як порівняти варіанти
| Варіант | Коли розглядати | Що перевірити до дії |
|---|---|---|
| Positive outcome | Confirmation отримано вчасно | Execution timestamp, beneficiary credit і повідомлення платнику |
| Negative outcome | Scheme повернула reject | Reason code, restoration of funds і безпечний repair |
| Timeout або late response | На десятій секунді confirmation ще немає | Account restoration, pending investigation і заборона автоматичного дубля |
Покрокова підготовка
- Зафіксуйте момент авторизації. Збережіть timestamp із milliseconds та timezone, щоб support порівнював ті самі десять секунд, що й payment engine.
- Розділіть UI і scheme status. Spinner або HTTP timeout не називайте failed payment, доки backend не покаже final scheme response.
- Перевірте balance restoration. Після no-confirmation case звірте доступний баланс і бухгалтерський entry, але залиште transaction у monitoring.
- Обробіть late positive. Якщо success приходить після restoration, негайно повідомте платника та застосуйте погоджену процедуру account correction.
- Блокуйте необдуманий повтор. До resolution за original reference не дозволяйте користувачу відправляти ту саму суму одним натисканням без warning.
Які дані та документи зібрати
- AT-T056 timestamp і timezone для instruction
- positive, negative або timeout scheme response
- account debit та restoration ledger entries
- UETR або end-to-end reference для investigation
- incident log для late confirmation і customer notification
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Інтернет-магазин повертав клієнту 620 EUR через SCT Inst. API не отримав response за десять секунд, баланс відправника відновився, а оператор уже готував повтор. Monitoring за original reference через чотири секунди зафіксував late positive. Система заблокувала дубль, повідомила finance про фактичне виконання й зберегла обидва timestamps для розбору з PSP.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- рахувати десять секунд від відкриття checkout, а не receipt/authorization
- вважати HTTP timeout тотожним negative scheme response
- ігнорувати milliseconds і timezone в incident evidence
- сприймати restoration balance як доказ, що late credit неможливий
- дозволяти автоматичний retry з новим reference без idempotency control
Де проходить межа поради
Технічні sub-timelines і recovery behavior потрібно реалізувати за чинним SCT Inst rulebook та PSP contract. Клієнтський UI може виглядати інакше, але не повинен приховувати невизначений outcome.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay не обіцяє десятисекундний результат для кожного euro route; коли використовується instant rail, status підтверджується за даними конкретного PSP. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.