Што е виртуелен IBAN?

Виртуелниот IBAN (vIBAN) е вистински, достапен за уплата број на меѓународна банкарска сметка, издаден од посебен опсег и насочен кон една главна сметка. Прима плаќања како секој друг IBAN — уплатувачот испраќа обичен SEPA кредитен трансфер од својата банка — но нема сопствено салдо. Неговата улога е идентификација: бидејќи секој виртуелен IBAN е доделен на точно еден уплатувач или намена, уплатата што пристигнува на него веќе кажува кој ја испратил и за што е. Парите автоматски се собираат на главната сметка; виртуелниот IBAN е ознаката на уплатата, а не второ место каде што стојат парите.

Таа една особина — еден IBAN по уплатувач — е целата идеја. За да видите зошто заслужува цел напис, започнете од проблемот што го отстранува.

Вистинскиот проблем: поврзување на парите со уплатувачите

Замислете бизнис што наплатува преку банкарски трансфер на една сметка: кирии, претплати, фактури. Секоја уплата стигнува на ист IBAN, а единствениот trag за тоа кој платил е она што уплатувачот го впишал во полето за повикување. Повикувањата се погрешно впишуваат, се скратуваат некаде по патот или воопшто се оставаат празни. Трансфер од €49.00 со нечитлива референца сè уште не е €49.00 признат приход — тоа е тикет. Некој мора да открие на кој клиент и на која фактура му припаѓа пред да се затворат книгите.

При мал обем тоа е досада. При обем на платформа тоа е цел оддел. Системите за поврзување ги оценуваат кандидат-фактурите според износ, датум и приближен текст на референцата; што не можат да сместат, оди во редица за луѓе. А проблемот е структурен: кога двајца претплатници плаќаат ист износ истиот ден без референца, ниту еден систем не може да ги разликува — информацијата што би ги разделила никогаш не била во уплатата.

Еден IBAN по уплатувач: идентитет по дизајн

Програмата за виртуелни IBAN го превртува дизајнот. Наместо секој уплатувач да го означува плаќањето правилно, му давате на секого своја адреса. Секој закупец, претплатник или продавач на маркетплејс плаќа на IBAN што е само негов. Полето за референца може да биде погрешно, празно или на друго писмо — уплатата сепак се идентификува сама, бидејќи идентитетот го носи бројот на сметката.

Бројот на сметка е многу подобар носител од референцата. IBAN има вградени контролни цифри, па погрешно впишан IBAN не поминува валидација во банката на уплатувачот уште пред трансферот да биде испратен. Погрешно впишана референца поминува и станува ваш проблем. Преместувањето на идентитетот од полето со слободен текст во адресата ја префрла проверката на грешки од вашата back office на банката што испраќа.

За уплатувачот ништо не се менява: плаќа на IBAN од својата банкарска апликација, како и секогаш. Целата новост е на страната на примачот — уплатата пристигнува однапред означена, а полето за референца се враќа на она што требало да биде од секогаш: белешка, а не систем за идентификација.

Кога секој уплатувач плаќа на свој IBAN, дојдовната уплата може да значи само едно. Проблемот со поврзувањето не се решава — туку престанува да постои.

Каде всушност стојат парите

Одоздола има точно една главна сметка по валута. Виртуелните IBAN се издаваат од опсези наменети за програмата, а секоја уплата на кој било од нив се порамнува на главната сметка. Нема салда по уплатувач за водење и нема крајдневни задачи што ги префрлаат средствата од илјадници мали сметки на една — концентрацијата се случува со насочување, а не со дополнителни трансфери што потоа сами би требало да ги порамнувате.

Тоа е и она што го прави виртуелниот IBAN вистински, а не трик. Достапен е од која било банка, се порамнува како секој SEPA кредит и се појавува на изводот на уплатувачот како сметката на која платил. Му недостасува точно она што го носи полната сметка: сопствено салдо и животен циклус надвор од доделување и повлекување.

Што виртуелниот IBAN не е

