Свързване на фактуриране и плащания: архитектура, предизвикателства и добри практики

1. Защо фактурирането и плащанията трябва да останат отделни, но свързани

Фактурирането и обработката на плащания са тясно свързани, но имат различни отговорности.

Системата за фактуриране управлява финансовите документи и свързаните с тях записи.

Според обхвата си тя може да се грижи за създаването, номерирането, издаването и коригирането на фактури, както и за връзките с клиентските данни или информацията за таксуване.

Платежната система управлява процеса на събиране на пари.

Тя може да комуникира с платежни доставчици, да създава заявки за плащане, да обработва известия за трансакции и да проследява опити за плащане, възстановявания или други финансови събития.

Тези отговорности не трябва да се смесват.

Например едно плащане може да е неуспешно, без това да прави първоначалната фактура невалидна. По същия начин коригирането на фактура не отменя автоматично вече събрано плащане.

Системите трябва да обменят информация, като запазват значението и историята на собствените си записи.

Проблемът с тясно обвързаните системи

Да разгледаме приложение, в което всяко успешно плащане автоматично създава фактура, а всяко неуспешно плащане предотвратява създаването ѝ.

Такъв процес може да работи за определени бизнес модели, но става ограничаващ, когато възникнат други сценарии.

Какво се случва, когато бизнесът трябва да:

• Издаде фактура, преди да поиска плащане?
• Приеме банков превод няколко дни след издаването на фактура?
• Запише плащане, събрано извън приложението?
• Получи няколко частични плащания по една фактура?
• Издаде коригиращ документ, без да променя първоначалното плащане?
• Използва различни платежни доставчици за различни клиенти?

При тясно обвързан дизайн всеки сценарий може да изисква изключения и обходни решения.

По-гъвкавата архитектура позволява на фактурирането и обработката на плащания да работят независимо, като поддържа изрични връзки между записите им.

Това улеснява поддръжката на различни търговски процеси, без всяка трансакция да се третира по един и същ начин.

2. Проектирайте около бизнес записите, а не само около полетата за статус

Една от най-честите интеграционни грешки е свеждането на връзката между фактуриране и плащания до едно поле, например paid = true.

Това поле може да е удобно за показване на информация, но не може да опише всяка финансова ситуация.

Да разгледаме фактура за 500 евро.

Клиентът може да направи две плащания от 200 и 300 евро.

В друг случай клиентът може да опита да плати 500 евро, трансакцията да е неуспешна и по-късно да завърши успешно плащане.

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

Надеждната интеграция трябва да запазва тези разлики.

Основните записи

Типичната архитектура може да разграничава следните обекти:

Тези записи не са непременно във връзка едно към едно.

Една фактура може да има няколко опита за плащане.

Едно плащане може да бъде разпределено между няколко фактури.

Възстановяването може да се отнася само до част от предходно плащане.

Поддържането на тези връзки прави финансовата история по-полезна от един обобщен статус.

Пример: частични плащания

Да предположим, че бизнесът издава фактура за 600 евро.

Клиентът плаща 250 евро веднага и останалите 350 евро една седмица по-късно.

Системата за фактуриране трябва да може да представи:

• Първоначална сума на фактурата: 600 евро.
• Първо разпределено плащане: 250 евро.
• Неплатена сума след първото плащане: 350 евро.
• Второ разпределено плащане: 350 евро.
• Окончателна неплатена сума: 0 евро.

Точното документиране и счетоводно третиране зависи от приложимите правила.

Въпреки това основните платежни записи трябва да обясняват как неплатеният остатък се е променял във времето.

Това става особено важно, когато клиент или финансов екип по-късно проверява трансакцията.

3. Използвайте устойчиви идентификатори за свързване на системите

Надеждните интеграции зависят от последователни референции.

Приложението за фактуриране може да идентифицира документ чрез вътрешен идентификатор в базата данни и официален номер на фактурата.

