Re: accepting online payments
by "Keith Sellars" <Keith(at)webgraffix.com>
|
| Date: |
Mon, 11 Mar 2002 08:53:24 -0500 |
| To: |
"HWG Basics" <hwg-basics(at)hwg.org> |
| References: |
on king |
| |
todo: View
Thread,
Original
|
|
Darrell,
I would like to commend you on a VERY good explanation. Related to your
explanation of "shopping carts":
We have developed what I call our "Economy Cart". It functions like a
shopping cart, except it does not use a session or database of any type. It
will calculate shipping (and even allow for shipping upgrades), calculate
sales tax based on state, allow for multiple quantities, and allow for
multiple options per item. It sends out emails to the site owner and
receipt emails to the buyer. The downside is that the viewer cannot roam
through the site and have the information retained in the shopping cart and
that the cart cannot handle large quantities of items. The advantage is
that the cost is significantly lower than a full fledged shopping cart
installation.
We have installed this type of system using realtime and manual credit card
processing.
Jim, if you'd like to see what I'm talking about, look at this site,
http://www.helmetsunblocker.com . It is a very simple, basic site that
allows the users to order online with credit cards. The site owner then
processes them all manually. The site gets LOTS of traffic since it is
advertised in motorcycle magazines and also gets LOTS of orders. Just an
example that simplicity CAN work in the right situation.
HTH,
Keith D Sellars
WebGraffix
www.webgraffix.com
"Making database sites seem easy"
----- Original Message -----
From: "Darrell King" <darrell(at)webctr.com>
To: "HWG Basics" <hwg-basics(at)hwg.org>
Sent: Monday, March 11, 2002 8:22 AM
Subject: Re: accepting online payments
> Here's my mini-FAQ (all MHO):
>
> 1) Order Form
>
> An HTML form that submits the visitor's selection to a server-side
> application that will process those selections to calculate final totals
and
> present the user with a payment form.
>
> 2) Shopping Cart
>
> This is software used to allow a visitor to "collect" merchandise while
> browsing the site. It maintains session for a specific purpose: without
it,
> the site would have no way of knowing what the visitor wanted to buy when
> checking out. Obviously, this is mostly useful in a site where the
> merchandise is scattered over more than one web page. If everything is on
a
> single page, and the visitor is going right from selection to checkout, a
> cart is overkill.
>
> 3) Payment Form
>
> An HTML form that collects the user's payment information
>
> 4) Gateway
>
> A service that processes online transactions, accepting the user's payment
> information (currently eCheck or Credit Card), often authorizes the user's
> credit, and forwards the appropriate information along to the merchant
> account provider for collection and transfer.
>
> 5) Merchant Account
>
> An account that allows the merchant to transfer funds electronically
between
> holders.
>
>
> Note that nothing above includes the actual inventory, unless you count
the
> entries on the order form. Inventory (such as a database of merchandise)
is
> actually the foundation of the store, but it's not really part of the
> transaction process except in a supporting role for the order form or
cart.
>
> Often, the term "shopping cart" has come in common usage to cover the
entire
> system above, when really it's just a small part of it. Understanding
the
> components of the system may help you make more appropriate choices for
> yourself and your clients.
>
> To accept simple payments online, such as payments on account or other
types
> that do not involve a widespread inventory, you do not need a cart. You
> will need a form from which users can submit their payment, a gateway for
it
> to be submitted to (if processing automatically!), and a merchant account
to
> move the money for you. We use AuthorizeNet.com for the gateway, and an
AN
> dealer for the merchant account.
>
> If you are processing card manually, you can even skip the gateway and
> merchant account and simply store the data server-side for retrieval or
> email it to yourself using PGP encryption. Both methods have some
> security-related responsibilities involved for you. Check with your
> existing merchant provider, though, as I believe some of them expressly
> forbid you to submit debits collected from an online source.
>
> PayPal also has an easy-to-use service, although there is the restriction
> that both customer and merchant must be members. Joining is relatively
> painless...:). As an order form, they often supply you with buttons that
> you can paste into your web pages that are each worth a preset amount.
>
> D
>
>
>
>
>
> ----- Original Message -----
> From: "Jim" <jimb(at)aci.on.ca>
>
> Good morning all.
>
> I am working on a site that will seen need to accept online payments for
the
> service of using our site to list their vehicle to sell. I have browsed
> through the archives and looked on the web for info but to be honest I am
a
> bit confused :-(
> I keep reading that I need a merchant account , a shopping cart, etc, etc
> but is this all necessary to accept credit payment?
> Could someone please let me know how to go about simply accepting credit
> card payments through a form on our site?
>
> Jim
> http://www.exoticautoinc.com
>
>
>
>
HTML: hwg-basics mailing list archives,
maintained by Webmasters @ IWA
This page is part of a preserved archive of archives.hwg.org. The site is no longer active and its content is not maintained. For enquiries about this archive, write to archive(at)iwanet.org.