If we set a flag to control renewals then to be useful it must be a flag
that can be set in the client, as far as my system is concerned
I have my registration flag set to non auto for registrations. If a customer
registers using the cash option a registration becaomes pending. If they
register using a credit card or account I then use the register.cgi type
functionality to complete the registration (a pain but until there is an
override flag the only way I can do it)
for renewals I do not offer the cash option (I can't as we can't pend the
tramsaction) - I only offer credit card or account processing
for any change to be useful I need to be able to be able to both pend and
immediate renew depending upon whether it is a cash or account/credit
transaction (the item we have been asking for in registrations for about 9
months in my case - longer in others)
Jim Carey
www.OZbcoz.com discount domain registration
www.iluvoz.com affordable hosting services
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Tiger Technologies
> Sent: Thursday, 15 February 2001 5:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Search Renewals in System?
>
>
> At 2/14/01 10:29 AM, Scott Allan wrote:
>
> >Renewal orders are being re-engineered to be actual orders; this
> will allow
> >for better tracking. In addition to this, they will respect the "process
> >orders immediately" flag. This functionality is in QA right now (should
> >show up reasonably soon).
>
> May I suggest/request that there be a separate flag?
>
> The reason we (and probably most RSPs) don't process initial orders
> immediately is that these people are brand new customers, and therefore
> we want to check them with a human eye towards potential fraud.
>
> However, in the case of renewals, we know that their order a year ago
> wasn't fraudulent. Therefore we trust them a great deal more and are
> willing to process their orders immediately.
>
> Much better, of course, would be the ability to set the flag individually
> for each order from the script. Then we could each do what we wanted on
> individual orders -- for example, if it's an order for only one year, and
> the credit card AVS matches, and we've processed less than five orders in
> the last few hours, I might want to process it right away. But if it's a
> ten-year order, or our registration volume is suddenly unusually heavy,
> or the credit card info doesn't match, I might want someone looking at
> the order and giving the customer a call.
>
> This could be implemented in a backwards compatible manner. You could add
> a parameter to the "renew" and "order" XCP messages that, if present,
> overrides the default RSP setting. If this parameter is not passed, the
> default setting is used.
>
> This sounds like a pretty easy change if you're messing with this stuff
> anyway, and would address a longstanding concern. Just my 2¢.
>
> --
> Robert L Mathews, Tiger Technologies
>
