uShop English (U.S.) for 179!

uStorekeeper English (U.S.) for 149!

 Tech Support
       Support Policy
       Knowledge Base
       Reference Sites
       Software Piracy
       Legal Notices
       Privacy Policy
       Reseller Info
       Contact Us
       Site Map
custom payment link

Knowledge Base Lobby : uShop Support Conference : Programmer Tips
Jul-16-18 10:34 AM EST
Original Message
custom payment link
Author Brian Stevens on 05-18-2001 at 08:10 (EST)

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

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

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


Table Of Contents
  RE: custom payment link Bill Weiner, 2001-05-20 21:05:19 (1)
            custom payment link Brian Stevens, 2001-05-21 07:12:00 (2)
                 RE: custom payment link Bill Weiner, 2001-05-21 21:42:46 (3)
                      still problems Brian Stevens, 2001-05-22 08:17:31 (4)
                           RE: still problems Bill Weiner, 2001-05-22 18:45:13 (5)
                                working better Brian Stevens, 2001-05-23 08:10:26 (6)
                                     rounding.... not Brian Stevens, 2001-05-27 21:03:22 (7)
                                          RE: rounding.... not Bill Weiner, 2001-05-29 20:10:08 (8)

Messages In This Discussion
         1. RE: custom payment link
        Author Bill Weiner on 05-20-2001 at 21:05 (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? (,, and

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 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.
                 2. custom payment link
                Author Brian Stevens on 05-21-2001 at 07:12 (EST)

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

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

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).


                         3. RE: custom payment link
                        Author Bill Weiner on 05-21-2001 at 21:42 (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);
                                 4. still problems
                                Author Brian Stevens on 05-22-2001 at 08:17 (EST)

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??

                                         5. RE: still problems
                                        Author Bill Weiner on 05-22-2001 at 18:45 (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 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.
                                                 6. working better
                                                Author Brian Stevens on 05-23-2001 at 08:10 (EST)

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...
                                                         7. rounding.... not
                                                        Author Brian Stevens on 05-27-2001 at 21:03 (EST)

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);
$totals_total= sprintf("%.2f",$totals_total);

but both no good, any more sugestions?

                                                                 8. RE: rounding.... not
                                                                Author Bill Weiner on 05-29-2001 at 20:10 (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 file... immediately BEFORE the line:

$custom_name = "$billing_first_name $billing_last_name";

And that should do it.

© 2003 Microburst Technologies, Inc.