How to process refunds and ensure that after a crash you don't resend to someone?

I want to have a server running that will be processing payments and refunds. However, I also want to ensure that should my server die, that after a restart I will continue sending out any applicable refunds without sending a refund to someone I have already sent one too. I plan on using a WAL to achieve this, but I need to know what to store in the WAL. Is it possible to know your transaction ID before submitting the transaction?

That way I could just log the ID before submitting, and if I crash, I can just check the blockchain to see if that transaction already exists or not.

This seems like it would be a common problem for payment processors, but looking at the JSON-RPC documentation it appears that you only ever get the transaction ID after submitting the sendfrom/sendtoaddress.

senecaso

Posted 2013-06-13T11:29:18.143

Reputation: 139

I suspect this can be achieved by creating a raw tx, then storing that in the WAL before attempting to send the tx. Then, after a crash, I can verify which transactions are in the blockchain and which aren't, but I dont know if this is the best way or not. – senecaso – 2013-06-13T13:21:32.900

Answers

You can check blockchain for the latest transactions of the address you are using for refunds.

Get the latest transactions of the address from the blockchain and compare those to the refunds in your system to see which ones you were able to send and which ones you weren't before the crash.

Emre Kenci

Posted 2013-06-13T11:29:18.143

Reputation: 3 008

1But I need a way to uniquely identify a refund. Address+amount isn't necessarily unique, so I have no way of knowing which transactions from the blockchain match to which transactions in my outgoing queue. Am I missing something? – senecaso – 2013-06-13T13:20:24.167

No you're right. Note that this is a really extreme case. You need to have sent the coins and before you can save the transaction on your db the machine needs to crash. Checking the address works but you need to use a unique address for each refund. – Emre Kenci – 2013-06-13T13:37:58.907

1Using a unique address is an interesting idea, however, how long do you wait after a crash to determine if a transaction ends up on the blockchain or not? You could very easily end up retransmitting due to a hiccup in the transactions processing (or my network connection). As I said above, I suspect the only safe way to do this is to store the signed raw tx in the WAL before sending and then replay it after a crash. That way the bitcoin network prevents the double spend for me. However, I'm not convinced there isnt an easier/cleaner way to do it. – senecaso – 2013-06-13T14:38:25.197

@senecaso The transaction id is always unique, you could use that. – Nick ODell – 2013-06-13T18:46:46.340

You could do this by chaining the refund and the transaction that you received. This way you could issue the refund as often as your system crashes without incurring the risk of returning more than you need. This is a bit tricky and you need to use the API from bitcoind but SatoshiDice has been using it successfully to return winnings. What you do is take the output that was sent to you and spend it in a transaction that refunds the sender. Since an output can be claimed at most once, the refund will be sent only once.

cdecker

Posted 2013-06-13T11:29:18.143

Reputation: 7 878