Has anyone researched payment gateways for credit cards lately? I'm
interested in any opinions about what good pricing would be and what
products have easy integration into your software (website).

For example, if anyone is using authorize.net, do you like your
reseller and, if so, who are you using?

I have also looked at google checkout, which is not yet feature-rich,
but seems to have good pricing for a service that does not require
that you have a merchant account (with authorize.net you also need
merchant accounts with each credit card provider as well as a reseller
for authorize.net in the mix).

How are you integrating credit cards into your (web) software? (using
what computer language and API)?

These questions might not yet be well-informed as I am just starting
my research, so what other questions should I be asking? Thanks. --
dawn

Totalink, using their modem/Internet-capable MV API. I have it integrated
into a bunch of MV applications I've written including a one-step ship,
charge, and invoice system as well card validation in customer service. We
don't use it yet on our web site due to a lack of sensible up-front freight
charges. We ship such a wide range of products in mix-pack orders that we're
still trying to sort out a freight schedule that won't bury us in
under-charges and also make existing customers angry. Once that happens, we
will be authorizing credit card orders at the time of order placement
instead of shipping time. That will eliminate a lot of card denials that sit
on pallets in the warehouse for 3-4 days and eventually get put back on the
shelf.

Glen

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

I use Mercury Payment via the internet and Drexel Managements software.
The interface was very easy for both debit cards, credit cards and
checks (for check verification and guarantee). Mercury so far has been
able to meet or beat any rate out there. They are a big company handling
Starbusks, Pizza Hut, etc.

Plus the software is FREE and you get commissions each month for the
clients usage. Can't beat that!

Drexel can be reached at 610-924-9290.

Richard Kann
Comp-Ware Systems, Inc.

dawn wrote:

dawn wrote:
<http://nebula-rnd.com/products/financial.htm>

Ron White

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

On Apr 11, 8:25 am, Rick Kann <h... (AT) comp-ware (DOT) net> wrote:
Thanks. I want to minimize the cost of each transaction (as if one
would want to do otherwise), which might mean coding to a service like
authorize.net or ? I'll check out Mercury, since I would guess that
PizzaHut and Starbucks have similar requirements and see what costs
Drexel adds (I am thinking it is not really free per transaction, is
it?)
--dawn

The per transaction is not free, but that is paid byu the client. The
software to interface is free and Drexel does not charge for the
connection. The reason is the dealer (you) would share the commissions
on the client's usage with Drexel. IE: Your customer pays a reasonable
fee (less than he could get at most other places), gets the software
interface for free, and you and Drexel get a monthly income as long as
the client uses the service. I get a nice monthly check that way!

dawn wrote:

Yes, I see how it makes sense for that model, which is not the one I'm
working with right now, but I'll keep it in mind. Thanks. --dawn

On Apr 11, 7:59 pm, Rick Kann <h... (AT) comp-ware (DOT) net> wrote:

On Apr 11, 8:08 pm, "dawn" <dawnwolth... (AT) gmail (DOT) com> wrote:
Dawn,

TotaLink runs on D3, MvBase, uniVerse, & Unidata. It works the same
way on Windows, Unix,
and Linux systems and does not require any additonal hardware other
than the server the client runs
their business on.
It can be used in a variety of market segments including eCommerce,
Retail, Wholesale, and Restaurants.
It works well for small and very large clients (our largest client
averages 5,000 transactions per day).
It is quite simple to implement and maintain.
We interface to clearing houses that use Tsys (Vital), Paymentech, and
Global Payment Systems.
The interface includes debit, credit, and check verification.
This allows the users to remain with their existing provider or switch
to our provider. We have
always been able to save our customers clearing fees when they go
through our network.
VARs receive commissions based on the provider network.

If you want to learn more give me a call at 866-796-7600.
Fred Tuttle

HI
I am interested in your idea of pre-delivery authorisation. A couple of
questions.
If you authorise an amount does this lock that amount out on the buyers
credit card until the transaction is completed? I have seen the problem
arise where a person buying a camera in Singapore has had $4000 locked out
and then not cleared when the final bill of $4250 was settled half an hour
later. This resulted in the person arriving in England and having their
credit card rejected because they were now over their $10,000 limit, and of
course it was exceptionally difficult to rectify.

How easy is it to delete the original amount and enter a new amount entirely
7 days later.

We have the problem that we only know the product ordered not the quantity.
Typically with oil the order is "fill the tank". We have a minimum delivery
charge but the actual result may be wildly different and does occasionally
result in rejected transactions and the associated rejection fees, plus the
muddle of trying to track someone down in working hours.

I love the idea of getting paid commission. This dramatically affects the
price that one needs to charge up front for the software.
Peter McMurray
"Terry Layne" <usenet (AT) laynesoftware (DOT) com> wrote

"Terry Layne" <usenet (AT) laynesoftware (DOT) com> wrote

Terry,

It depends on many things. The order could be picked, packed, and shipped
within the hour or it could take 3-4 hours to be released to the warehouse
for processing. We're working on order flow at the moment and my latest
(long-standing) addition to the process is a pre-prioritised picking queue.
We also recently implemented a central order processing queue for fax and
web orders. Those together help reduce the tendency of CSR employees to
stack up orders and then release a bunch whenever they feel like it. Spiking
the warehouse like that really kills productivity. Shipping the order and
charging the card isn't a timing issue anymore since we implemented XML
shipping with UPS/FedEx. Shipping, charging the card, and then billing the
order takes 4-8 seconds depending on the Internet, our available bandwidth,
the shipping server at UPS or FedEx, and the credit card gateway.

We've gone down a ton of routes and what we really need to do is implement
a cubic quoting and packing instruction system. Ideally, the application
determines which of the standardized boxes available is appropriate for
packing the entire order and also tells the packer exactly how to pack the
order. On the back-side, this gives me accurate shipping info to quote with.
That kind of logic and capability is BIG $$ to purchase these days. It's
mega-company technology that a small business like ours could never afford
off-shelf. I've already done the homework and put together a working design
model. The problem is that we need accurate piece dimensions for every
single SKU we sell. Currently that's atleast a couple years worth of R&D
work, plus we're constantly adding new products. Since we don't stock
everything we sell, we can't physically measure them all. We sell products
for some manufacturers that don't even know how much some of their own
products weigh, so even our vendors/manufacturers are quite often no help at
all.

The best option that I've been able to come up with so far is to limit
order freight quoting below parcel carrier box weight limits. Every item
gets placed into a virtual box, up to 150 pounds. If the order exceeds that,
then a shipping quote has to be requested or the customer can use their
respective shipping account. The only problem with using such logic is when
the box is shipped expedited and the true box count exceeds 1 box. 2 30
pound boxes shipping next day can cost twice the price of a single 60 pound
box. That's good for the customer, because they end up paying a lot less for
expedited freight. It's bad for ground shipments because we have to make up
the difference there. We can't mark up all expedited fees by a percentage.
If we did, the overall pricing for expedited would be abnormally high. I
have lots of real data analysis on this and I'm really close to figuring a
solution for us. That solution probably won't work for anyone else, though.
It's all about tweaking a model based on historical numbers. I'm sure we'll
eventually implement some kind of historical analyzer to suggest new rate
logic/fees as our sales and shipping trends change.

Regarding over-quoting, that works OK for consumer buyers. However, we
sell to government defense contractors, military firms, educational firms,
and huge companies that just won't accept changes in any pricing after the
intial order confirmation. Sometimes we are allowed to, and also asked to,
handle pre-shipping charges by calculating it in the item pricing. However,
that is not an automatic process and we have to automate as much of the
process as possible.

Glen