Payment stuck at depositing when less than full amount is captured.

[calumbrodie]

The issue I'm having relates to partial deposits and refunds. What I've found is that if I approve a certain amount during the approve stage (say $100), but then I come to capture the money (make the deposit) and I decide that I only want to capture a portion of this amount (customer orders 3 items, 1 is out of stock) - say $80...

What happens is that the payment state is now stuck at 'depositing', because the deposited amount does not equal the amount initially captured.

Line 645 of https://github.com/schmittjoh/JMSPaymentCoreBundle/blob/master/PluginController/PluginController.php

$changePaymentState = Number::compare($depositedAmount, $payment->getApprovedAmount()) >= 0;
if ($changePaymentState) {
    $payment->setState(PaymentInterface::STATE_DEPOSITED);
}

I can see why this check is important but it does cause issues when later trying to issue a credit on this payment (It won't issue a credit on a payment which is stuck at depositing).

Options would be to:

• Change this check to simply test if the deposited amount is > 0
• Make the deposit with an additional flag which forces the state change (this would modify the payment plugin interface, but not in a way which is backwardly incompatible), for those payment processors that allow partial deposits but don't allow subsequent deposits (so you can use the token for a single deposit event). This pattern is common in my experience
• We can fudge it in our calling code by manually forcing the payment into the deposited state after we are done with our deposit.

I guess the main question here is what the DEPOSITED state should denote. Should it mean

• all the money that is available to capture - has been captured
• the first attempt you made to deposit funds on this payment was successful' (regardless of the amount you attempted to deposit)
• some money was successfully deposited'

[schmittjoh]

As for the meaning of DEPOSITED, I think we need to leave the meaning at "the requested amount has been captured/deposited".

When you say "issue a credit", are you talking about actually transferring money, or just about releasing some of the authorized funds (which have not actually been transferred to you)?

As for issuing credits, I think it would make sense to also allow credits on payments where some partial amounts have been deposited.

[calumbrodie]

I mean returning (refunding) funds that we have already captured, rather than a reverse approval (releasing the approved amount without depositing it). So a DependentCredit.

This cannot happen when the state is still at 'depositing' (nor can it while 'deposited' in fact), so I suppose this issue is related to #35 and perhaps #11

Feel free to close this as I don't have a specific bug - but I think the state machine (and particularly the state that payments 'finish' in) may need to be clarified/worked out and it will solve a few of these issues. We will spend some time on this (we are planning to make our payment plugins available) and take a look at the websphere documentation too.