www.uburst.com www.uburst.com

"custom payment link"

Go back to the LobbyClick here to Go Back to Main ListingClick here to see helpClick here to Search the Forum

Programmer Tips
Forum Type: Public
Moderator: edmunds
Time Zone: EST
Printer Friendly Format
Original Message
 
"custom payment link"
Posted by Brian Stevens on May-18-01 at 08:10 AM (EST)
Hi,

I had a custom payment system working on V3.1 but when I upgraded the store to V3.4 I was able to get everything working except the success/fail url that used to work, now doesnt.

Has the syntax changed at all between the versions??

I am using

http://www.xxx.net.au/store/cgi-bin/ushop.pl?command=custom_payment&ind=s&inv=002356809

as the syntax for the payment gateway to pass the success of the transaction back to me and

http://www.xxx.net.au/store/cgi-bin/ushop.pl?command=custom_payment

as the fail url.

Both these now return "File Error Unable to locate .tmp" (even though I checked the .tmp file is in the data directory)this worked up till the time I upgraded.

By the way, the reason for upgrading was that one of the 3.1 appletes cant add up correctly when multiple products with prices ending in 95cents (this seem to be corrected in the later version.

Any help is appreciated

Click to Send Alert Message to the Administrator Click to edit this messageClick to EMail Click here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents

 Table of Contents

RE: custom payment link, Bill Weiner, May-20-01, (1)
custom payment link, Brian Stevens, May-21-01, (2)
RE: custom payment link, Bill Weiner, May-21-01, (3)
still problems, Brian Stevens, May-22-01, (4)
RE: still problems, Bill Weiner, May-22-01, (5)
working better, Brian Stevens, May-23-01, (6)
rounding.... not, Brian Stevens, May-27-01, (7)
RE: rounding.... not, Bill Weiner, May-29-01, (8)

 

 
Click here to goto Click here to goto the Lobby
Messages in this discussion
 
1 . "RE: custom payment link"
Posted by Bill Weiner on May-20-01 at 09:05 PM (EST)
There were no specific changes between 3.1 and 3.4 that would affect your custom payment method. But here are some things to check/note in order to help you determine the problem:

1) When upgrading from 3.1 to 3.4, are you sure you replaced all 3 uShop CGI scripts? (ushop.pl, ushop-lib.pl, and ushop-languages.pl)

2) Are you sure you implemented all of the custom changes that you made to your 3.1 scripts into your 3.4 scripts?

3) Are you sure you are linking back to the correct script URLs? (Ie. Make sure that your not still linking back to your 3.1 script URL... in case you still have your 3.1 scripts on your server).

And just as a note, as of uShop 3.4, the default order number format is MMDDYYYY-RRRRRRRRR (where MMDDYYYY is the year and RRRRRRRRR is a randomly generated order number). So unless you manually changed the $date_format in the 3.4 ushop-lib.pl script back to just RRRRRRRRR, that may be an indication that you are linking back to an old version of the uShop CGI script on your server.

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
2 . "custom payment link"
Posted by Brian Stevens on May-21-01 at 07:12 AM (EST)
Bill,

Thanks, all good sugestions, but I worked through most of them the other day, the question really is "will the syntax I have quoted above work to call the correct ushop functions as a url"?.

But that is not my only problem, as although I cant get 3.4 working with the custom mods, the real problem is that crazy numbers get passed to the payment gateway, see below for details

Specific comments from your posting:

>1) When upgrading from 3.1 to 3.4,
>are you sure you replaced all
>3 uShop CGI scripts?

Yes done that and all the appletts as well

>2) Are you sure you implemented all
>of the custom changes that you
>made to your 3.1 scripts into
>your 3.4 scripts?

Im as sure as I can be, but since the only thing that doesnt work is the return url, I am pretty confident (but how many times have you heard that??)

>3) Are you sure you are linking
>back to the correct script URLs?

3.1 doesnt live there anymore..

>And just as a note, as of
>uShop 3.4, the default order number
>format is MMDDYYYY-RRRRRRRRR

Yeah, I worked that one out, as the payment gateway only accepts max 10 digits. I set the format parameter in the lib file to fix the numbers like the 3.1 version.

I have the clients problem sorted at the moment by making all thier prices that end in .95 now end in .90 as when someone adds multiple x.95 items to the cart, ushop tries to pass a number like 100.89994 to the gateway (which rejects it). Interesting the display says 100.90 but source says 100.89994 is it a known bug??)which is the number passed to the gateway.

I have set up our demo system so as to not screw with the clients site while we work this one out, you can have a look at both problems (failing success url and crazy numbers) at the following location

http://www.tel.net.au/demo

You have to go through the process and you can get the crazy numbers (as per the page source) by adding these products:

