Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Sometimes it's evne charging. Any ideas on why this is?
| Comment | File | Size | Author |
|---|---|---|---|
| #32 | 1000364-round-amounts.patch | 546 bytes | jrust |
| #29 | uc_linkpoint_api-ROUNDFIX.patch | 2.77 KB | bkosborne |
| #26 | lkemper-order-result.jpg | 274.7 KB | gaiello |
Comments
Comment #1
mimetic2 CreditAttribution: mimetic2 commentedMore details:
-I have a 9 digit store # (it asks for 10 in the module)
-newest install fo the module
-I disabled AVS and CVS check
-On SALE in production mode
Comment #2
bkosborneYou certainly should have a 10 digit store number. What type of account do you have with linkpoint?
You're saying that when proceeding to checkout and completing an order, you get a message saying "checkout error contact administrator". I'm not familiar with that... Is that the exact error message? When does it come up? (is it when you click Submit order on the review screen or somewhere else?).
Comment #3
jrust CreditAttribution: jrust commentedComment #4
el luchedor CreditAttribution: el luchedor commentedI am having an issue similar to this. I'm a newbie with Ubercart and am struggling getting this working. I feel like I'm almost there however.
When I submit order, this is the error message:
We were unable to process your credit card payment. Please verify your card details and try again. If the problem persists, contact us to complete your order.
Here is the message I'm getting when I run a report:
couldn't connect to host
The file: /home2/elluchedor/ssl/store/test/1111111111.pem exists: check your pass phrase or verify that you have selected the right "transaction server" for your certificate (PEM file).
I have tried running a test in both Test Server and Live Server modes. Transaction type is SALE. I'm not sure what a "pass phrase" is.
Any help is very much appreciated. Thanks!
Comment #5
bkosborneel luchedor,
Please ensure that apache has read access to that PEM file. This is a common error. Many server environments prevent PHP from accessing "random" directories outside of httpdocs/ and /tmp/ for security reasons.
In the payment settings page, when you enter the path of the PEM file, does it give you an error when submitting?
Comment #6
el luchedor CreditAttribution: el luchedor commentedThe permissions are now set to 777 for the PEM file. I placed the file within the ssl folder and also tried in the www folder but still to no avail. I do not get an error message in the payment settings page.
My error report within the uc_payment type is: Payment failed for order 38: Credit card declined for $14.02 with error: Sorry - Could not connect to payment gateway.
My error report within the uc_linkpoint_api type is: couldn't connect to host
The file: /home2/elluchedor/ssl/store/1111111111.pem exists: check your pass phrase or verify that you have selected the right "transaction server" for your certificate (PEM file).
Comment #7
bkosborneI'm unfamiliar with using all 1's for the PEM file. I assume this is for a test account, but with my test accounts I was given a real store number. I believe to be able to download the test PEM file, you put in all 1's for the TAX-ID, but the PEM file that is provided is actually your store number.
Comment #8
el luchedor CreditAttribution: el luchedor commentedThat is not the real PEM file/store number I am using. The error is:
couldn't connect to host
The file: /home2/elluchedor/ssl/store/1909481541.pem exists: check your pass phrase or verify that you have selected the right "transaction server" for your certificate (PEM file).
Comment #9
bkosborneYou sure you are using version 1.8 ? We took the "sorry" text out of the error message a couple releases ago. Confirm you are using the latest. If you are, try again, then go into watchdog and copy/paste the error log msg.
Comment #10
el luchedor CreditAttribution: el luchedor commentedI appreciate your help with all of this!
I found that I made an error when updating to 1.8. So, now that is done and I only get one error log entry which reads: Payment failed for order 40: Could not connect to payment gateway. Error: couldn't connect to host
Comment #11
bkosborneYou should try formatting that better next time, or maybe wrapping it in code tags...
But anyway, the error you are getting is a cURL error, which likely means your hosting company does not have port 1129 open. See http://drupal.org/node/1009536. Are you on shared hosting? You need to contact them and ask about that port.
Comment #12
el luchedor CreditAttribution: el luchedor commentedSorry about the formatting. I'm a first-timer at this.
I have a dedicated IP with Bluehost. Thanks for your help. I'll give them a shout.
Comment #13
el luchedor CreditAttribution: el luchedor commentedI called Bluehost and they opened the port.
Comment #14
bkosborneThere's nothing in there regarding linkpoint... it would have made an entry in the log if there were an issue. You are still having an issue?
Comment #15
el luchedor CreditAttribution: el luchedor commentedYes, I'm still getting this error message...
Payment failed for order 46: Could not connect to payment gateway. Error: couldn't connect to host
Comment #16
el luchedor CreditAttribution: el luchedor commentedComment #17
bkosborneYou do not need to keep posting that log, it has no useful details. I'm interested in the watchdog log.
Aside from that, if Bluehost said they opened that port, I don't know what to tell you. You are receiving a cURL error, not a LinkPoint error. If you have some PHP experience, I would suggest going in and getting the specific error number from cURL, then doing a quick google search and working with the host.
Comment #18
el luchedor CreditAttribution: el luchedor commentedI appreciate your help and patience with this. I contacted Bluehost again today. Port 1129 was not open bi-directionally. It was only incoming. It is working now.
Thanks again!
Comment #19
bkosborneglad i could help
Comment #20
gaiello CreditAttribution: gaiello commentedBack to the original problem noted in this thread...
My customer definitely has a 6 digit LinkPoint store id (has had it for several years). He contacted LinkPoint and they say they have 6, 7, and 10 digit store ids and suggested we try filling with leading or trailing zeros... which didn't work. Their next suggestion was to have our customer contact his bank's merchant services (BofA) and request a 10 digit number from them, then generate a new pem file from there. I don't know if any of this makes sense but that's the case. The BofA / new pem file step has not been taken as of yet.
The resulting error is as stated above:
"We were unable to process your credit card payment. Please verify your card details and try again. If the problem persists, contact us to complete your order."
No errors with the API configuration, pem path, etc. Just the processing error.
Comment #21
bkosbornegaiello, confirm you are using 1.8 and then check watchdog. there should be an error line in there with more detail. I don't, however, have any experience with store numbers less than 10 digits. I've only used FD as a merchant service.
Comment #22
gaiello CreditAttribution: gaiello commentedThank you for the prompt response. Yes, we're using 6.x-1.8. The watchdog error is:
"Payment failed for order 17: Credit card payment declined: SGS-002301: Charge total must be the sum of subtotal, tax, value added tax, and shipping."
When reviewing the order the correct total charge is there.
Comment #23
bkosborneThat is very strange indeed.... Does this order have both tax + shipping charges? If you have devel installed, do this:
go into the .module file to 456. Right before the return statement, add a line "dpm(get_defined_vars());" ... and then try processing the order again. The information I'm curious about are the values for $subtotal, $tax, $shipping, and $amount.
Comment #24
gaiello CreditAttribution: gaiello commentedHere is the result using the devel module...
#
amount (Float) 13.42313
#
shipping (Float) 5.865
#
item (Array, 6 elements)
*
line_item_id (String, 2 characters ) 33
*
type (String, 3 characters ) tax
*
title (String, 10 characters ) California
*
amount (String, 7 characters ) 0.60813
*
weight (String, 1 characters ) 9
*
data (Array, 4 elements)
o
tax_id (String, 1 characters ) 1
o
tax_rate (String, 6 characters ) 0.0875
o
taxable_amount (Float) 6.95
o
tax_jurisdiction (String, 10 characters ) California
#
tax (Float) 0.608125
#
tax_item (Object) stdClass
*
∞ (Recursion)
#
subtotal (Float) 6.950005
#
xml (String, 128 characters )
6.9500050.60...
*
6.9500050.6081255.86513.42313Again, thank you for looking into this.
-George
Comment #25
bkosborneSomething is def. not right here... but that's very hard to read. Can you do that again, expand out everything you can, and take a screen shot and attach?
Comment #26
gaiello CreditAttribution: gaiello commentedScreen shot attached...
Comment #27
bkosborneAhh... I've figured it out.
Looked a the API manual and found that Linkpoint requires two decimal places for each of those values. What seems to be happening is they are trimming off all the numbers after the 2nd decimal, adding them together and getting $13.41. Do the same trimming on the charge total and you get $13.42. Numbers don't match up.
This probably doesn't happen too often but I consider it a pretty major bug. I will submit a fix for this when I'm home from work tonight. Hang tight.
Comment #28
gaiello CreditAttribution: gaiello commentedUnderstood, sounds good. Of course, my poor customer can not process sales and is a bit frantic. I know you'll do what you can.
Again, thanks.
George
Comment #29
bkosbornewell, after spending roughly 6 hours looking into this problem, it turns out there is a problem with ubercart and the way it rounds numbers. For instance, I replicated the same order you submit on a test store. Ubercart reports:
tax: $0.61
shipping: $5.87
subtotal: $6.95
-------
charge total: $13.42
If you actually add those numbers up, you get $13.43. The module was reporting to Linkpoint those numbers above. Linkpoint then adds them up, notices they are off by a cent, and denies it.
I "fixed" this by adjusting the subtotal that's passed to Linkpoint to be the $chargeamount - $tax - $shipping. That will make sure the numbers always add up. HOWEVER, that means that the subtotal that Linkpoint gets will be off by a penny from what Ubercart reports. Not a huge deal. In this case it would have the subtotal at $6.94. This is a flaw in Ubercart, and I can't do much about it until it is fixed. There is a loooong discussion about it here: http://drupal.org/node/479784.
Anyway, this patch was created from the latest dev release. So update to that, then apply this patch. Let me know if this fixes the problem (it should for now anyway), then I'll commit.
Comment #30
gaiello CreditAttribution: gaiello commentedYes, the dev version and patch did the trick. The customer is OK with the penny differences. We'll keep an eye out for the overall Ubercart fix. Also in the fyi department, his 6 digit store id works fine.
Thanks so much for the prompt attention and effort you made on this.
-George
Comment #31
jrust CreditAttribution: jrust commentedNot sure if it's related, but check out #1066072: Subtotal doesn't always play nice with discounts, as I found I was getting subtotal errors, not from rounding, but from an incorrect calculation of the subtotal when discounts or gift certificates were present. Maybe the subtotal variable in this issue was off because of that?
Comment #32
jrust CreditAttribution: jrust commentedI don't know if this is really an ubercart issue, so much as an issue with trying to program with floating point numbers in general. From the PHP manual about floats:
My thought is that we can solve this in a simpler fashion by rounding to two pennies before checking to see if a subtotal should be included in the XML. I've attached a patch with what I'm thinking. Please apply it against a fresh copy of dev and see if it works for you.
Comment #33
bkosborneI'm not convinced that will fix it. In fact, I believe I tried that approach when trying to fix gaiello's problem. This problem is also unrelated to coupon discounts. The problem is that the numbers for tax, shipping, and subtotal have all been rounded by Ubercart while calculating the initial total amount that needs to be charged to a card. Because of weirdness I don't have time to look into, the numbers don't always add up.
Yes, we get the full (5 decimals) amount of subtotal tax and shipping, but the amount for charge has already been calculated and the customer was already shown the numbers.
This issue tracks the problem: #479784: Order rounding and will ultimately fix our issue here.
Comment #34
jrust CreditAttribution: jrust commentedBut what I don't understand is how this problem can be triggered when we already have a test to ensure that we only send Linkpoint subtotal if $tax + $shipping + $subtotal = $amount. My thought was that our test was faulty because in some rare cases it could pass that test but then the amounts are slightly off because of float issues. Hence, my thought that we would avoid it by rounding to two decimal places before doing the test.
Comment #35
bkosborneYes, we only send that info if they add up. The reason for this check is to ensure we don't sent that information if this charge is a 'secondary' charge for an order, meaning that the charge amount is not indeed the order subtotal, but instead a partial or additional payment.
If it was a first time, complete order charge, the module will ALWAYS send subtotal, tax, and shipping info to Linkpoint because we are given all of the numbers as their original float values, and adding them up will always check out to be good. This is not the problem.
The problem is that Linkpoint will only accept two decimal places. It does not round up the numbers if we give them extra decimals, it will just cut them off (to my best knowledge). So in gaiello's case, look at the latest screenshot he posted of the order review screen.
The numbers are all rounded up to two decimal places, but the amount does not seem to be the addition of the item total + tax + shipping. It seems the numbers are just rounded for display purposes only. You can verify this by adding his Shipping + Subtotal + Tax. It comes to 13.43, but the order total reports 13.42.
So it doesn't matter if we decide to round the subtotal, tax, and shipping before sending it to Linkpoint. Because in his case, the subtotal would report 13.43, while the charge would be 13.42. If we just leave it the way it is and let Linkpoint chop off the extra decimals, the subtotal adds up to 13.41 and the charge total 13.42.
No easy solution. I'm fairly confident that the issue I cited will resolve this. I hope that wasn't too long/confusing jrust?
Comment #36
jrust CreditAttribution: jrust commentedHmm, I'm still not reproducing it right. Here's my little test using the numbers in the screen dump:
And the output is:
I did notice the tax variable seems wierd. It's listed in the line item as being 0.60813 but the actual tax variable is 0.608125.
What about this, is there an order we can create locally that reproduces this problem consistently so we can test various ideas to fix it and ensure that we're solving the issue?