right but 700 dollars is a bit extreme.....
----- Original Message -----
From: Joe Rhett <[EMAIL PROTECTED]>
To: Rodney Payne, Support Team <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 28, 2000 11:52 AM
Subject: Re: Implementing credit card processing...
> Not intending to be rude, but why should someone work for free so that you
> can make money from their efforts?
>
> People seem to have completely mistaken the notion of what free software
is
> about. And it ain't giving away our time to make others rich. It's to make
> better software available to institutions and people who aren't trying to
> get rich from our efforts.
>
> (coming from the mouth of one who both assists on free software projects
> and codes for money)
>
> On Fri, Jul 28, 2000 at 01:27:18AM -0500, Rodney Payne, Support Team
wrote:
> > Does anyone have a credit card solution that they are willing to shows
us,
> > without it costing an arm and a leg, this group is suppose to help each
> > other
> > but all of the quotes I have gotten - being a small ISP I would have to
get
> > a loan to cover the expense.....
> >
> >
> > ----- Original Message -----
> > From: Vladimir Jebelev <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, July 27, 2000 12:13 PM
> > Subject: Re: Implementing credit card processing...
> >
> >
> > >
> > > You'd want to break down the billing step into 2 stages:
> > > 1. authorize credit card - i.e. make sure the card is valid and there
is
> > > enough credit
> > > 2. actually acquire funds.
> > >
> > > So:
> > > - do authorization
> > > - if fails, then abort
> > > - register/renew/transfer domains
> > > - calculate number of succesful registrations
> > > - recalculate the amount the user owns you (it could be less that you
> > > originally authorized for)
> > > - acquire funds
> > > - if fails (which is very unlikely, since authorization was
successful)
> > > then send a notification to customer support folks, so they can
> > > try to re-submit credit card later, and it fails again,
unregister
> > > domains
> > >
> > > All credit card processors that I know (CyberCash, AuthorizeNet,
> > > CyberSource, Signio, etc.) support sush 2-step procedure, and in fact,
you
> > > are not supposed to acquire funds before you deliver the goods or
service
> > > you are billing for: in our case, register domains. Using void or
> > > especially return (and in fact, you can not use return unless the
> > > transaction is settled by the time you try to refund some money - and
> > > with CyberCash it's several hours after the transaction ), is really
not
> > > the right thing to do in this case.
> > >
> > > Vlad
> > >
> > > On Thu, 27 Jul 2000 [EMAIL PROTECTED] wrote:
> > >
> > > > domain_charge -- charge a credit card for the number of domains
> > processed.
> > > > This will need to know the price per domain, the number of domains
> > > > registered, the credit card / billing info, and somehow create an
order
> > id
> > > > and return a success / fail code. The price per domain and number
of
> > > > domains I can pass as arguments, or simply multiply them and pass
the
> > > > final price. The number of domains to register is easy to get, but
> > there
> > > > are other snags, and also with the order_id.
> > > >
> > > > domain_credit -- similar to domain_charge, or possibly just another
> > > > option to that function instead; credits a credit card for a given
> > amount.
> > > >
> > > > The problematic issues are as follows:
> > > >
> > > > When a domain is registered successfully, we get billed, and are
> > > > responsible for that domain. Therefore, the client should always
> > > > get billed for this first; otherwise, we could be liable for many
> > > > "free" domain registrations.
> > > >
> > > > Therefore, the client's credit card should be checked or billed
first.
> > > > We're using CyberCash for this, and AFAIK, we'll have to bill them
for
> > > > the amount. We also want this to be completely automated, so even
if
> > > > we could use batch transactions, we wouldn't want to review them.
> > > >
> > > > However, if the client gets billed for, say, five domains and two of
> > them
> > > > fail for whatever reason, we need a way to give them that money
back.
> > > > Hence, the domain_credit function: this could be implemented with
the
> > > > CyberCash 'return' or 'void' function, and I'm leaning towards
'return'
> > > > here. But I don't have much experience with CyberCash yet, so we'll
> > see.
> > > >
> > > > Now CyberCash and OpenSRS both have some notion of using order ids
to
> > > > track customers and customer information. I think this is a great
idea,
> > > > and the right way to do this would be to use one id, and potentially
> > store
> > > > this information in a database somewhere, as needed. However, the
> > OpenSRS
> > > > id is created *after* the transactions take place, and the CyberCash
id
> > > > would be needed beforehand, to charge the credit card.
> > > >
> > > > So either there would have to be two separate ids, (you could put
them
> > > > both in the database, but it would be a messy solution) or you'd
have to
> > > > be able to specify or query for an id for OpenSRS, or change one in
> > > > CyberCash, or bill the client later (but be absolutely sure they
have
> > the
> > > > requisite funds). I don't know if there's a good way to do any of
these
> > > > things, so we might be stuck with two order ids. Also, I don't know
if
> > > > we'll be able to use mauthonly transactions; apparently this depends
on
> > > > our setup with the bank, and I have a feeling we'd only be able to
use
> > > > mauthcapture.
> > > >
> > > > I think that's everything, but let me know if I missed something.
I'm
> > > > somewhat new to CyberCash and OpenSRS.
> > > >
> > > > Any questions or comments?
> > > >
> > > > Anyone want to help me design or develop this?
> > > > ---
> > > > Peter Baylies
> > > > American Data Technology
> > > >
> > >
> > >
>
> --
> Joe Rhett Chief Technology Officer
> [EMAIL PROTECTED] ISite Services, Inc.
>
> PGP keys and contact information: http://www.noc.isite.net/Staff/
>