Не е подсметка: подсметката држи салдо, бара полнење и празнење и ги множи книгите што ги водите. Не е виртуелен референтен број: тие сè уште се возат на полето за референца и зависат од уплатувачите да ги препишат низите правилно. И не е паричник: ништо не се чува на самиот vIBAN. Тој е адреса со насочување зад неа — најтесната конструкција што ја прави дојдовната уплата сама да се идентификува.

Повраќајите се враќаат со причина

Плаќањата не само што пристигнуваат. Сметките се затвораат, банките ги одбиваат уплатите, уплатувачите ги повикуваат трансферите. Во свет со една сметка за наплата, повраќајот е мала истрага: која уплата се вратила, чија била и дали книжењето на кое било поврзано треба да се поништи?

Во програма со vIBAN, повраќајот е податок. Носи свој код на причина, пристигнува како настан payment.returned на истиот виртуелен IBAN што го користела првичната уплата и добива своја ставка на изводот. Знаете чија уплата се вратила и зошто пред некој да отвори тикет. Повраќајите стануваат редови за обработка, а не мистерии за бркање.

Редица за исклучоци, а не тим за поврзување

Ниту еден дизајн не порамнува сто проценти од ништо. Уплати пристигнуваат на повлечени vIBAN. Се случуваат дупликати. Некој, некако, плаќа директно на главната сметка. Целта не е исклучоците да бидат невозможни — туку да бидат ретки и преброиви. Во Protocore vIBAN демото, 99.6% од уплатите се порамнуваат автоматски; остатокот влегува во редица за преглед со целата историја на уплатувачот прикачена, па работата на исклучок почнува од контекст, а не од банкарски извод и табела.

Таа разлика го менува тимот. Операцијата за поврзување расте со обемот на плаќања: повеќе уплати, повеќе неповрзани уплати, повеќе луѓе. Процесот за исклучоци расте со обемот на исклучоци, што дизајнот веќе го турнал кон нула. Луѓето што ги задржувате работат вистински аномалии, а не препишуваат референци. Во нашиот стек таа редица живее во Protocore Center (/products/center), оперативната конзола каде секоја привилегирана дејност бара причина и завршува во ревизорска трага.

Масовно издавање, ознаки за намена, платформи

Еден IBAN по уплатувач функционира само ако издавањето на еден не чини ништо. Станодавец со десетина закупци може да ги создаде vIBAN рачно; маркетплејс што вклучува илјадници продавачи не може. Затоа издавањето е масовна операција. Во vIBAN демото, CSV со 2,400 уплатувачи се валидира, прикажува преглед на IBAN на секој ред и се издава со една дејност — 2,400 уплатувачи, една операција, со чекор за преглед помеѓу.

Ознаките за намена ги држат tokовите одвоени на ниво на адреса: кирија овде, претплати таму, исплати на маркетплејс на своја лента. Известувањето по намена станува филтер, а не проект, а секој vIBAN добива свој извод — CSV или PDF — додека главната сметка остане единствена линија на вистина одоздола. Кога уплатувачот си оди, неговиот vIBAN се повлекува: историјата останува, адресата престанува да прима нови уплати.

Каде се вклопува ова во стекот за плаќања

Виртуелните IBAN се инфраструктура за наплата. Им даваат на дојдовните банкарски трансфери она што картичните плаќања отсекогаш го имале — идентитет прикачен на самото плаќање, а не впишан покрај него. Во екосистемот на Protocore, нарачките со плаќање преку трансфер во Gateway носат vIBAN референци, а Center ги обработува исклучоците што ќе ги остави поврзувањето. Страницата на производот на /products/viban го води целиот круг — издавање, споделување, поврзување, исклучоци, известување — на истите демо-податоци што се користат овде.

И искрена граница: ако примате неколку трансфери месечно, договор за референца и десет минути книговодство се сосема доволни. Виртуелните IBAN се исплатуваат таму каде обемот го претворил поврзувањето во процес — кирии, наплата на претплати, маркетплејси — секаде каде прашањето кој ви платил се поставува илјадници пати месечно.