Платежният доставчик може да присвоява собствен идентификатор на всяка трансакция.

Платформата за таксуване може да използва друг идентификатор за абонамента, поръчката или периода на таксуване.

Тези референции имат различни цели, но трябва да останат свързани.

Вътрешни и външни референции

Бизнесът може да поддържа информация като:

Тези идентификатори са илюстративни.

Системата не трябва да приема, че идентификаторът на трансакцията при външния доставчик е и идентификатор на фактурата.

Вместо това тя трябва изрично да запазва връзката.

Така трансакцията може да бъде намерена и от двете страни: като се започне от фактурата или от платежния запис при доставчика.

Избягвайте съпоставяне само по сума и дата

Двама клиенти могат да платят една и съща сума в един и същ ден.

Един клиент може също да направи няколко еднакви плащания за различни услуги.

Затова съпоставянето на записи само по сума и времеви маркер може да създаде неправилни връзки.

Устойчивите идентификатори и референциите на трансакциите са по-надеждни.

Когато доставчиците поддържат референции или метаданни, зададени от търговеца, те могат да помогнат за запазване на връзката между външното плащане и съответната бизнес трансакция.

Външните референции обаче трябва да се проверяват, вместо да им се вярва безусловно.

4. Обработвайте платежните събития асинхронно

Много платежни интеграции разчитат на асинхронни известия, обикновено наричани webhooks.

Webhook позволява на платежния доставчик да уведоми бизнес приложение, когато настъпи съответно събитие.

Например доставчикът може да изпрати известие, когато плащането е успешно, неуспешно или сумата е възстановена.

Това премахва нуждата бизнес приложението непрекъснато да запитва за последния статус на всяка трансакция.

Асинхронната обработка на събития обаче има свои предизвикателства.

Известията могат да пристигнат повече от веднъж

Доставчикът може да изпрати известието отново, ако не получи потвърждение, че събитието е обработено.

В резултат едно и също събитие може да бъде доставено няколко пъти.

Ако приложението обработва всяко известие като нова финансова трансакция, могат да се появят дублирани записи.

Устойчивата интеграция трябва да разпознава вече обработените събития и да гарантира, че повторната доставка не създава повторни финансови ефекти.

Известията може да пристигнат в различен ред

Платежно събитие, създадено по-рано, може да пристигне след по-ново събитие.

Например забавено известие за по-ранно състояние на плащането може да пристигне, след като приложението вече е записало успешно събиране на средствата.

Системата не трябва автоматично да заменя текущото състояние с по-старо.

Вместо това обработката трябва да отчита правилата за жизнения цикъл при доставчика, идентификаторите на събитията и достоверната информация за трансакцията.

Известията могат да се забавят или да бъдат пропуснати

Мрежови грешки, временни прекъсвания на услуги и конфигурационни проблеми могат да прекъснат доставката на събития.

Надеждната интеграция трябва да има начин да открива липсваща информация и да я възстановява.

Това може да включва периодична проверка на неразрешените трансакции чрез API на доставчика или извличане на събития, които не са обработени успешно.

Проверявайте известията, преди да ги обработите

Крайните точки за webhooks са достъпни за външни заявки.

Приложенията трябва да удостоверяват известията чрез механизмите за сигурност, определени от доставчика, например проверка на подписа.

Само проверени събития трябва да могат да променят финансовите записи.

Заедно тези практики помагат временен комуникационен проблем да не се превърне в постоянно несъответствие между системите.

Вижте документацията на Stripe за webhooks ↗ (отваря се в нов раздел) за разглеждане при конкретен доставчик на дублираните събития, реда на получаване, повторните опити и проверката на подписите.

5. Предотвратявайте дублирането на финансови операции

Повторната обработка е особено опасна във финансовите приложения.

Повторена заявка може случайно да създаде два опита за плащане, да издаде дублирани фактури или да приложи едно възстановяване на сума два пъти.

