On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <andreas@schildbach.de> wrote:

However, I don't see how PaymentDetails can be an answer. None of the
fields (other than outputs and network) can be known in advance (at the
time of the initial payment).

You don't need all the fields indeed, but they're mostly optional (except time). So for the refund you'd fill out:

outputs (same as today)

time

expiry_time

You're probably aiming for an expires field? How would you refund a
payment after expiry?

It'd have to be ad-hoc at that point. OK, you don't get the nice UI that the refund field provides. Oh well. It should be rare to get refunds very very late after the purchase.

Btw. another problem is that the refund address is currently unprotected.

Yes indeed as is the rest of the Payment structure. We talked about signing it with one of the keys that's signing the Bitcoin transaction as well. But it seems like a bit overkill. Usually it'll be submitted over HTTPS or a (secured!) Bluetooth channel though so tampering with it should not be possible.

However this does raise the question of whether a refund should be a full blown PaymentRequest with optional PKI signing. Normally, I think, a seller does not know or care about the identity of a buyer for refunds, outside of their own tracking system.