Hello, I wanted to paste here an extract from my submission to the Hack the Galaxy hackathon that might be useful for new fintech developers.
Even tho is related specifically to the issue of refunding a transaction to a VA, it is a result of a broader approach to fintech development in which you keep a local copy of each API asset, users, transactions, beneficiaries, etc, after every synchronous call or using webhooks for asynchronous events like bank deposits. It’s a heck of a lot of work doing this, BUT, for complex large fintech applications, it’s a good investment for the future since it becomes a time saver. (Been here for the past 10 years 
)
This is the extract:
The complexity of making a refund for a pay-in to a VA is that you do not refund the sums to the source like in any regular refund, since the source is a virtual/real bank account not owned by the payer.
So you need to do a new bank wire to the payer using their bank account details, BUT ALSO, you need to keep track of the fact you refunded the transaction, by linking the original transaction to the new refund bank wire. You can use the metadata field of the original transaction to keep track of this, but the listing endpoint of the transactions directed to a VA does not include the metadata field, so in order to list the transactions that have been refunded using this method, obligates you to make a get request for each transaction to the transaction details endpoint, extremely inefficient if you have hundreds of payments.
In order to fix this, we decided to make a local copy of the transactions to manage a custom state, so we can keep track of what transaction was refunded for ease of use. This increments the complexity, having to manage the webhook for new deposits and a DB for persistence, but it also improves the admin panel speed since fewer calls to the Rapyd API are needed.