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
>
