As reported in the 3D Secure module here:

http://drupal.org/node/1312188

CommentFileSizeAuthor
#13 3d_secure_loop-1679828-12.patch600 bytespq
#3 checkout.jpg42.66 KBkevster
#1 3d_secure_loop-1679828.patch948 bytesikos

Comments

ikos’s picture

ikos commented
Assigned: ikos » Unassigned
Status: Active » Needs review
StatusFileSize
new 3d_secure_loop-1679828.patch948 bytes

Patch attached that resolves the looping problem by correctly setting the checkout status.

kevster’s picture

kevster commented

Hi Richard - many thx for putting the patch up - will grab it now and apply...

Thx - Kevin

kevster’s picture

kevster commented
StatusFileSize
new checkout.jpg42.66 KB

Just tested in a live environment but Im still stuck on the 3d secure page.

I put my 3d secure password in and that passes ok - I can see the browser path trying to do something (chrome bottom left) but then nothing happens and Im not redirected. I also see a 3d secure proceed button below and outside the 3d iframe window - not sure that that should be there as I would have thought that clicking on the submit button within the 3d secure iframe would be enough to move on to the next stage (providing 3d passes)?

Using this default rule for 3d secure under sagepay direct:
If 3D-Secure checks are possible and rules allow, perform the checks and apply the authorisation rules (default)

Attached checkout panes screen (ignore not saved status on 3d secure pane)

Nothing in the recent log, I will do some more testing and turn on more error logging..

UPDATE:
Apologies Richard - reuploaded patched file and all worked ok so looks to be fixed - many thx..

Thx - Kevin

ikos’s picture

ikos commented

Hi Kevin,

The only difference I can see with my setup is that I have disabled the offsite payment redirect pane in the checkout setup.

Can you try the same and see if it gets you past that step?

many thanks

Richard

kevster’s picture

kevster commented

Its working ok I think.

I just need to add another rule so that when it gets pushed into checkout:checkout completed it then moves it to pending:pending which fires our email confirmation to customer and admin - this is how it works on our shop without the 3d secure.

We have the offsite payment because of the paypal payment option, not needed for the pagepay direct option...

Anonymous’s picture

Anonymous (not verified) commented

Unfortunately the patch in #1 does not solve the problem for me, using the Sage Pay Simulator. Any ideas why this might be? I also have the "Off-site payment redirect" checkout pane, and if I try and disable it, I get this warning (and then it gets put back where it was):

Off-site payment redirect is locked in the code to the Payment page and was repositioned accordingly.

I also don't understand the need for the "Proceed with 3D Secure Authentication" button on the 3D Secure Authentication page - why do you need a button outside of the iframe?

Anonymous’s picture

Anonymous (not verified) commented

Ok I've realised that my problem is that after doing the 3D Secure authentication, when I POST the MD and PARes to Sage Pay, the Simulator is returning the following:

status=INVALID

transaction_status_message=Simulator cannot find your vendor name. Ensure you have have supplied a Vendor field with your Vendor name assigned to it.

After looking at the Direct integration guidelines PDF, on p15 it says that you should only need to POST those 2 variables and Sage Pay should be able to use them to retrieve the transaction details you originally provided... So I'm not sure what the problem is - maybe it is just something weird with the Simulator. I will try and contact Sage Pay about it, and will be sure to post back here what I find out.

UPDATE: I've realised that SP is actually processing the transaction (it appears in the Simulator's transaction list) when the user first submits their card details, before the user even sees the 3D Secure iframe and authenticates there... so this must be the problem - the transaction is already finished, so when the user does complete the 3D Secure authentication, and we try to finish the transaction with SP, they reject it! I've posted a support request with SP about this.

PS. a suggestion for the commerce_sagepay_direct_3d_secure_callback() function, and the $post variable:

$post .= '&PARes=' . urlencode($pares);

I.e. the integration guidelines say the variable should be called PARes with an uppercase 'a' when being POSTed back to Sage Pay, and also that you should encode the value. This is also how it is in Sage Pay's example Direct PHP implementation code.

Anonymous’s picture

Anonymous (not verified) commented

Ok my issue was completely unrelated, sorry! The problem I was having was specific to the Sage Pay Simulator: #1697568: Missing 3D Secure Callback URL for Simulation mode. I'm afraid I don't have a Sage Pay test account yet, so cannot test ikos's patch in #1.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs review » Reviewed & tested by the community

Got myself a shiny new test account! I can confirm that I was indeed stuck in a loop until I applied ikos's patch and then it worked.

kingandy’s picture

kingandy
he/him
commented

This patch is missing a call to commerce_checkout_complete($order); line. Though this is probably unrelated to the infinite loop issue, it will prevent the "Completing the checkout process" event from firing (see #1538348: "Completing the checkout process" isn't firing in rules.).

The line can be added immediately after the call to commerce_order_status_update().

pq’s picture

pq commented
Status: Reviewed & tested by the community » Needs work

I've had to apply this patch due to getting the looping 3D Secure issues, however it seems to cause a new issue, whereby it sets the order status to checkout_complete after all the events 'When an order is first paid in full' and 'Completing the checkout process', so where typically there may be a rule that sets the order status to 'Pending' or 'Completed', on finalising the order, this code will run afterwards and reset it to checkout_complete.

The main visible effect is that the order still appears in 'Shopping carts' instead of 'Orders' in the UI, but also causes issues with integration with fulfilment software etc.

kingandy’s picture

kingandy
he/him
commented

It might be worth switching to the new Commerce Sagepay module. Ikos have rolled all the separate payment methods (Direct, Server, Form) into a single package which addresses a lot of the patches from the issue queue - I don't know if this one is included but it would be worth a look.

pq’s picture

pq commented
Status: Needs work » Needs review
StatusFileSize
new 3d_secure_loop-1679828-12.patch600 bytes

I'm not sure if this is the right way to go about it but here's a patch that adds a commerce_checkout_complete($order); at the end of the success clause.

nb. the patch at #1538348: "Completing the checkout process" isn't firing in rules. unfortunately causes the same issue since that saves the order before resetting the status as well. I'll cross-post there.

pq’s picture

pq commented

Hi @kingandy, sound's like a sensible idea, but in this case it's the eleventh hour before a site launch and the gateway process has been hooked into and customised significantly, so changing gateway at this stage would cause a lot of disruption. I will definitely go straight to Commerce Sagepay for future development though.