| 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... | |
| Better to show the refund amount specified by the merchant, by coins too confusing For each event in the timeline, we need a better description. Name for states of refund proposed in related bug 0010695 | |
| the SPA was already merging but the refunded list is returned with a wired order of the items, I expected this to be order by time (asc or desc) ordering on the spa after 50f768fa601e4a891cecd122687553fe89a72606 | |
- Anonymous