|
Vittorio Pennazio
|
June 24, 2014 at 2:58 am
Good morning, we have set-up Quickpay as a payment gateway but, whereas the test mode worked, it does not work with live transactions. I have contacted them and the issue is that EE (version 3.1.36.5.P Get Version 3.9.1) uses Method Form V3, but V3 is no longer accepted by the banks and it needs to be updated to V7. They told me it’s a pretty quick thing to do, like two little things to be changed in the code, but we desperately need your help on that! Please let me know what should be done to get that up and running as soon as possible!
Thanks in advance,
Vittorio
|
|
Tony
|
June 24, 2014 at 5:31 am
Hi Vittorio,
Thank you for reporting this, I have issued a ticket for the developers to investigate.
Looking over the output for v7, I can see no differences in the HTML output between v3 and v7 (however that does not mean there is no difference within the protocol used) meaning this may just be a simple case of updating the ‘protocol’ version number used however I think it would be best to wait for feedback from the developers due to this involving live transactions.
|
|
Vittorio Pennazio
|
June 25, 2014 at 2:14 am
Hey, thanks for the update. I have found this one on QuickPay website:
http://quickpay.net/faq/new-payment-window/
How soon do you think that developers can find a solution?
In any case, I think I will try later today to just change the 3 to 7 and see if that’s enough (though from that link it seems that there’s more things that changed and the QuickPay guy told me over the phone that it was about a couple of lines to be changed)
|
|
Tony
|
June 25, 2014 at 4:21 am
Apologies, what I had intended to say above was I could see no differences between our HTML output (using v3) and the output that Quick-pay is expecting using v7.
Our Quick-Pay gateway already uses the correct input names etc, the difference between the example output and the output we have is we are using a couple of extra fields/options.
If you would like to update the Protocol version number used open up event-espresso\gateways\quickpay\quickpay_vars.php line 15 you will find:
$protocol = '3';
Change that to
$protocol = '7';
Then test a live transaction.
|
|
Vittorio Pennazio
|
June 25, 2014 at 5:27 am
Perfect, thanks!
|
|
Dean
|
June 25, 2014 at 6:34 am
Please let us know if this resolves the issue or not.
|
|
Vittorio Pennazio
|
June 30, 2014 at 5:06 am
Hi, sorry for the late reply, there was also some issues between QuickPay and the merchant bank. Now that they’re solved, there’s another problem: it marks the payment as incomplete, while instead the payment went through.
Interestingly, when I tried in Test Mode before (when there was still the v3), the registration got marked as completed. Now, both in test and production mode, the registration is marked as incomplete, although I can see that the transaction got through on QuickPay.
What could it be?
|
|
Sidney Harrell
|
June 30, 2014 at 11:28 am
Got it sorted out:
Ver 7 of the API sends back several additional fields, one of which is “fee”. Now, I could not find a definitive list of the md5 checksum fields used on the return of the user to the site in the Quickpay official API documentation, but I did look in the Drupal Quickpay module’s code, and in their return md5 checksum field list, they have that “fee” field listed in there. I tried changing our return md5 checksum field list to match, and it works. Go into gateways/quickpay/quickpaypaymentprocess.php and change lines 27-31 from:
$cardnumber = isset( $_POST['cardnumber'] ) ? sanitize_text_field( $_POST['cardnumber'] ) : '';
// concatenate above values, add our SECRET QUIICKPAY SALT value, then md5 the whole thing
$response_md5_check = md5( $msgtype . $ordernumber . $amount . $currency . $time . $state . $qpstat . $qpstatmsg . $chstat . $chstatmsg . $merchant . $merchantemail . $transaction . $cardtype . $cardnumber . $quickpay_settings['quickpay_md5secret'] );
to:
$cardnumber = isset( $_POST['cardnumber'] ) ? sanitize_text_field( $_POST['cardnumber'] ) : '';
$fee = isset( $_POST['fee'] ) ? sanitize_text_field( $_POST['fee'] ) : '';
// concatenate above values, add our SECRET QUIICKPAY SALT value, then md5 the whole thing
$response_md5_check = md5( $msgtype . $ordernumber . $amount . $currency . $time . $state . $qpstat . $qpstatmsg . $chstat . $chstatmsg . $merchant . $merchantemail . $transaction . $cardtype . $cardnumber . $fee . $quickpay_settings['quickpay_md5secret'] );
PS. You might want to copy your quickpay folder from plugins/event-espresso/gateways to uploads/espresso/gateways before you do these changes, so that your changes will be preserved the next time you update. I’ve created a ticket and submitted these changes into the codebase, but they probably won’t show up in release until 3.1.38
|
|
Vittorio Pennazio
|
July 2, 2014 at 2:45 am
Hi Sidney,
thanks for your help. I have tried but unfortunately that does not seem to fix the problem: the payment still shows as incomplete on EE, both in front and back end, while instead the payment got indeed through on QuickPay. I guess there still some other variables not aligned with QuickPay. What about something on the points 11. and 12. in the list at the end of this page? http://quickpay.net/faq/new-payment-window/
|
|
Sidney Harrell
|
July 2, 2014 at 10:57 am
gateways/quickpay/quickpay_vars.php line 95 and line 99.
That document only deals with sending the user off to the quickpay server, but does not deal at all with receiving the user back from the quickpay server, which is where your problem lies. You might want to turn on “full logging” in the general settings, then do a test transaction, and take a look in uploads/espresso/logs/espresso_log.txt. You should see both the user returning to the thank-you page, but also the notification message sent by quickpay. It should have request variables like “fee” and “md5check”.
|
|
Vittorio Pennazio
|
July 2, 2014 at 1:27 pm
Hi Sidney,
thanks for the update. I did that and what I guess that the useful part is this one:
<code>[ 2014-07-02 19:20:44 ] espresso.php
VARS : page_id = 789 & id = 119 & r_id = 1-53b45b47e8241 & attendee_action = post_payment & form_action = payment & type = quickpay & chronopay_callback = true & transaction_id = eddea82ad2755b24c4e168c5fc2ebd4053b45b7b224b18.62675292 & sessionid = vo46sl4ilr6il6tcr11cbna7n7-53b457f82983f3.88380812 & msgtype = capture & ordernumber = 1-53b45b47e8241 & amount = 100 & currency = EUR & time = 2014-07-02T19:20:40+00:00 & state = 1 & qpstat = 000 & qpstatmsg = OK & chstat = 00 & chstatmsg = queued for capture & merchant = Innovation Roundtable & merchantemail = accounts@innovationroundtable.com & transaction = 90960005 & cardtype = dankort & cardnumber = XXXXXXXXXXXX++++ [++++ = last 4 digits of my card] & cardhash = & splitpayment = & acquirer = & fraudprobability = low & fraudremarks = & fraudreport = & fee = 0 & md5check = 961625a349b91cf28efdb54cadd58e34
[ 2014-07-02 21:20:44 ] registration_page.php -> FILE LOADED
[ 2014-07-02 21:20:44 ] cart.php -> FILE LOADED
[ 2014-07-02 21:20:45 ] espresso.php -> espresso_load_pricing_functions
[ 2014-07-02 21:20:45 ] espresso.php -> espresso_export_certificate
[ 2014-07-02 21:20:45 ] espresso.php -> espresso_export_ticket
[ 2014-07-02 21:20:46 ] espresso.php -> ee_init_session
[ 2014-07-02 21:20:46 ] espresso.php -> load_event_espresso_widget
[ 2014-07-02 21:20:46 ] process_payments.php -> event_espresso_txn
[ 2014-07-02 21:20:46 ] process_payments.php -> event_espresso_txn
Payment for: Pennazio, Victor|| registration id: 1-53b45b47e8241|| transaction details: a:23:{s:7:"msgtype";s:7:"capture";s:11:"ordernumber";s:15:"1-53b45b47e8241";s:6:"amount";s:3:"100";s:8:"currency";s:3:"EUR";s:4:"time";s:25:"2014-07-02T19:20:40+00:00";s:5:"state";s:1:"1";s:6:"qpstat";s:3:"000";s:9:"qpstatmsg";s:2:"OK";s:6:"chstat";s:2:"00";s:9:"chstatmsg";s:18:"queued for capture";s:8:"merchant";s:21:"Innovation Roundtable";s:13:"merchantemail";s:33:"accounts@innovationroundtable.com";s:11:"transaction";s:8:"90960005";s:8:"cardtype";s:7:"dankort";s:10:"cardnumber";s:16:"XXXXXXXXXXXX++++ [++++ = last 4 digits of my card]";s:8:"cardhash";s:0:"";s:12:"splitpayment";s:0:"";s:8:"acquirer";s:0:"";s:16:"fraudprobability";s:3:"low";s:12:"fraudremarks";s:0:"";s:11:"fraudreport";s:0:"";s:3:"fee";s:1:"0";s:8:"md5check";s:32:"961625a349b91cf28efdb54cadd58e34";}</code>
Is that useful to see what’s the variable that is not aligned between EE and Quickpay?
|
|
Vittorio Pennazio
|
July 2, 2014 at 1:34 pm
Something went wrong copy-pasting the code, here it is again:
http://codeshare.io/3QgM2
|
|
Sidney Harrell
|
July 2, 2014 at 6:44 pm
It’s got the “fee” var there in the request. Can you double check that you added the $fee to this line:
$response_md5_check = md5( $msgtype . $ordernumber . $amount . $currency . $time . $state . $qpstat . $qpstatmsg . $chstat . $chstatmsg . $merchant . $merchantemail . $transaction . $cardtype . $cardnumber . $fee . $quickpay_settings['quickpay_md5secret'] );
You might want to throw in a var_dump of the $fee, just to check that you are getting the “0” that is in the request:
var_dump($fee);
|
|
Vittorio Pennazio
|
July 3, 2014 at 2:13 am
Hi Sidney,
Thanks! Where shall I put that var_dump exactly?
Unfortunately I am not an expert programmer, but it looks indeed that the problem is with the check-sum since, looking on the back end, the amount_pd is 0.00 (as set in the “else of lines 38-39” in quick paypaymentprocess.php). Hence it means that the IF that, if true, changes amount_pd to the paid amount and payment_status to Complete is false.
What about the following variables, are they part of the check-sum on Quickpay side? card hash, split payment, acquirer, fraud probability, fraud remarks, fraud report
Actually, digging a bit into QuickPay website I have found this two pages about the md5check:
a) http://quickpay.dk/faq/md5check/ (it’s in Danish, but you can Googletranslate the paragraphs) – or in English, but without comments: http://quickpay.net/faq/md5check/
b) http://doc.quickpay.dk/paymentwindow/technicalspecification.html#index1h2
(hopefully that’s where the key of the issue is)
…so, in other words, are we sure that all the variables defining the md5 check are aligned?
|
|
Sidney Harrell
|
July 4, 2014 at 11:26 am
That’s the documentation on the md5 checksum that you have to send with the customer to the quickpay site. There is a different md5 checksum that is sent by quickpay back with the customer to your site after they have made the payment. Our code then needs to calculate an md5 checksum and compare it with the one sent from quickpay to confirm that it is a valid payment. That uses the list md5( $msgtype . $ordernumber . $amount . $currency . $time . $state . $qpstat . $qpstatmsg . $chstat . $chstatmsg . $merchant . $merchantemail . $transaction . $cardtype . $cardnumber . $fee . $quickpay_settings[‘quickpay_md5secret’] ). On my test site, when I changed it to version 7 in the quickpay_vars file, it started sending the $fee variable, and my payments stopped verifying. I pulled the $fee from the request, put it in the md5, and the payments started verifying again.
You can put that var_dump($fee) line anywhere after it gets declared on line 28.
|
|
Vittorio Pennazio
|
July 9, 2014 at 5:52 am
I have tried with the var_dump($fee) and all I got was…
a) it still shows incomplete although the payment went through according to QuickPay
b) the payment date and type were missing
c) I got the following message from quickpay on my e-mail:
Failed to notify callbackurl “http://innovationroundtable.com/summit/?page_id=789&id=123&r_id=1-53bd281ce49ec&attendee_action=post_payment&form_action=payment&type=quickpay&chronopay_callback=true&transaction_id=8dd48d6a2e2cad213179a3992c0be53c53bd282584e673.43478295&sessionid=5671d3n7duoi5panhv34sqckm3-53bcf9c2164c36.83630217” for ordernumber “1-53bd281ce49ec” with message: Server responded with status code “500”
Please see http://quickpay.net/faq/failed-to-notify-callbackurl for more information.
Once I have removed the var_dump and tried again, a) still occurred but b) and c) not any longer.
I have been in contact again with QuickPay and they suggest you to check this page (it’s in Danish and the English version is not available yet, but you can use Google Translate or so): http://quickpay.dk/features/v7/
Having a quick look at it… might it be something related to the acquirer field?
Vittorio
|
|
Sidney Harrell
|
July 9, 2014 at 4:21 pm
You need a semicolon at the end of the var_dump, like:
var_dump($fee);
otherwise, it’ll generate a php error, which probably caused the 500 error.
|
|
Vittorio Pennazio
|
July 10, 2014 at 2:47 am
Hi, thanks, that solved the issue with the 500 error but still not the overall issue of the md5check. What about the acquirer field, as in my previous message? Can be that the origin of the problem?
|
|
Sidney Harrell
|
July 10, 2014 at 9:41 am
It could be. They aren’t sending anything in those fields to me, or my test transactions would fail, but they may be sending something in those fields to you. I’ve made an updated version of quickpaypaymentprocess.php with all the fields in that documentation. (Good find getting that, btw).
|
|
Vittorio Pennazio
|
July 10, 2014 at 1:32 pm
IT WORKS!!!! 😀 Thanks a lot!
|