Една често използвана техника за предотвратяване на дублирани операции е идемпотентността.

Идемпотентната операция дава същия предвиден резултат, когато една и съща логическа заявка се обработва многократно.

Пример: събитие за периодично таксуване

Да си представим, че подновяване на абонамент задейства заявка за създаване на фактура.

Услугата за фактуриране създава документа успешно, но отговорът се губи поради изтичане на времето за изчакване в мрежата.

Приложението за таксуване не знае дали операцията е приключила, затова опитва отново.

Без подходящи защити втората заявка може да създаде още една фактура за същото събитие.

Идемпотентният дизайн разпознава, че двете заявки представляват една и съща предвидена операция.

Вместо да създаде втори документ, той връща или посочва съществуващия резултат.

Прилагайте идемпотентност на подходящото ниво

Идемпотентността трябва да се разглежда отделно за операции като:

• Създаване на фактура.
• Иницииране на плащане.
• Обработка на входящо платежно събитие.
• Записване на разпределение на плащане.
• Иницииране или записване на възстановяване на сума.

Защитите за една операция не предпазват непременно друга.

Например предотвратяването на повторна обработка на webhook не предотвратява автоматично инициирането на две заявки за плащане от бизнес приложението.

Ключовете за идемпотентност, уникалните ограничения в базата данни и транзакционната обработка могат да помогнат, но конкретната реализация зависи от системата и доставчика.

Приложението трябва също да разбира ограниченията на механизмите за идемпотентност при външния доставчик, включително сроковете за съхранение.

За пример за поведението и ограниченията при конкретен доставчик вижте документацията на Stripe за идемпотентни заявки ↗ (отваря се в нов раздел).

6. Разграничавайте състоянията на фактурата, плащането и сетълмента

Чест източник на объркване е третирането на всички финансови статуси като взаимозаменяеми.

Една фактура може да е неплатена или платена.

Опитът за плащане може да е в изчакване, успешен, неуспешен или отменен.

Сетълментът при доставчика може да се обработва, да е завършен или да е включен в по-късно изплащане.

Тези състояния описват различни процеси.

Пример: завършено плащане, което очаква изплащане към търговеца

Да предположим, че клиент плаща фактура за 100 евро с карта.

Платежният доставчик потвърждава, че сумата по плащането на клиента е уловена.

Свързаната фактура вече може да отговаря на условията да бъде отбелязана като платена според приложимите правила на бизнеса.

Доставчикът обаче може да преведе съответните средства по банковата сметка на търговеца едва няколко дни по-късно.

Затова системата трябва да разграничава:

• Резултата от плащането на клиента.
• Неплатения остатък по фактурата.
• Статуса на сетълмента или изплащането при доставчика.

Обединяването им в едно състояние може да създаде подвеждаща информация.

Например фактурата не трябва непременно да остава отбелязана като неплатена само защото доставчикът не е завършил изплащането към търговеца.

По същия начин една трансакция не трябва да се третира като събрано плащане само защото авторизацията ѝ е успешна.

Целта е да се запази значението на всяко състояние, като същевременно бизнесът може да ги разглежда заедно.

Документацията на Adyen за жизнения цикъл на плащанията ↗ (отваря се в нов раздел) показва защо сетълментът и изплащането трябва да остават отделни. За по-широко обяснение вижте Как протича едно онлайн плащане: от авторизация до сетълмент.

7. Обработвайте възстановяванията и корекциите като свързани, но отделни операции

Възстановяванията на суми и корекциите на фактури често възникват заедно, но не са едно и също.

Възстановяването е платежна операция, която връща пари на клиента.

Корекцията на фактура променя или допълва финансовата документация за първоначалната трансакция според приложимите правила за фактуриране.

Да разгледаме клиент, който купува услуга за 200 евро и впоследствие получава възстановяване от 50 евро.

Платежната система трябва да запише първоначалното плащане и възстановяването.

