Delay generating an unpaid response for redemption requests for unpaid vouchers

While there may be some client-side improvements that can be made, the payment server may be able to contribute to an improved experience here as well.

If the server receives a redemption request for a voucher which has not yet been paid for, it could hold onto the request for a while. If payment arrives within a few minutes, as it typically will, then the server can immediately allow redemption to succeed - preventing the client from ever seeing an error response and having to invoke its delay and retry logic.

If the success response is triggered immediately on the arrival of payment notification then this can also provide the shortest possible turn-around for delivering ZKAPs to the client (within the current architecture, anyway). There is no way the client could time a redemption request so as to receive the ZKAPs faster. At best it could issue its request so it arrives instantly after payment information has been committed to the database - but it has no way to know when this is.

This can probably drive the perceived time-to-completion for payment down to near zero (based on recent measurements of how long different parts of the redemption process takes, the client might end up with tokens one or two seconds after the payment page shows the success response to the user).