Obecný princip automatického párování plateb s účtem u FIO

ales.k
Člen | 6
+
0
-

Ahoj,
na jednom projektu chci implementovat automatické párování plateb s účtem u FIO banky. Vím, že mají docela dobré API, podle dokumentace to vypadá, že použiji formát JSON.
Potřeboval bych od vás zpětnou vazbu jestli proces párování, co jsem navrhl, vám dává smysl.

V DB projektu existuje tabulka registrací – registrované osoby na určité akce. Každá registrace má vygenerovaný variabilní symbol a částku, kterou má zaplatit.
Každá registrace má přiřazen stav platby (cizí klíč do tabulky stavů platby). Po zaregistrování na akci je registrace ve stavu UNPAID (nezaplacená).
A teď samotný proces párování plateb z účtu. Plánuji použít nějaký princip pravidelně spuštěného tasku (myslím, že v Kdyby na to něco je).
Task bude dělat následující:

  1. Stáhne pohyby na účtu za poslední hodinu.
  2. Vytáhne si všechny registrace, které jsou na následující akce (akce konající se v budoucnu), a které jsou ve stavu UNPAID.
  3. Postupně iteruje nad pohyby na účtu (z JSONu z FIO API) a provádí s nimi následující

V každé iteraci (pro každý pohyb na účtu)

  1. Porovná variabilní symbol záznamu a pohybu
  2. Pokud VS souhlasí, tak porovná částku, zaokrouhlenou na celé koruny
  3. Pokud i částka souhlasí, tak označí záznam jako zaplacen (přiřadí mu stav PAID) a uloží jej do DB, zároveň také uloží data o pohybu do DB pro zpětnou informaci o platbě (speciálně určená tabulka, pro uložení prakticky stejných informací k transakci, které přijdou z API)
  4. Pokud částka nesouhlasí (souhlasí jen VS), tak označí záznam jako kolizní (přiřadí mu stav COLISION) a uloží jej do DB, zároveň také uloží data o pohybu do DB pro zpětnou informaci o platbě

A nakonec tasku (až projede všechny pohyby z JSONu)

  1. Uloží informaci do DB o svém průběhu (tasku) – kolik záznamů spárováno úspěšně, kolik v kolizi a kolik nespárováno vůbec

Díky za každý podnět.
Až toto řešení naimplementuju a vzpomenu si, tak sem připíšu nějaké zpětné zhodnocení tohoto procesu.
(Kdybych si nevzpomněl a nepřipsal to sem, a někdo to chtěl vědět, tak mi napište ;))

jiri.pudil
Nette Blogger | 1028
+
+2
-

Ahoj,

řešili jsme úplně stejný problém a vyřešili jsme ho hodně podobně tomu, co popisuješ.

Použili jsme https://github.com/…/fio-api-php, kde jsem doimplementoval podporu pro endpointy /last a /set-last-id, takže si identifikátor poslední zpracované transakce drží a řeší sama aplikace. Máme to obalené symfony/console commandem, který pouštíme každou půlhodinu pomocí cronu.

ales.k
Člen | 6
+
0
-

jiri.pudil napsal(a):

Ahoj,

řešili jsme úplně stejný problém a vyřešili jsme ho hodně podobně tomu, co popisuješ.

Použili jsme https://github.com/…/fio-api-php, kde jsem doimplementoval podporu pro endpointy /last a /set-last-id, takže si identifikátor poslední zpracované transakce drží a řeší sama aplikace. Máme to obalené symfony/console commandem, který pouštíme každou půlhodinu pomocí cronu.

Jirko, na co přesně jsou prosím tě ty endpointy last a set-last-id? Jak to zapadá do toho procesu? Díky.

jiri.pudil
Nette Blogger | 1028
+
+1
-

To je k bodu 3 – „postupně iteruje nad pohyby na účtu“. Aplikace načítá jen dosud nezpracované transakce (/last) a po úspěšném zpracování nastavuje ID poslední zpracované transakce (/set-last-id), od které se pak zase budou načítat v dalším běhu.