e-commerce site - need advice

[John Paul]

I'm thinking of building an e-commerce site in php.

Anyone got any advice in building one?

What is the best way to implement a payment system?

Are any legal issues involved?

Thanks,

John Paul.

[peter]

I'm thinking of building an e-commerce site in php.

>
Anyone got any advice in building one?

What is the best way to implement a payment system?

Are any legal issues involved?

the main legality you will come across is the responsibility to ensure that
users data is secure.

Is there a reason you wish to build 1 from scratch? it is not so,ething you
should take on lightly especially for 1 person doing all of the coding. A
better idea would be to find a good open source ecommerce package and build
upon that.

[Dano]

I've worked for a company that used one extensively to sell barcode
printers, labels, scanners, etc., so I think I can give you a couple of
good pointers.

First, decide if you will do real-time processing of credit cards, or
just take the numbers, and process later as a batch process. Real-time
processing costs more, and to be honest, might be an expense you don't
need, especially in the startup phase. Consider gathering the credit
card info, and processing as a batch process later with your bank.

Either way, you'll need good Secure Socket Layer (SSL) security to
encrypt the credit card info. A good resource is InstantSSL
(http://www.instantssl.com). They take your compamy info, verify it,
and issue a digital certificate at a considerable savings - and I mean
CONSIDERABLE! - over Verisign or Thawte, which are more than happy to
charge you over $1,000 per year! (Hint: InstantSSL costs less than $200
for a 3-year certificate, and has an adequate guarantee for most
eCommerce applications.)

When you design your shopping cart, I would recommend open source
solutions as a low-cost alternative. Shopping carts do a few basic
things:

Gather product info
Display accumulated products
Allow deletion of individual products or the entire order
Checkout, which typically involves:
Gathering shipping/billing and credit card info
Displaying/choosing shipping options for products in cart based on
weight
Providing a summary of the transaction when the process is complete.

The shopping cart works with a "back-end" database. Here, I would
recommend MySQL, an open source database. (At "free" it sure beats the
heck out of SQL Server or Oracle!) The database allows you to store
captured data from the shopping cart transaction, which can be used for
order processing and fulfillment.

On your Web site, I recommend PHP as a scripting language to allow you
to build the kind of site that interacts with your customers. PHP also
"plays well" with MySQL, and with the added benefit that the two
applications are found on nearly all good Linux-based hosting servers,
it really is a convenient fit.

Final recommendation: Hosting. You want a good hosting service that
provides the tools you need. I recommend TotalChoiceHosting
(www.totalchoicehosting.com), which can run you - for an adequate
service - a whole $5 per month. There are no ads attached, the server
is "yours," and it's left up to you to configure it as you need. There
are a lot of site management tools, including unlimited email accounts,
unlimited MySQL databases, PHPMyAdmin (for administering your MySQL
database) and AWStats, a great all-around statistical "dashboard" for
your server.

Hope that helps, and hope I haven't given away too many secrets! ;)

Dan sends...

John Paul wrote:

I'm thinking of building an e-commerce site in php.

Anyone got any advice in building one?

What is the best way to implement a payment system?

Are any legal issues involved?

Thanks,

John Paul.

[Koncept]

In article <RA******************@fe2.news.blueyonder.co.uk> , John Paul
<Jo****@NOTTELLING.nopewrote:

I'm thinking of building an e-commerce site in php.

Anyone got any advice in building one?

What is the best way to implement a payment system?

Are any legal issues involved?

Thanks,

John Paul.

I advice is "don't bother". There are millions already pre-made e-com
scripts out there you can tweak. Check Google. Check sourceforge. Check
phpclasses.org. Seriously! You are wasting your time reinventing the
wheel here. Why not take advantage of what others before you have
already built and contributed?

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche

[frothpoker]

I have to agree,

Your time would be better spent on building a good back office
solution, or integration with other standard packages like Sage,
Quickbooks etc. and integrating with OScommerce.

Obiron

[Adam]

On Tue, 24 Oct 2006 01:51:57 -0400, Koncept wrote:

>In article <RA******************@fe2.news.blueyonder.co.uk> , John Paul
<Jo****@NOTTELLING.nopewrote:

>I'm thinking of building an e-commerce site in php.

Anyone got any advice in building one?

What is the best way to implement a payment system?

Are any legal issues involved?

Thanks,

John Paul.

I advice is "don't bother". There are millions already pre-made e-com
scripts out there you can tweak. Check Google. Check sourceforge. Check
phpclasses.org. Seriously! You are wasting your time reinventing the
wheel here. Why not take advantage of what others before you have
already built and contributed?

And *my* advice to your advice ... is to *steer totally clear* of O/S
"solutions" (for e-commerce at least). I've tried a few and they're
the biggest P.O.S. I've ever seen. Security nightmares, most of them -
spaghetti-like code which often looks 10yrs old, with patches made by
amateurs that require subsequent patches ... code that requires
register globals to be ON to work ... yadda yadda ...

If you're feeling particularly masochistic, try OSCommerce.

Don't get me wrong - there's tons of totally excellent O/S code out
there - written by unbelievably talented people - but I've yet to find
a decent O/S (or very cheap) e-commerce solution that works well in
today's environment - though I'm open to suggestions!

I'd say it's far better value (from a client's point of view) to spend
their money on a solid commercial product (that has good support) than
you "reinventing the wheel" (I agree on that bit ;-) )

Adam (flame suit ON!).

[readmy]

In article <30**********************@coldmail.com>, ga***@coldmail.com
says...

Koncept, let me cover another aspect. The fellows in here were very
helpful when I posted a question so now it's my turn to give something
back.

I run pay-to-view web sites which is another way of saying I run
e-commerce sites.

You ask what is the best way to implement a payment system. This will
be your biggest headache.

When I set up my first PTV site, I was back in my native New Zealand.
(These days, I'm in the northern hemisphere.) I was the first person in
New Zealand to receive permission to transact credit cards online. My
bank and the card companies invited me in for coffee, it was a sort of
mini-celebrity thing. Wow how times have changed!

Starting last year and continuing today, the card companies have been
introducing new protocols for card-not-present transactions. This has
caused and continues to cause major disruption, inconvenience and
frustration to webmasters.

For many industries, it can now be difficult or impossible to structyre
a payment system. Oh, there are many (hundreds. Thousands!) of web
sites that proclaim "we can have you online in 48 hours." Bullshit!

Here is my advice on how to get a contract with a payment gateway, as
painlessly as possible.

You should put your site online first. A site that is "under
construction" or offline, will not be given much consideration.

Make sure you have a checking account with a regular bank. Ask them
will they offer you a merchant account.

Set up a simple spreadsheet. You will want to keep an easy-to-use
record.

Do a google for "payment gateway". Start the long boring process of
visiting a site, reading what they offer, entering details in your
spreadsheet for future reference and posibly applying for an account.

50% of the sites you visit will be just agents for Authorise.net.
Another 25% will be bullshit sites that want to sell you some expensive
software ‹ the sort of software your correspondents wee discussing
above. Another 20% will be thieves, out of business or whatever. The
nuggess, that last 5% you will follow up on.

Many many industries will not be well-received. Some make sense, others
do not. Read the exclusion list before wasting your time replying to a
gateway that does not want your business.

Alternatively he could just join paypal and be accepting credit cards
within the hour?

I think the original question was a bit more complex and I'd have to
agree with comments made by previous respondents however.

[Nate Lyman]

authorize.net is really easy to get setup just use PHP and the CURL library.

-Nate

<re****@otherlips.comwrote in message
news:MP************************@news-text.blueyonder.co.uk...

In article <30**********************@coldmail.com>, ga***@coldmail.com
says...

>Koncept, let me cover another aspect. The fellows in here were very
helpful when I posted a question so now it's my turn to give something
back.

I run pay-to-view web sites which is another way of saying I run
e-commerce sites.

You ask what is the best way to implement a payment system. This will
be your biggest headache.

When I set up my first PTV site, I was back in my native New Zealand.
(These days, I'm in the northern hemisphere.) I was the first person in
New Zealand to receive permission to transact credit cards online. My
bank and the card companies invited me in for coffee, it was a sort of
mini-celebrity thing. Wow how times have changed!

Starting last year and continuing today, the card companies have been
introducing new protocols for card-not-present transactions. This has
caused and continues to cause major disruption, inconvenience and
frustration to webmasters.

For many industries, it can now be difficult or impossible to structyre
a payment system. Oh, there are many (hundreds. Thousands!) of web
sites that proclaim "we can have you online in 48 hours." Bullshit!

Here is my advice on how to get a contract with a payment gateway, as
painlessly as possible.

You should put your site online first. A site that is "under
construction" or offline, will not be given much consideration.

Make sure you have a checking account with a regular bank. Ask them
will they offer you a merchant account.

Set up a simple spreadsheet. You will want to keep an easy-to-use
record.

Do a google for "payment gateway". Start the long boring process of
visiting a site, reading what they offer, entering details in your
spreadsheet for future reference and posibly applying for an account.

50% of the sites you visit will be just agents for Authorise.net.
Another 25% will be bullshit sites that want to sell you some expensive
software < the sort of software your correspondents wee discussing
above. Another 20% will be thieves, out of business or whatever. The
nuggess, that last 5% you will follow up on.

Many many industries will not be well-received. Some make sense, others
do not. Read the exclusion list before wasting your time replying to a
gateway that does not want your business.

Alternatively he could just join paypal and be accepting credit cards
within the hour?

I think the original question was a bit more complex and I'd have to
agree with comments made by previous respondents however.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com