user78: I want to write code that accepts a transaction, and afterwards "pays back" some amount to the origin of the transaction.
Assume users will be using the standard client. Will transactions have a single input, or must I handle the situation where a transaction have multiple inputs?
Can I just choose one of these inputs and pay back to that input? I want to avoid having to request users from entering a payout Bitcoin address - it's so much neater to just pay back to the same address they used.

user323: As any user can easily receive Bitcoins with multiple addresses, the transactions they send can have multiple inputs. There are a couple cases you should consider:

Single input, single output - easy case, send coins back to the input (unless some prankster mines coins onto your address, then you might as well keep them instead of sending them to some invalid address)
Any number of inputs, two outputs - the second output is probably where the user has sent its remaining coins, you might as well send them there (although you should explain it to the users first)
Multiple inputs, single output - you probably should provide the users with two functionalities - either sending coins to the first input, or sending the same amount of coins got from each input into each of them
Multiple inputs, multiple outputs - probably should work as the previous case

All in all, you should provide users with different functionalities, probably each using a different address for their transactions and see which are used more often.

user575: Assuming that the user uses the standard client, or in fact any client, is a very strong assumption. If the user is using an eWallet service such as Instawallet, in all likelihood the user will not get the funds back, they will be held by the operator and possibly credited to one of his other clients.
Even if the input addresses are controlled in some way by the user, paying back to one of them can cause confusion regarding the payment's source - it will look as if the payment was for whatever the address was originally associated with. If there is a change address controlled by the user, it is associated uniquely with the payment to you so the information exists to identify it, though the client may not display it properly.

78: <p>I want to write code that accepts a transaction, and afterwards "pays back" some amount to the origin of the transaction.</p>

<p>Assume users will be using the standard client. Will transactions have a single input, or must I handle the situation where a transaction have multiple inputs?</p>

<p>Can I just choose one of these inputs and pay back to that input? I want to avoid having to request users from entering a payout Bitcoin address - it's so much neater to just pay back to the same address they used.</p>
 323: <p>As any user can easily receive Bitcoins with multiple addresses, the transactions they send can have multiple inputs. There are a couple cases you should consider:</p>

<ul>
<li>Single input, single output - easy case, send coins back to the input (unless some prankster mines coins onto your address, then you might as well keep them instead of sending them to some invalid address)</li>
<li>Any number of inputs, two outputs - the second output is probably where the user has sent its remaining coins, you might as well send them there (although you should explain it to the users first)</li>
<li>Multiple inputs, single output - you probably should provide the users with two functionalities - either sending coins to the first input, or sending the same amount of coins got from each input into each of them</li>
<li>Multiple inputs, multiple outputs - probably should work as the previous case</li>
</ul>

<p>All in all, you should provide users with different functionalities, probably each using a different address for their transactions and see which are used more often.</p>
 575: <p>Assuming that the user uses the standard client, or in fact any client, is a very strong assumption. If the user is using an eWallet service such as Instawallet, in all likelihood the user will not get the funds back, they will be held by the operator and possibly credited to one of his other clients.</p>

<p>Even if the input addresses are controlled in some way by the user, paying back to one of them can cause confusion regarding the payment's source - it will look as if the payment was for whatever the address was originally associated with. If there is a change address controlled by the user, it is associated uniquely with the payment to you so the information exists to identify it, though the client may not display it properly.</p>
