GH GambleHub

Interac Канада: e-Transfer і ліміти

1) Контекст і місце Interac в платіжній екосистемі

Interac e-Transfer - популярна рейка P2P/P2B/P2M всередині Канади, що працює через банки і кредитні спілки. Оплата відправляється на email/номер телефону одержувача або безпосередньо на його банківський рахунок через Autodeposit. Переклади близькі до миттєвих і доступні 24/7, при цьому фінальна зараховуваність і ліміти залежать від конкретної фінансової установи (FI).

Ключові властивості:
  • Адресація без реквізитів: відправка по email/телефону; одержувач обирає банк для зарахування.
  • Autodeposit: автоматичне зарахування на рахунок одержувача без секретного питання.
  • Request Money: «запит платежу» з сумою та призначенням, що підтверджується у платника.
  • Нативна доступність: підтримується більшістю канадських банків в мобільних/онлайн-банкінгах.
  • Комісії та ліміти визначаються банками/планами акаунтів, а не єдиною «схемою».

2) Учасники та ролі

Interac - мережевий оператор, маршрутизація і правила сервісу.
FI платника (Sender FI) - ініціює переклад, застосовує KYC/AML, ліміти та антифрод.
FI одержувача (Recipient FI) - зараховує кошти, обслуговує Autodeposit/Request Money.
Платник - фізособа/бізнес, що оплачує за email/телефоном/запитом.
Мерчант - бізнес-одержувач; може використовувати Autodeposit і/або корпоративні функції e-Transfer for Business у свого банку.

3) Ідентифікатори та адресація

Email/Номер телефону - основний «аліас» одержувача.
Autodeposit-адреса - email/номер прив'язаний до конкретного банківського рахунку одержувача; переклад падає відразу без Q&A.
Одержувач за контактами - в адресній книзі банку зберігаються перевірені бенефіціари (впливає на ризик-політику та ліміти у деяких FI).
Payment Reference - текст призначення/номер замовлення; прокочується в квитанції та звітах.

4) Потоки платежів

4. 1 P2P/P2B (push)

1. Відправник вказує email/телефон одержувача і суму.
2. (Опціонально) секретне питання/відповідь Q&A - якщо у одержувача не налаштований Autodeposit.
3. Одержувач отримує повідомлення (email/SMS) → вибирає свій банк/заходить в онлайн-банк → відповідає на питання (якщо є) → кошти зараховуються.
4. При Autodeposit кроки 2-3 пропускаються: гроші приходять автоматично.

4. 2 Request Money (collect)

1. Мерчант надсилає платнику запит із сумою/призначенням.
2. Платник підтверджує в онлайн-банку → кошти відправляються як звичайний e-Transfer.
3. Мерчанту приходить повідомлення і зарахування.

4. 3 Для бізнесу (e-Transfer for Business)

Підтримка bulk-сценаріїв у ряду банків (масові запити/виплати).
Розширена звітність та ліміти за корпоративними акаунтами.
Часто доступні API/host-to-host у банку для інтеграції в ERP/білінг.

5) Ліміти і як з ними працювати

Ліміти задаються банком платника (і іноді одержувача) і залежать від типу аккаунта, історії, KYC/AML-профілю і ризику.

Типи лімітів:
  • Per-transaction - максимум на одну операцію.
  • Per-day/24h - сумарна денна величина.
  • Weekly/Monthly - тижневі/місячні стелі за сумою/кількістю.
  • Новий одержувач - тимчасово знижені ліміти та/або витримка для перших переказів на новий контакт.
  • Q&A vs Autodeposit - при Autodeposit у частини банків діють інші пороги і перевірки.
  • Request Money - ліміти можуть відрізнятися від «звичайної» відправки.
  • Business/Treasury - корпоративні акаунти нерідко мають втричі-вище базові ліміти і гнучкі квоти за погодженням.
Практика для продуктової команди:
  • Не хардкодьте числа - ведіть довідник лімітів по банках/планах і оновлюйте його.
  • В UX показуйте інформативну помилку «перевищений ліміт у вашого банку» + підказку варіантів (дроблення, інший метод).
  • Для рекурентних сценаріїв використовуйте Request Money з автопам'яттю одержувача і/або альтернативні рейки (PAD/ACH-дебет).

6) Безпека, Q&A і Autodeposit

Q&A (секретне питання/відповідь) захищає переклад, якщо Autodeposit не налаштований у одержувача. Відповідь передається в зашифрованому вигляді і потрібна для зарахування.
Autodeposit знижує ризик фішингу по Q&A і прискорює флоу - рекомендується мерчантам.
Notification hardening: попереджайте клієнтів, що банк ніколи не запитує PIN/паролі по email/SMS; навчайте розпізнавати фішингові «запити платежу».
Device/IP/velocity-контролінг на рівні банку платника.

7) Статуси, скасування та повернення

Pending/In Progress/Completed/Failed/Expired - типові статуси.
До прийняття одержувачем переказ можна відкликати (cancel) відправником у своєму банку (якщо не Autodeposit).
Chargeback як в картах відсутній. Повернення після зарахування - це нова кредитова операція від мерчанта платнику.
Partial refund підтримується через окремі операції.
У спірних кейсах (шахрайство, помилка адресата) ескалація йде через банки і регламенти підтримки.

