Create a proposal with a max price N, say N = 10 GBP.
Back it for 1 product.
Close it.
Process payments.
Expected result: pledge payment of 0.5 GBP taken. On process payment, refund of 0.5 GBP paid because no deal.
Result: the 0.5 GBP will be in escrow forever. The payout functionality is dependent on the start payment being paid, and there's no current handling of a refund.
Strategy to solve: drop requirement of start payment > 0 to execute a refund; implement refund.
In the contract, for each consecutive payment there's a check for the previous one. For the end payment of a backer it looks like this:
else if (paymentType == 3) {
// End payment
// Validate that start payment was registered
if(b.startPaymentAmount == 0) return;
// Can only register once
if(b.endPaymentAmount != 0) return;
// Validate correct amount
if(amount != getEndPaymentAmount(backerIndex))
return;
b.endPaymentTransactionID = transactionID;
b.endPaymentAmount = amount;
}
We could add an explicit case for "has accepted offer" && "is closed" in which case an end payment should always be executed. In that case a refund. Also, implement a test to handle this case.
Steps:
Expected result: pledge payment of 0.5 GBP taken. On process payment, refund of 0.5 GBP paid because no deal.
Result: the 0.5 GBP will be in escrow forever. The payout functionality is dependent on the start payment being paid, and there's no current handling of a refund.
Strategy to solve: drop requirement of start payment > 0 to execute a refund; implement refund.
In the contract, for each consecutive payment there's a check for the previous one. For the end payment of a backer it looks like this:
We could add an explicit case for "has accepted offer" && "is closed" in which case an end payment should always be executed. In that case a refund. Also, implement a test to handle this case.