First off, sorry for all the bug reports!!

Please also forgive me if I explain this poorly. I'm pretty good at figuring things out but I'm not a very experienced developer.

I've been trying to update Commerce Hosted PCI to work with Commerce Card on File 7.x-2.x in order to use rules to charge recurring payments (with hopes of contributing it back, maybe as a 2.x branch). I've run into an issue that I also noticed when I first set up Commerce Hosted PCI but didn't fully explore until now. If you have multiple payment options (for instance Check / Credit Card / Cash), it (obviously) loads the payment form for each payment type through an ajax call. Tha ajax call updates window.location() to "system/ajax" instead of the url of the checkout page (on our site it is "checkout/(order_id)/review") which breaks the js that HostedPCI uses to submit the data in the iFrame and get the response back, I believe because jquery.ba-postmessage uses window.location.

I got around this originally (sort of) by making HostedPCI as the default payment option which loads the credit card form with the page load and there are no issues. If a customer picks "Check" as payment type but then clicks back to "Credit Card" the submission is broken because the credit card form is reloaded through ajax. As well, in trying to integrate Card on File, if the customer tries to use a different card than the original one they used, it again loads the form through ajax and breaks the submission.

Does anyone have any idea how to get around this? I assume that HostedPCI won't or can't change the way they receive submissions, so it seems like we need to find a way to spoof window.location after an ajax call or remove the ajax entirely and load all the payment type forms and then use #states to show / hide them as neccessary. I've tried hard coding the correct url into the iFrame code (in commerce_hosted_pci_submit_form()) but jquery.ba-postmessage doesn't use that value but window.location still so it still breaks. I've already spent 10+ hours trying to fix this without success so if anyone with more experience has any ideas it would be truly appreciated.

Comments

JulienD’s picture

Status: Active » Postponed (maintainer needs more info)

Hi cjgriffin

A full rewrite of the card on file module has been done and I don't had the time yet to update the module :/

I tried to reproduce your bug but I didn't succeed. If another payment method is selected by default and I choose Hosted_PCI, I can pay without any problem.

What browser are you using? Could you give me more information to reproduce that ? You said the issue happens even when you aren't using card on file ?

cjgriffin’s picture

Hi Julien,

I've updated the module to mostly work with the new card on file. The only thing not quite working yet is the charge callback that is used for example by rules for recurring payments. I can submit a patch here with my work if you'd like to give you a starting point.

I'm going to investigate my bug a little further on a clean install. I'm just wondering if you've only tested with Commerce Kickstart, or with a regular Commerce install too? Thanks!

Chris

JulienD’s picture

Hi Chris,

Usually I develop with a Drupal + commerce but I always test my developments on Commerce kickstart.

Yes, feel free to give me info in order to reproduce your conditions :)

cjgriffin’s picture

Status: Postponed (maintainer needs more info) » Active

Hi Julien,

I did some further testing with a clean Commerce Kickstart installation, and I'm still having the issue. Steps to reproduce:

Install Commerce Kickstart V2 with demo content.
Enable Hosted PCI and enter staging environment credentials.
Set the weight of Hosted PCI rule to be greater than Kickstart example payment rule (so it's not the default payment method).

Edit commerce_hosted_pci.js and add: alert(ret) on line 24 after var ret = sendHPCIMsg();

Add a product to the cart and go through checkout procedure.
Click the Commerce Hosted PCI payent method to load it via ajax.
Enter test card details and submit.
Alert will pop up False because sendHPCIMsg() returns False (it isn't submitted) and error message is displayed (You have entered an expired credit card.) even though the expiry is valid.
If you submit again without changing the card details it will submit properly because the Hosted PCI form wasn't reloaded via ajax.

With Chrome Developer tools I examined the headers (under Network -> showPxyPage!ccFrame.action... With a successful submission (when payment method isn't loaded via ajax), fullParentQStr under Query String Parameters = checkout/{order_id}/review. With an unsuccessful submission (payment method loaded via ajax) it = system/ajax.

I hope this makes sense and helps! Thanks!

Chris

ajm8372’s picture

Hello

Any updates on updating the commerce_hosted_pci module to support card on file 2.0?

JulienD’s picture

Hi,

For the moment I don't have the time to work on the module in order to support the version 2.0 of Card on File.

Patches are welcomed !

garnett2125’s picture

Hi,

The bug was thrown by the ajax which was changing the css id of the select list "expiration date". So when you recheck the commerce hosted pci method then the jquery wasn't able to get the value of the expiration date because the selector wasn't right anymore.

Here is the patch

cjgriffin’s picture

Status: Active » Reviewed & tested by the community

Thanks garnett2125. Working for me.

theo_’s picture

Issue summary: View changes
JulienD’s picture

Status: Reviewed & tested by the community » Fixed

Fixed the expiration date error when submitting the form when Hosted_pci wasn't the default payment method. #1981444

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.