8) Звірка і звітність

Зберігайте банківські ідентифікатори операції (confirmation/reference number), email/телефон одержувача, суму, timestamp, призначення.
Увімкніть daily auto-recon (операційний) і періодичний full-recon (фінансовий).
Для bulk-виплат/запитів використовуйте звіти банку/PSP з результатами по кожному рядку (success/fail/expired/canceled).

9) Комісії та витрати

Вартість e-Transfer визначається тарифами банку аккаунта (часто фікс за відправку; для бізнесу - пакетні плани).
За отримання у мерчантів/фізосіб частіше комісії немає, але умови залежать від FI.
Закладайте витрати на підтримку (фрод/фішинг-скарги), SLA обробки запитів і відмін.

10) Ризики і антифрод

Фішинг по Q&A: зловмисник перехоплює email/SMS і намагається виманити відповідь. Мітигується Autodeposit, навчанням користувачів і обмеженням спроб.
Помилкова адреса: підтвердження імені одержувача перед відправкою обмежено - компенсуйте UX-підсвічуванням контакту і дворазовим підтвердженням email/телефону.
Соціальна інженерія та «refund-scams»: запасайтеся сценаріями перевірки в саппорті і стандартами повернень.

11) iGaming та інші чутливі вертикалі

Банки і платіжні провайдери в Канаді застосовують категорійні політики: для окремих видів бізнесу ліміти і доступність e-Transfer можуть бути обмежені.
Очікуйте звужені ліміти, розширений KYC і можливі вимоги до «джерела коштів».
Тримайте альтернативні рейки (наприклад, PAD/ACH-дебет, карткові платежі, AFT) і сегментацію по ризику.

12) Інтеграція мерчанта

Варіанти

1. Autodeposit для прийому

Простий старт: публікуєте email/номер, налаштовуєте Autodeposit.
Мінуси: ручне введення суми платником (помилки), слабкіше per-order аналітика.

2. Request Money (інвойс/collect)

Створюєте запит з фіксованою сумою/призначенням → платник підтверджує.
Краще по звірці і конверсії; підходить і для one-off, і для повторюваних платежів.

3. Business e-Transfer через банк/PSP

Доступ до bulk-операцій, розширених лімітів, API/host-to-host.
Вимагає корпоративного акаунта і онбордингу у FI.

Обов'язкові компоненти бекенду:
  • 'webhook/callback'на статуси (або опитування по backoff).
  • Таблиця ідемпотентності (orderId + ключ запиту).
  • Конектор до банківського recon-звіту.
  • Refund-флоу (часткові/повні).
  • Моніторинг SLA (успіх/відмови/латентність/expiries).

13) UX-рекомендації

Для one-off платежів - робіть ставку на Request Money (менше помилок, чітка звірка).
Показуйте таймер дії запиту, зрозумілі статуси і кроки повтору.
Давайте вибираємо: «Оплатити зараз» (Request) або «Відправити вручну» (Autodeposit/email/телефон).
Окремий екран безпеки: про Q&A, фішинг, «ми ніколи не просимо паролі».

14) Архітектура «Interac Gateway»

API поверхні: `createRequest`, `cancelRequest`, `queryStatus`, `processRefund`, `reconcile`.
Надійність: ідемпотентність, ретраї за експонентом, дедуп за зовнішніми референсами банку.
Дані: каталог лімітів по банках, карта одержувачів (новий/довірений), статуси expiries.
Безпека: HMAC-підписи веб-хуків, allowlist IP банку/PSP, журнал аудиту, шифрування PII (email/телефон).
Observability: метрики конверсії по каналах (Autodeposit vs Request), час до зарахування, частка expiries/cancel.

15) Чек-лист виведення в прод

1. Виберіть банк/PSP і корпоративний план з потрібними лімітами/API.
2. Налаштуйте Autodeposit та/або Request Money; протестуйте expiries/скасування.
3. Реалізуйте статуси/веб-хуки, ідемпотентність і recon.
4. Увімкніть Refund-флоу і ODR-процедури в саппорті.
5. Додайте екрани безпеки (Q&A, фішинг), зрозумілі помилки лімітів.
6. Запустіть моніторинг SLA та алерти по банках/каналах.
7. Проведіть end-to-end тести з декількома великими FI.

Картка лімітів (орієнтири для проектування)

💡 Фактичні ліміти встановлює банк/план аккаунта; нижче - організаційні орієнтири.

Per-txn / 24h / 7d / 30d: зберігати в конфігу і перевіряти перед ініціацією.
Нові одержувачі: тимчасово знижені пороги та/або витримка.
Autodeposit vs Q&A: можливі різні пороги і антифрод-правила.
Корпоративні акаунти: підвищені ліміти за заявкою + доп. due diligence.

Резюме

Для онлайну і точної звірки використовуйте Request Money; для простого прийому - Autodeposit.
Не «вшивайте» конкретні цифри: тримайте конфіги лімітів по FI і оновлюйте їх.
Вбудовуйте refund/ODR, детальну звітність і денний recon.
Навчайте клієнтів безпеки і пропонуйте Autodeposit для кращого UX і меншого фроду.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.