Масови плащания: контрол на получателите, одобренията и статуса

Определете какво означава плащане в този случай

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

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

Изходящи плащания

Проверете получателите преди одобрение

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

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

Платежни отчети

Одобрявайте точна версия на пакета

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

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

Следете резултата на всеки ред

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

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

Сверявайте отчета с действителните операции

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

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

Разделете изискванията от наличния продукт

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

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

Източници

• Stripe Webhooks
• OrsunPay: продукти