Wrong state of Payment after approveAndDeposit

[phiamo]

Hi,
i am using approveAndDeposit, and it works like a charm except for the payment status afterwards.

Money is beeing approved and deposited but state is STATE_APPROVED

i think thats due to
https://github.com/schmittjoh/JMSPaymentCoreBundle/blob/master/PluginController/PluginController.php#L331

musnt that be STATE_DEPOSITED?

as far as i understood state transition is to APPROVED after approving and DEPOSITED after succ depositing or?
since its done in one flow with approveAndDeposit i would assume to have state DEPOSITED afterwards ?

cheers phil

[schmittjoh]

I need to think more about this, but it's the same in websphere.

see http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/topic/com.ibm.commerce.api.doc/com/ibm/commerce/payments/plugincontroller/PaymentsInterface.html#approveAndDeposit(com.ibm.commerce.edp.api.PaymentContext,%20java.lang.String,%20java.math.BigDecimal)

[phiamo]

indeet i see ..
its not really a prob i just came over it when dispayling states and saw it was different than when doing approve and deposit in a two stage process ...
anyways, have you any other payment systems already build based on coreBundle?
We are currently discussing if we should start over with sofortüberweisung and publish it, or if we wait until we got some other specs from another major payment provider which might be an alternative for us.

anyways tnx a lot!

[schmittjoh]

I only use PayPal at the moment.

[ebernhardson]

This was closed as a 'works as intended', with the link to the web sphere docs. I can't find anything in the linked websphere doc about STATE_DEPOSITED or STATE_DEPOSITING.

For example, doDeposit in the php PluginController switches the payment from STATE_APPROVED to STATE_DEPOSITING before running the inner plugin action. Then if the resulting processed amount, plus any previously deposited amount, equals the payments approved amount after a successfull response it transitions again to STATE_DEPOSITED

compare to the linked websphere docs for doDeposit:

PPC makes sure that:

PaymentInstruction is in STATE_VALID
Payment is in STATE_APPROVED
there is enough approved amount in Payment to be deposited
there is no pending transaction against the same PaymentInstruction
The PPC will:

set depositing amount in Payment
increase depositing amount in PaymentInstruction
delegate the request to the target plug-in
On successful transaction response, PPC will:

reset Payment depositing amount by the requested amount
decrease depositing amount in the PaymentInstruction by the requested amount
update Payment deposited amount by the actual processed amount

Basically, i'm trying to figure out how STATE_DEPOSITED fits into the system. Its referenced exactly one time outside of a test case, and once a payment gets into STATE_DEPOSITED its no longer possible to reverse it, because reverseDeposit requires the payment to be STATE_APPROVED, not STATE_DEPOSITED.

[ebernhardson]

This is additionally shown in the 'state machine' graph provided by ibm: http://i.imgur.com/1mp8t.png

[schmittjoh]

This seems like an inconsistency to me.

We probably need to adjust the state after the approveAndDeposit method to DEPOSITED, and also the state that is required by the reverseDeposit method.

DEPOSITING was introduced to allow a PENDING transaction to complete successfully. For example, after the user has done something (visited an URL, etc.).

[ebernhardson]

That makes sense.

I will write and test a patch along that line of thought this week.

[schmittjoh]

We have a related problem in #34

[marcospassos]

@schmittjoh, any news? I belive this is crucial for all of us.

[schmittjoh]

I think no-one is working on this atm, so you could write up a patch if you like.

[marcospassos]

I'll work on it then. Thanks!