PHP-building my own shopping cart

Question

Hi all
Has anyone tried to build their own shopping cart?
Besides a secure space on a server, does anyone know a little
bit about what building a shopping
cart entails?
I am using PHP and I would look into integrating the shopping
Cart with authorize.net...
Authorize.net has some documentation for developpers about
this, so I'll look into it, but I just
wondered if this was something anybody had done, and if this
was accessible to someone like me (I
know my PHP pretty good) if this is way over-the-top
complicated.
seb ( [email protected])
http://webtrans1.com | high-end web
design
Downloads: Slide Show, Directory Browser, Mailing List

Answer 1

thanks a lot for this info gareth
gareth wrote:
>>> If there's come particular technology beyond
PHP, or some specific
>>> protocol, to thansfer the
> shopping cart info (including CC number) to the
institution that processes
> the transaction.
>
> Well HTTPS is always used to encrypt the transaction in
transite. Apart from
> that it really depends on the financial institution your
details with. A
> large proportion of payment providers actually take the
card details on
> their site. You pass across the customers details, name,
address, order
> number, order value etc to the provider site, and then
they take the card
> details on their site, and then pass back a response to
you with the order
> number (or some other unique reference), saying if the
transaction has
> succeeded or not. This way, you actually have no contact
with the credit
> card details. This method is prefered, as it takes a lot
of responsibility
> off you, you don't have to try and store the details
securely or pass the
> details securely.
>
> Various methods are used by the institutions when
passing the details. Its
> always by post, by some provide code that you run all
the fields through
> that you send to them with a secret key, which creates a
hash that you send
> to them as well. At their end, they run the details
through the hash
> generator with your key, and if the two hash values
don't match then they
> know the data has been tampered with in transit (eg the
customer saving your
> checkout page, changing the order amount, and then
submitting the data from
> their own server). They then hash the reponse they send
back to you, and
> then you hash it and compare the values, so you can be
sure the info coming
> from the payment provider hasn't been tampered with.
Usually the code is
> available in a variety of languages, and most give PHP,
although HSBC use C,
> which you can run through PHP (although I actually
created an extension to
> PHP to generate the hash).
>
>> You can always just send POST vars, in the format
they require, to the
>> transaction processor, right?
> Or is there something else at play?
>
> Yes, its almost always sent to the institution as a
simple form POST. You
> just need to pass a unique value, so that they can pass
it back and you can
> link the response to the customers order at your end.
>
>> And it's just a matter of knowing how this response
is formatted, to deal
>> with it, right?
>
> Yes, usually they send the data to an address on your
server you provide, as
> POST data. So, its simple to read it using PHP.
>
>> thanks for this info... All in all I was just
wondering what's the big
>> deal about building a
> shopping cart, compared to, say, builing a CMS.
>
> No problem, to be honest with you, and IMHO its really
not that difficult,
> less so than building a complete CMS. It used to be,
years ago, but the
> financial institutions have made things easier now, and
provide all the
> processing for you. The main problem that put people off
was security, but
> nowadays merchants don't take credit card details
themselves, so its not a
> major issue.
>
> It really depends on the payment provider, some are
easier than others, the
> banks own systems tend to be more complex than other
parties such as
> Worldpay.
>
seb ( [email protected])
http://webtrans1.com | high-end web
design
Downloads: Slide Show, Directory Browser, Mailing List