IS01 In Step Children $ 18.95
PLATA01 Plataroos Live $ 18.00
DSSDD01 Dan's Super Slam-Dunk $ 13.95
BA01 Bible Adventures $ 18.95

The display says the total is $ 69.85 but the source says 69.850006.

To see the other problem just select an even number total and see that it fails on the last part when it returns back to the site (can find the temp file).

Thanks

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick to EMail Click here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
3 . "RE: custom payment link"
Posted by Bill Weiner on May-21-01 at 09:42 PM (EST)
Based on your return URL, you are passing the order number via the parameter name "inv". By default, the $order_number is determined via the parameter name "order_number".... so if you are using "inv" instead of "order_number", then you will need to add a line like this near the top of your complete_order subroutine:

$order_number = $form_text{'inv'};

This most likely will fix your "Unable to open .tmp file" errors (because your order number was not getting set).

In regard to formatting the subtotal, if your payment processing system requires that the amount be formatted to only 2 decimal places, then you may want to add the following line near the top of your "custom_payment" subroutine:

$totals_total = sprintf("%.2f",$totals_total);

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
4 . "still problems"
Posted by Brian Stevens on May-22-01 at 08:17 AM (EST)
Bill,

Thanks for your help, but.....although both those tips sounded promising, niether worked.

The rounding down to 2 decimals didnt (the source still said "amt=74.850006" and the gateway rejected it, but works ok other amounts) The real question here is why doesnt it add up to the right ammount in the first place? why always this + or - .0000006?

Anymore sugestions for this one?

Also the failure to find the temp file still exisits. The return url is one you guys gave me to use last year with the "inv" in it, and it works under 3.1 (ie the gateway sends that url format back to us and ushop picks up the right temp file) but does not under 3.4

Anymore sugestions for this one??

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick to EMail Click here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
5 . "RE: still problems"
Posted by Bill Weiner on May-22-01 at 06:45 PM (EST)
In regard to the "amt" still saying "74.850006"..... if "amt" is the parameter name that you are passing to your external payment processing system... then that is the parameter that you have to format with the "sprintf" syntax that I mentioned above. Just perform that on whatever variable you are passing as "amt".

In regard to why the total is off in the first place, that is just the way the floating-point numbers are getting rounded somewhere along the line. It's probably being introduced if using some quantity x price calculation... and the floating-point numbers are just being rounded that way.

In regard to the "inv", if that is the parameter that your external payment processing system is returning as the order number, then you're going to have to put that line:

$order_number = $form_text{'inv'};

... in there before the .tmp file is read. Double-check your older "complete_order" subroutine (in your older ushop.pl file) and you should see that somewhere.

Also, if we helped you with this custom interface before, then refresh my memory and remind me which external payment processing system this is for. I may be able to help again.

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
6 . "working better"
Posted by Brian Stevens on May-23-01 at 08:10 AM (EST)
Bill,

Ah ha......

I failed to notice the extra custom mods in the complete_order sub and now I have done this it seems to work ok with the return url.

I am off to test the rounding thing now....

By the way, the custom mods were for the National Bank in Australia back in November.

Thanks for your help...

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick to EMail Click here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
7 . "rounding.... not"
Posted by Brian Stevens on May-27-01 at 09:03 PM (EST)
Bill,

I still cant seem to get the rounding of the amount down to 2 points.

Everything else seems to work except when we add 3 x 18.95 items (and other .95 combinations) to the cart the rounding goes out to 6 digits and I dont seem to be able to reduce it.

We are passing the amt from $custom_amount which also:

$custom_amount = totals_total_with_shipping_tax
$custom_amount = $totals_total

I tried using

$custom_amount = sprintf("%.2f",$custom_amount);
and
$totals_total= sprintf("%.2f",$totals_total);

but both no good, any more sugestions?

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick to EMail Click here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents
 
8 . "RE: rounding.... not"
Posted by Bill Weiner on May-29-01 at 08:10 PM (EST)
You should only have to add the line:

$custom_amount = sprintf("%.2f",$custom_amount);

... to the "get_custom_payment_button_html" subroutine in your ushop.pl file... immediately BEFORE the line:

$custom_name = "$billing_first_name $billing_last_name";

And that should do it.

Remove this Message: Administrator and Moderator onlyClick to Send Alert Message to the Administrator Click to edit this messageClick here to reply to this messageClick here to reply to this message with quotesClick to goto the Table of Contents


Archive This Thread: Admin and Moderator OnlyRemove This Thread: Admin and Moderator Only
Click here to goto Click here to goto the Lobby

 

 

 

 

 

 

 

 

 

 

 

 
Questions or problems regarding this bulletin board should be directed to Webmaster
©1997-1999 by DCScripts. All rights reserved.