Now at startup, the daemon runs through all unpaid orders ever created in the background and checks their balances. Accordingly, I moved this logic from the scanner loop there.
The only problem is with the current refund algorithm in the scanner, which previously only issued a refund if a) the order was unpaid, b) the surplus was only in the first transfer. Now the scanner has no information about whether the order was paid before the block being scanned or after, as this happens in a different cycle and is not stored in the database in any way.
As a result, the return of the surplus now occurs every time the order account receives an amount greater than its payment price, regardless of whether it is paid or not
Now at startup, the daemon runs through all unpaid orders ever created in the background and checks their balances. Accordingly, I moved this logic from the scanner loop there. The only problem is with the current refund algorithm in the scanner, which previously only issued a refund if a) the order was unpaid, b) the surplus was only in the first transfer. Now the scanner has no information about whether the order was paid before the block being scanned or after, as this happens in a different cycle and is not stored in the database in any way. As a result, the return of the surplus now occurs every time the order account receives an amount greater than its payment price, regardless of whether it is paid or not