Payment status is not getting updted in case of order failure

[V]

Hi,
There is a payment auth issue here at my client. If the order fails
due to failure of some of the component in the commerce pipeline, the
payment auth is not saved to dcspp_pay_status table.
And if in this scenario, user clicks place order again after seeing
the failure texts on the screen, there is another new payment auth
happening. We wanted to place the logic of checking the order and
prior payment auth to avoid multiple payment auth for the same order
and order amount less than or equal to the previous auth amount. But
when we are checking the payment auth for the order, it comes as a
null value.
Just wondering why the earlier payment auth was not saved to
dcspp_pay_status table. Can someone please let me know how we should
get the previous auth info for the order?
One solution is to use a session component and store the payment auth
info for the same user session and check it before going for the next
auth. But this solution is limited to only for the session. We are
looking for resolving this issue for the order irrespective for user
session.

Thanks,
~Veerendra

[O'Brien, Paul]

It's because the processOrder pipeline makes other changes to the order
before doing the authorization. Since the order isn't going through, it
needs to roll back those other changes, which results in a rollback of
the payment status. If you call PaymentManager.authorize() directly,
the payment statuses will remain on the payment group. I suggest you
write a processor that calls PaymentManager.authorize() directly, and
put that processor at the head of a pipeline chain. This processor can
return STOP_CHAIN_EXECUTION_AND_COMMIT if there is an authorization
failure, which will halt execution of the chain, but will not roll back
the payment status objects.

[V]

If the other processor down the line in the pipeline chain throws
exception, the transaction gets rolled back.

Also I tried with new transaction to call updateOrder in the
authorizeComponent, db update happens properly but in the
commitFormHandler, there is an updateOrder which fails with following
message:

CONTAINER:atg.commerce.CommerceException;
SOURCE:CONTAINER:atg.service.pipeline.RunProcessException: An
exception was thrown from the context of the link named
[addOrderToRepository].;
SOURCE:atg.commerce.order.InvalidVersionException: This order
(o0000000001010792450) is out of date. Changes have been made to the
order and the operation should be resubmitted. Order version 13,
Repository item version 11.

I would like to update payment authorization irrespective of any
failure in processOrder pipeline chain.

> ~Veerendra- Hide quoted text -
>
> - Show quoted text -

[Nooruddin Shaik]

If you have any exceptions in updateOder pipeline chain and commit
happens on dcspp_order table then you will see this error when next
updateOrder() is called.

The order repositoyitem version is incremented for any update queries
on dcspp_order table.
After successful completiion of updateOrder pipeline chain the
order.version is updated with the version of order repositoryItem.

Becoz of the rollback in your case the order.version is not updated
from order repositoryItem.

So explicitly call order.updateversion() in your customized processor
to avoid this.
This is not a hack as you are expecting to update the DB even after rollback.

Thanks
Shaik

[lokivog]

The problem with this is the whole version designed system. Even if
you were to follow the best practices of updating an order, somehow
you will still see orders fail sporadically in the commerce pipeline
because of the InvalidVersion exception. Also, this problem
dramatically increases in the fulfillment pipeline. I have seen this
on every project I have worked on.

Yes you could call update version on the order but a lot of the times
I have seen exceptions that specify the payment groups are out of
version (using OOTB cybersource processor) and there is no way to
explicitly call update version on a payment group. Without ranting on
about the version designed system, which I could all day, I have a
solution I have found that works pretty well if you would like to try
it.

- First you create a new table that is essentially a replica of the
credit card status table. It will contain a column for the payment
group id and columns for every property on your credit card status
object. This table represents an audit table for your credit card
status.
- Then you will need to override the authorize method of your
CreditCardProcessor class.
- Immediately after the authorization is received from the 3rd party
processor or gateway, you save the values in the authorization status
to your new audit table. You need to do this in a new transaction
with mode RequiresNew. This suspends the current transaction and
guarantees that the new entry is saved in your audit table.
- Now that you have audit records of your authorization statuses, you
will need to put a check in right before the call is made to the
gateway to see if the audit record exists.
- If it does exist and because the CreditCardStatus is an object, you
can now create the CreditCardStatus object using the values in your
audit table.

Here is the process flow when an order is submitted
Transaction 1 begins
1. Order state updated to SUBMITTED
2. Order is validated and runs through the processOrder pipeline
3. Order reaches authorize payment pipeline
4. Check to see if Cybersource response already exists
a. if true
i. Create Cybersource status from existing response.
ii. continue to 7
b. if false continue to 5
5. Order is sent to Cybersource for authorization
6. Authorization received from Cybersource
a. Transaction 1 suspended
i.
Transaction 2 begin
ii.
Save Cybersource authorization to audit table
iii.
Transaction 2 commit
b. Transaction 1 resume
7. Pay state updated to Authorized
8. Finish processOrder pipeline.
9. Update order.
10. Commit transaction 1.


Using this solution allows you to maintain the natural flow of the
pipelines and default behavior of submitting an order. Please note
that the same concept will apply to debiting the credit card in the
fulfillment pipeline which is actually more important then the
authorization. This is because a lot of credit card processors,
paymentech for instance, allow multiple debits per authorization and
they do not decline debits over the authorized amount.

Michael

[kathir muruges]

Hi Guys,
              Here i created a new payment integration. I can successfully add the new payment group in current order but i did not authorize the order amount and paymentGroupDroplet initializer error...