wizardsandwars

You need either.... 1.) Your own merchant account and payment gateway. Authorize.net is a good gateway, but you still need a merchant account. If you go through authorize.net directly, it will be more expensive. The best thing to do is to find a authorized auth.net reseller that will give you a merchant account and payment gateway for nothing up front. This is a pretty common promotion if you get the merchant account and gateway together. With these types of modules, you collect the cc info on your website, and programatically process the payment through the gateway. The money lands in your merchant account, and is batch deposited in your business account once per day. The standard CC module you are using just collects the CC info, but nothing is processed. This module is for the #3 type of processing cc's below. 2.) A third party processor, such as paypal, 2checkout (big mistake here). There are a few others. During checkout, the customer is taken to a third party website, where they make the payment. The money lands in your account with the third party. Usually there is slightly more restrictions on how you withdrawl the money to your account, and you have less protection in the event of fraud. 3.) Off line, or near line processors. This is where you have a merchant account and a virtual terminal. So you collect the CC information on your website, and then have to manually enter it in on your vitual or real physical cc terminal. It's a little more manual, but it's usually alot cheaper this way. There's a ton more information about cc payment processors in my blog.

First of all, you didn't tell anyone what contribution you are talking about. Secondly, it looks like either you have not installed it properly, or the contribution forgot to tell you to run the SQL to add columns to the database tables. I suspect the former. Re-trace your steps through the installation procedure, and pay particular attention to any parts that tell you to run some SQL against the MySQL database. HTH

You don't know what you've done? I supposed that also means you didn't make a backup before you done it?

MOECTO does both.

Iv'e gotten it to work on 3 or 4 stores now. If it's not working for you, then I think it might be that you didn't install it properly. A space at the end of a file is a good place to start looking.

I think the problem is in the 'Show price with VAT' contribution. In your configuration, set the 'show poducts with tax' option to false, and see if that fixes the subtotal amount on the confirmation page.

No, go to an authorized reseller of authorize.net. They won't charge you a dime up front.

You can fix that about 99.9% of the time by giving paypal a 'Return URL' of your checkout_process.php file. In order to make it 100%, you'll need to install the paypal IPN module.

It would be straight PP processing, yes. But customers could still use a credit card to purchase. Thie difference between a standard paypal module, and paypal's payments pro, is that with the standard module, customers are re-directed to paypal's website to actually make the payment. With the payments pro module, the customer give you their CC details right on your site. A standard module only takes a few minutes to set up, and costs nothing up front. Unforutnatly, it does make the checkout even longer, (ungh), and it will cost you about 1/2 your customers if that's the only payment module you offer. Still, it's a fantastic way to get up and running, and give you some times to work the kinks out of your business model.

If you are processing less than $1000 per month, I'd recommend jsut using the standard paypal module (with IPN), until you can build the business a little bigger. Yes, you'll lose customers using only a standard paypal account, but it will give you some time to work on you marketing, and link building. Once your are processing over $1000, you can switch over to a merchant account/gatway without having to worry about those 'minimums'.

I've tried them all, and I think that this one is probably the best. http://www.oscommerce.com/community/contri...all/search,josh

Not directly, no. It goes into your paypal account. From there you can withdrawl the money to your bank account. I'm not sure if you can schedule this or not.

No need to pay $200 to setup authoprize.net. If you go with a merchant account / gateway through the same vendor, the gateway is normally free. The bottom line between these two solutions is this... The merchant acocunt / gateway is $10 more expensive, but give you a little more recourse against chargebacks. PayPay Payments Pro dumps to your paypal acocunt, which is nice to have some flexibility for how and when you withdral to your back account.

That's a very subjective opinion, for those of you following alog. Session IDs in the URL are perfectly fine, as long as you make sure you don't assign them to seach engines spiders. And for the growing population of users out that that are becoming more and more security sensitive and have their cookies disabled, no, there are not other methods. Session IDs in the URL is a neccesary evil, unless you don't mind losing ~20% of your potential customers right off the bat.

The meta tages are already in the page. You can define your global meta title in the english.php file.

define('TITLE', 'makeupworld.co.uk');

Each contribution is different. You'll need to read the install or read me instructions. Normally, yes, it means that you will have to ftp download the files affected in the contribution to your desktop, and manually make text edits as instructed.

/includes/languages/english/checkout_success.php

You do that at paypal, not in your OSC admin. This is the easiest way to fix the problem, and works about 99.9% of the time.

Well, if you have a better way to do it, I would certainly encourage you to do so. And since you're going to be in there anyways, a contribution making this chagne would be nice. I wonder how this was addressed in the new CVS preview of MS3?

There's a contribution that changes all the buy now links to forms. That fixes the issue.

opps I forgot the $language variable. $contents = fread ($fd, filesize (DIR_WS_HTTP_CATALOG . DIR_WS_LANGUAGES. $language . '/' . $filename));

ok, the easiest way to do that is going to creat a differetn html file for each language, and put it in the appropriate language directory. The in the script you've pasted above on this line.... $contents = fread ($fd, filesize ($filename)); You've going to want to change the $filename variable to point at the appropriate directory $contents = fread ($fd, filesize (DIR_WS_HTTP_CATALOG . DIR_WS_LANGUAGES. $filename)); I think that should work

While I like the abbreviated checkout, there's a couple of things I don't like about the way this is implemented, and I think it could be improved upon. 1.) Kinda hard to get real time UPS and USPS quotes without having the address first. Having to refresh the page essentially adds another page to the checkout. 2.) The details page is WAY too long. I think this would scare customers away more than the long checkout does. 3.) In almost every major shopping cart out there ,they ask for your 'shipping address' first, and then you have a way to indicate if the billing address is different than the shipping address. Your solution seems to have it backwards. I've given it a great deal of thought, and I have a few ideas on how to make solve some of these problem with your checkout process. 1.) Move the 'Billing Address' to the 'shopping cart' page, and change it to 'Shipping Address. This solves the problem of getting the shipping quotes, becuase they won't show up until the next page. This also removes quite a bit of clutter form the main checkout page. Provide a link at the top of the form to direct customers to the login screen. 2.) On the alternative checkout page, put the button back in the payment method selection to chagne the payment address, if needed. We can assume by default that it is the same as the shipping address, but they can change it on this page if they need to. 3.) Take the product image out of the shopping cart sumary, in order to 'condense' this section, and make this page a little less lengthy. 4.) Move the 'comments' section of this page to the checkout confirmation page. It's usually the confirmation page that peoplethink to add a comment anyways. There's also the whole problem of returning customers not hitting the 'click here if you have purchased from us before'. They fill in all their details (for a second time), and then they get an error saying that they already have an account, and are redirected to a login page where they have to remember and old password. While most of your customers are always going to be new, success of your business depends on return customers, and we should consider making it a little easier on them. If they fill in their details accidentally a second time, we shouldn't give them an error message. We can easily allow them to go ahead and purchase with the new address they provided. Here are some other usefull ideas you might look over in consideration of your new checkout process. http://wizardsandwars-oscommerce.blogspot....kouts-suck.html

Well, it's probably best to look at other options for getting more order before looking at a merchant account and payment gateway. I'd reocmmend upping your adverting, and doing some SEO to get your orders up to where you are processing at least $1000 per month before you consider adding a merchant account. Here's some thoughts on when you should use paypal and a comparison between paypal and a merchant account. http://wizardsandwars-oscommerce.blogspot....use-paypal.html http://wizardsandwars-oscommerce.blogspot....nt-gateway.html