Системата за фактуриране може да трябва да издаде подходящ коригиращ документ според трансакцията и приложимата юрисдикция.

Тези дейности трябва да останат свързани, но не трябва да се приема, че едната замества другата.

Запазвайте връзката между записите

Полезната финансова история може да съдържа:

• Първоначална фактура: 200 евро.
• Първоначално събрано плащане: 200 евро.
• Събитие за възстановяване на сума: 50 евро.
• Свързан коригиращ документ, когато е необходим.

Заедно тези записи обясняват какво се е случило.

Изтриването или тихото пренаписване на първоначалната трансакция би затруднило последващите проверки.

За бизнесите, които работят в няколко юрисдикции, отразяването на възстановяванията и корекциите във фактурите трябва да се определя отделно от техническия платежен процес.

8. Изберете интеграционна архитектура, която отговаря на бизнеса

Няма една архитектура, подходяща за всяка интеграция на фактуриране и плащания.

Подходящият дизайн зависи от обема на трансакциите, броя на доставчиците, бизнес процесите и оперативните изисквания.

Три често срещани подхода показват компромисите.

Директна интеграция

Бизнес приложението се интегрира директно със система за фактуриране и платежен доставчик.

Приложението отговаря за обмена на информация и поддържането на връзките между записите.

Този подход може да е достатъчен при малко интеграции и сравнително прости бизнес изисквания.

Приложението обаче трябва да обработва специфичните за доставчика събития, съпоставянето на статуси и сценариите при неуспех.

Централен интеграционен слой

Специализиран интеграционен компонент стои между бизнес приложенията и външните услуги.

Той получава платежни събития, преобразува специфичната за доставчика информация в последователно вътрешно представяне и свързва получените събития със съответните бизнес записи.

Това може да е полезно, когато бизнесът използва няколко приложения или платежни доставчици.

Същевременно се добавя компонент, който трябва да се поддържа, защитава и наблюдава.

Платформа за свързани финансови процеси

Бизнесът може да използва платформа, която предоставя възможности за фактуриране и плащания чрез общ интеграционен модел.

Такава платформа може да намали количеството собствена логика за свързване, която бизнесът трябва да поддържа, според поддържаните възможности и интеграции.

Бизнесът обаче трябва да прецени кои отговорности действително се поемат от платформата.

Например поддръжката на платежна интеграция не означава автоматично, че платформата обработва или държи клиентски средства.

По същия начин свързването на платежни записи не означава непременно, че платформата осигурява счетоводство или пълно банково съпоставяне.

Важното е дали избраната архитектура създава надеждни връзки, без да прикрива отговорностите на отделните системи.

9. Проектирайте за работа с няколко платежни доставчика

С растежа на бизнеса могат да се добавят платежни доставчици за нови пазари, местни платежни методи или различни търговски договорености.

Всеки доставчик може да предоставя собствен API, видове събития, идентификатори на трансакции и терминология за статусите.

Без последователен вътрешен интеграционен модел бизнес приложенията могат да станат зависими от специфичните особености на доставчиците.

Например различни доставчици могат да използват различни наименования, за да покажат дали трансакцията е авторизирана, сумата е уловена, сетълментът е приключил или сумата е възстановена.

Централен компонент за проследяване на плащанията може да преобразува съответните събития в последователно вътрешно представяне.

Уеднаквявайте значението, а не само наименованията

Преобразуването на статуса „успех“ при всеки доставчик в една и съща вътрешна стойност може да изглежда удобно.

Съответните събития при доставчиците обаче могат да представляват различни финансови етапи.

Добрият интеграционен модел запазва тези разграничения.

Вътрешната система трябва да отразява какво действително се е случило, дори когато терминологията на доставчика е различна.

Тя трябва също да запазва първоначалната референция при доставчика и достатъчно изходна информация за проверка на необичайни случаи.

Избягвайте ненужна зависимост от доставчик

Когато е практично, бизнес приложенията трябва да използват собствени устойчиви идентификатори и вътрешни финансови връзки.

