Obecný princip automatického párování plateb s účtem u FIO
- ales.k
- Člen | 6
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í:
- Stáhne pohyby na účtu za poslední hodinu.
- 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.
- 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)
- Porovná variabilní symbol záznamu a pohybu
- Pokud VS souhlasí, tak porovná částku, zaokrouhlenou na celé koruny
- 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)
- 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)
- 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 | 1032
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
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 | 1032
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.