<p>You can check blockchain for the latest transactions of the address you are using for refunds.</p>

<p>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.</p>

CC BY-SA 3.0
2013-06-13T13:20:24.167Z
But 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
CC BY-SA 3.0
2013-06-13T13:37:58.907Z
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 K.
CC BY-SA 3.0
2013-06-13T14:38:25.197Z
Using 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
CC BY-SA 3.0
2013-06-13T18:46:46.340Z
@senecaso The transaction id is always unique, you could use that.
Nick ODell
CC BY-SA 3.0
2013-06-13T12:33:30.740Z
2013-06-13T12:33:30.740Z
Emre K.
<p>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 <code>bitcoind</code> 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.</p>

CC BY-SA 3.0
2013-07-17T07:29:49.433Z
2013-07-17T07:29:49.433Z
cdecker
<p>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? </p>

<p>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.</p>

<p>This seems like it would be a common problem for payment processors, but looking at the <a href="https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list" rel="nofollow">JSON-RPC</a> documentation it appears that you only ever get the transaction ID after submitting the sendfrom/sendtoaddress.</p>

CC BY-SA 3.0
2013-06-13T13:21:32.900Z
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
<transactions><blockchain><json-rpc><payment-processors>
How to process refunds and ensure that after a crash you don't resend to someone?
senecaso
# How to process refunds and ensure that after a crash you don't resend to someone?

(Asked by: username_0 on 2013-06-13)

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](https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list) documentation it appears that you only ever get the transaction ID after submitting the sendfrom/sendtoaddress.

**Tags:** transactions, blockchain, json-rpc, payment-processors

> **Comments:**
> **username_0**: 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.  

---

## 2 answers

### Answer by username_1 on 2013-06-13. Score: 2

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.

> **Comments:**
> **username_0**: But 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?  
> **username_1**: 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.  
> **username_0**: Using 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.  
> **username_2**: @username_0 The transaction id is always unique, you could use that.  

---

### Answer by username_3 on 2013-07-17. Score: 0

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.


---

