Since we’re all aware that it’s impossible to trust Ledger to actually notify our canister about received payments 100% of the time, there’s a huge issue of possible “refunds” an app would have to make to everyone who sent ICP to it and did not get whatever they bought with that ICP credited due to the above.
I was thinking of how this might be handled to go around refunds and would like to know if this would be a viable thing to do to counter this problem:
- We still use notify from ICP ledger to get customers what they paid for and act like this will work 100% of the time (even though it wont)
- Instead of having refunds option (that is a pain on it’s own to implement and deal with) and to also go around the issue of having to use heartbeat (which costs a lot), we create some kind of a web2 app that is only accessible to admins of the ICP app.
- This web2 app would either via CRON jobs or manually allow calling the
notify_dfxto the ledger canister for all of the payment transfers that occurred in the last 24h (since ledger invalidates tx’s after 24h I believe) and just resends thenotify_dfxcall for each of those (so if the Ledger did not send the notification properly to our canister, this would actually fix it for the ones that did not run the first time and we can then assign customers whatever they have paid for). - In web3 frontend of the app, we also ping the API endpoint of our web2 app every time a tx is sent, sending it the timestamp of it (so we know the time of the tx which we use in the “last 24h check”) and the block number that Ledger gives back to us after
transfer_dfxresponse is back.
Is this viable or not?