Що таке віртуальний IBAN?

Віртуальний IBAN (vIBAN) — це справжній номер міжнародного банківського рахунку, який видається з окремого діапазону та маршрутизується на єдиний мастер-рахунок. Він приймає платежі як будь-який інший IBAN: платник надсилає на нього звичайний кредитовий переказ SEPA зі свого банку, але власного балансу в нього немає. Його завдання — ідентифікація: оскільки кожен віртуальний IBAN закріплений за одним платником або призначенням, платіж, що на нього надійшов, уже сам каже, хто його надіслав і за що. Гроші автоматично концентруються на мастер-рахунку; віртуальний IBAN — це мітка платежу, а не друге місце, де лежать гроші.

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

Справжня проблема: зіставити гроші з платниками

Уявіть бізнес, який збирає оплату банківськими переказами на один рахунок: оренду, підписки, інвойси. Усі надходження потрапляють на один IBAN, а єдина підказка, хто заплатив, — те, що платник вписав у поле призначення платежу. Призначення плутають, воно обрізається десь по дорозі або взагалі лишається порожнім. Переказ на €49.00 зі спотвореним призначенням — це ще не €49.00 визнаного доходу, а тікет. Хтось має з'ясувати, якому клієнтові та якому інвойсу він належить, до закриття періоду.

На малих обсягах це дрібна неприємність. На обсягах платформи — ціла служба. Системи зіставлення оцінюють інвойси-кандидати за сумою, датою та нечітким збігом тексту призначення; усе, що не вдалося розподілити, потрапляє в чергу до людини. До того ж збій тут структурний: коли двоє підписників платять однакову суму в один день без призначення, жоден алгоритм їх не розрізнить — інформації, яка їх розрізняє, у платежі просто не було.

Один IBAN на платника: ідентичність закладена в конструкцію

Програма віртуальних IBAN перевертає підхід. Замість того щоб просити кожного платника правильно підписати платіж, ви даєте кожному власну адресу. Кожен орендар, підписник чи продавець маркетплейсу платить на IBAN, який належить лише йому. Поле призначення може бути хибним, порожнім чи написаним іншим алфавітом — надходження все одно ідентифікує себе, бо ідентичність несе номер рахунку.

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

Для платника нічого не змінюється: він, як завжди, платить на IBAN зі свого банківського застосунку. Уся новизна — на боці отримувача: платіж приходить уже з міткою, а поле призначення знову стає тим, чим мало бути завжди, — приміткою, а не системою ідентифікації.

Коли кожен платник платить на власний IBAN, вхідний платіж може означати лише одне. Проблема зіставлення не вирішується — вона перестає існувати.

Де насправді лежать гроші

Під капотом на кожну валюту є рівно один мастер-рахунок. Віртуальні IBAN видаються з діапазонів, виділених для програми, і кожне надходження на будь-який із них зараховується на мастер-рахунок. Немає балансів по платниках, якими треба керувати, і немає щоденних задач, що переганяють кошти з тисяч дрібних рахунків в один, — концентрація відбувається маршрутизацією, а не додатковими переказами, які потім довелося б звіряти окремо.

Саме це робить віртуальний IBAN справжнім, а не фокусом. На нього можна платити з будь-якого банку, він проходить як звичайний кредитовий переказ SEPA і відображається у виписці платника як рахунок, на який він заплатив. Йому бракує рівно того, що тягне за собою повноцінний рахунок: власного балансу та життєвого циклу, крім призначення й виведення з обігу.

Чим віртуальний IBAN не є

Це не субрахунок: субрахунок тримає баланс, потребує поповнення й виведення коштів і примножує облікові книги, які ви ведете. Це не віртуальний референс-номер: такі номери все одно їдуть у полі призначення й залежать від того, чи правильно платники скопіюють рядок. І це не гаманець: на самому vIBAN нічого не зберігається. Це адреса з маршрутизацією за нею — найвужча конструкція, що робить вхідний платіж самоідентифікованим.

Повернення приходять із причиною

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

У програмі vIBAN повернення — це дані. Воно несе код причини, надходить як подія payment.returned за тим самим віртуальним IBAN, що й початкове зарахування, і має власний рядок у виписці. Ви знаєте, чий платіж повернувся і чому, ще до того, як хтось відкрив тікет. Повернення стають рядками для обробки, а не загадками для розслідування.

Черга винятків замість команди зіставлення

Жоден дизайн не звіряє сто відсотків чогось. Кошти надходять на виведені з обігу vIBAN. Трапляються дублікати. Хтось якимось чином платить прямо на мастер-рахунок. Мета — не зробити винятки неможливими, а зробити їх рідкісними й обчислюваними. У демо vIBAN від Protocore 99.6% зарахувань звіряються автоматично; решта потрапляє в чергу на перевірку з повною історією платника, тож робота з винятком починається з контексту, а не з банківської виписки й таблиці.

Ця різниця змінює саму команду. Операція зіставлення росте разом з обсягом платежів: більше зарахувань — більше нерозпізнаних — більше людей. Процес винятків росте разом з обсягом винятків, який дизайн уже штовхнув до нуля. Люди, яких ви залишаєте, розбирають справжні аномалії, а не перепечатані призначення. У нашому стеку ця черга живе в Protocore Center (/products/center) — операційній консолі, де кожна привілейована дія вимагає причини й потрапляє в журнал аудиту.

Масове випускання, теги призначення, платформи

Один IBAN на платника працює, лише якщо випуск нічого не коштує. Орендодавець із десятком орендарів може створити vIBAN вручну; маркетплейс, що підключає тисячі продавців, — ні. Тому випуск — масова операція. У демо vIBAN CSV із 2,400 платників проходить валідацію, показує попередній перегляд IBAN у кожному рядку й випускається однією дією — 2,400 платників, одна операція, крок перевірки посередині.

Теги призначення розводять потоки на рівні адреси: оренда тут, підписки там, виплати маркетплейсу — окремою доріжкою. Звітність за призначенням стає фільтром, а не проєктом, а кожен vIBAN отримує власну виписку — CSV або PDF, — тоді як мастер-рахунок лишається єдиним джерелом істини. Коли платник іде, його vIBAN виводиться з обігу: історія лишається, адреса більше не приймає нових зарахувань.

Місце в платіжному стеку

Віртуальні IBAN — це інфраструктура збору коштів. Вони дають вхідним банківським переказам те, що картковим платежам було властиве завжди: ідентичність, прикріплену до самого платежу, а не вписану поруч. В екосистемі Protocore замовлення Gateway з оплатою переказом містять референси vIBAN, а Center обробляє винятки, які залишає зіставлення. Сторінка продукту /products/viban проводить через увесь цикл — випуск, передача, зіставлення, винятки, звіт — на тих самих демоданих, що й тут.

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