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
> >
>
>
