|
|
That's correct. Refund_pending = false means that the wallet *did* get the refund. The point is that here now "wired = true", and that means that any pending refund can no longer succeed. So you do need to consider all the bits in combination: if refund_pending = true *and* wired = true, it means the wallet will never get it. |
|
|
This is, however, something the SPA needs to show nicely, so for example no longer showing the refund as "pending" but as "failed". |
|
|
This is how it looks when a merchant 1) create an order of KUDOS 3 2) merchant refund KUDOS 1 3) customer takes the refund 4) merchant refund KUDOS 1 5) customer DON'T take the last refund 6) wire transfer deadline passes I think is clear that the first one was taken in the UI, the second one didn't, the wiredeadline passed. The refund URI is not shown anymore. The merchant backend reports KUDOS:0.4 and KUDOS:0.6 which I think is wrong (!) because the merchant specified KUDOS:1 and I think this is a details of the coins used by the wallet should not be relevant here and backend should return KUDOS:1 image.png (86,389 bytes) |
|
|
i think the spa is ok and backend should not return refund by coin |
|
|
Well, customer/protocol picks up refunds by coin, so little choice there in terms of data model. But SPA could reconcile, maybe? |
|
|
Let's see if Vlada has good design ideas here... |
- Anonymous
