SCT ініціює платник: він щоразу або за standing order доручає своєму PSP переказати euro одержувачу. SDD ініціює creditor на підставі mandate, який дав payer, і тому має окремі collection, prenotification, reject, return та refund rules. Для subscription важлива не лише регулярність, а хто контролює дату й суму та як клієнт відкликає повноваження.
SaaS-компанія хоче автоматично списувати щомісячну плату. Standing order клієнта дає передбачуваний SCT, але продавець не може сам змінити суму. SDD дозволяє creditor подавати collection після mandate, однак вимагає mandate management і обробки refunds. Одне слово «автоплатіж» приховує різний контроль та liability.
Інформацію та офіційні джерела перевірено 2026-08-02. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | власник рахунку або компанія, що ініціює платіж у євро |
| Кому | фізична чи юридична особа з рахунком у зоні доступності схеми |
| Мета | перевірка схеми SEPA, швидкості, VOP і правил конкретного PSP |
| Валюта / інструмент | SCT, SCT Inst, VOP або миттєвий переказ СЕП України залежно від теми |
| Що змінює висновок | країна PSP, участь у схемі, валюта рахунку, effective date і доступність у провайдера |
Що потрібно знати до платежу
SCT є push payment
Credit transfer instruction виходить від payer або від сервісу, якому payer дав окреме право initiation. Creditor не списує кошти лише на підставі invoice. (EPC — SCT Inst Rulebook)
SDD спирається на mandate
У Direct Debit creditor подає collection через свій PSP на підставі authorisation payer. Mandate reference та creditor identifier потрібні для lifecycle і dispute handling. (EPC — Evolution of SEPA schemes)
Core і B2B мають різний participant scope
EPC веде окремі SDD Core та SDD Business-to-Business registers. Наявність банку в одному списку не підтверджує підтримку іншого scheme або account type. (EPC — реєстри учасників SEPA-схем)
Instant не перетворює SCT на debit
SCT Inst прискорює credit transfer, але не дає merchant права самостійно pull funds. Ініціатор і consent model лишаються credit-transfer, а не mandate-based SDD.
Як порівняти варіанти
| Варіант | Коли розглядати | Що перевірити до дії |
|---|---|---|
| Standing-order SCT | Сума й дата стабільні, а payer контролює instruction | Schedule, sufficient funds, beneficiary details і cancellation |
| SDD Core | Merchant збирає payment у consumers або eligible business | Mandate, prenotification, creditor ID та refund process |
| SDD B2B | Обидві сторони business і банки підтримують scheme | B2B mandate validation, participant registers і stricter refund conditions |
Покрокова підготовка
- Визначте ініціатора. Вирішіть, чи payer сам надсилатиме кожен transfer, чи creditor повинен подавати collection за mandate.
- Оцініть змінність суми. Для usage-based billing перевірте, як клієнт дізнається amount до списання та оскаржує помилку.
- Перевірте scheme reachability. Знайдіть PSP у SCT, SDD Core або SDD B2B register саме для потрібного account type.
- Побудуйте mandate lifecycle. Для SDD зберігайте issuance, reference, amendments, cancellation, last use і evidence customer authorisation.
- Підготуйте exceptions. Розділіть reject до settlement, return після processing, refund request і повторну collection із правильним reference.
Які дані та документи зібрати
- subscription contract із price і payment method
- standing-order instruction або SDD mandate
- creditor identifier та unique mandate reference
- EPC participant evidence для chosen scheme
- reconciliation, return та refund procedures
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Сервіс оренди спочатку просив клієнтів створювати standing order, але змінні utility charges постійно залишали борг. Компанія перейшла на SDD Core: отримала creditor ID, зібрала mandates, налаштувала prenotification та refunds. Для корпоративних клієнтів B2B не вмикали автоматично — спершу перевірили, чи їхні банки є в окремому register.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- називати standing order прямим дебетом лише через регулярність
- починати SDD collection без чинного mandate
- поширювати SDD Core participation на B2B scheme
- вважати SCT Inst механізмом pull payment для merchant
- не розрізняти return, refund і повторну collection
Де проходить межа поради
Точні mandate, prenotification та refund rights визначають чинний SDD rulebook, contract і consumer law. Матеріал допомагає вибрати модель, але не замінює юридичний дизайн subscription.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може оцінити доступний спосіб регулярної міжнародної оплати, але не створює SDD mandate або право списання без окремої договірної процедури. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
Дата редакційної перевірки: 2026-08-02.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.