This is by design. Returning the crypto amount would not make sense. Imagine a crypto that suddently spikes 50%, all your users with pending orders would suddenly be incentivised to request refunds on that day.
If you are running a legitimate business, in terms of accounting, you immediately convert any crypto you receive to whatever currency you are paying your taxes with. You want to be hedged against crypto volatility. A business is not a place to speculate with price movements or expose yourself to price risk. If you want to do that, go to an exchange and start trading, but that shouldn’t have anything to do with your s-shop or other businesses. Crypto is used as a medium of exchange here. Shop prices should be set in fiat currencies.
Again, in a normal situation you would have more funds in your admin account so that you can pay out more crypto if the crypto value goes up, and less if it goes down. This will average out over time.
Hope this makes sense.
If you really need to refund the original amount, you can always mark the order as cancelled, and go to the transactions list and cancel the internal transfer. But there is no legitimate situation where you would want to do this.
Therefore, this calculation is not the problem. The problem is that in some situations the method is not being triggered (e.g. with auto commissions, or other edge cases) If there was a clear API on how to hook to the plugin to create a payout payment gateway, these problems would not exist. But the plugin is too closely tied with paypal and there is no sufficient decoupling of payout methods to the multivendor plugin, hence the need for the DB hacks you see in the code.
with regards