Това улеснява добавянето на платежни доставчици, без да се преработват фактурните записи или процесите за таксуване на клиенти.

Освен това позволява историческите трансакции при предишни доставчици да останат проследими.

10. Осигурете видимост върху финансовите интеграции

Дори добре проектираните интеграции срещат проблеми.

Платежно известие може да се забави, API може да стане временно недостъпен или запис да съдържа несъгласувана информация.

Надеждната система трябва да прави тези ситуации видими.

Полезните оперативни възможности включват:

История на обработката на събития

Запис на съответните входящи събития и начина, по който са обработени.

Проследяване на неуспешни операции

Видимост върху заявки или известия, които не са обработени успешно.

Безопасни повторни опити

Механизми за повтаряне на неуспешни операции, без дублиране на финансовите ефекти.

Неразрешени платежни референции

Начин за откриване на плащания, които не могат да бъдат свързани с очакваната фактура, поръчка или клиентски акаунт.

Възможност за одит

Достатъчно информация, за да се разбере кога записите са създадени или актуализирани и коя операция е причинила промяната.

Чувствителна платежна или клиентска информация не трябва да се разкрива ненужно в логове или диагностични записи.

Целта на оперативната видимост не е само техническо отстраняване на проблеми.

Тя помага и на финансовите екипи и обслужването на клиенти да откриват несъответствия и да разбират финансовата история на клиентските трансакции.

11. Практически списък за проверка на интеграцията

Преди да въведе интеграция на фактуриране и плащания в реална работа, бизнесът трябва да може да отговори на няколко въпроса.

Връзки между данните

• Може ли всяко плащане да се свърже със съответната бизнес трансакция?
• Може ли една фактура да има няколко свързани плащания?
• Може ли едно плащане да бъде разпределено между няколко фактури при необходимост?
• Проследими ли са възстановяванията и корекциите до първоначалните записи?

Надеждност на събитията

• Удостоверяват ли се входящите известия?
• Могат ли дублираните събития да се обработват безопасно?
• Може ли приложението да обработва забавени събития или събития, получени в различен ред?
• Има ли процес за възстановяване на липсващи актуализации?

Финансова точност

• Разграничават ли се авторизацията, събирането на средства, сетълментът и изплащането?
• Изчисляват ли се остатъците по фактурите чрез подходящо разпределение на плащанията?
• Тълкуват ли се платежните статуси според действителното им значение при доставчика?
• Могат ли финансовите екипи да проверяват несъответствия, без да възстановяват записите ръчно?

Оперативна устойчивост

• Видими ли са неуспехите?
• Могат ли операциите да се повтарят, без да създават дублирани записи?
• Запазват ли се идентификаторите при външните доставчици?
• Има ли разбираема история на важните финансови промени?

Не всеки бизнес се нуждае от една и съща степен на сложност.

Въпреки това ранното разглеждане на тези въпроси може да предотврати оперативни проблеми с увеличаването на обема на трансакциите и изискванията към интеграциите.

Заключение

Свързването на фактуриране и плащания не е просто прехвърляне на статус на трансакция между две приложения.

Надеждната интеграция изисква ясно разбиране на записите, които всяка система управлява, и на връзките между тях.

Фактурите, опитите за плащане, събраните плащания, възстановяванията, сетълментите и корекциите представляват различни финансови събития.

Устойчивите идентификатори, асинхронната обработка на събития, идемпотентните операции и проследимите финансови истории правят тези връзки по-надеждни.

За SaaS компаниите и онлайн бизнесите тези основи осигуряват гъвкавост с увеличаването на обема на трансакциите, смяната на платежни доставчици и усложняването на финансовите процеси.

Целта не е непременно всички операции да се съберат в една система.

Тя е участващите системи да могат да работят независимо, когато е подходящо, като поддържат съгласуван и разбираем поглед върху финансовата дейност на бизнеса.