Ay Ay! It's really insane that such a system doesn't exist.. The only
explanation I can come up with is that the programmers just "stitched" on
the whole renewal system to have 'something' there... forget about
actually being usefull.
Which is why I'm about halfway done with a merged renew.cgi reg_system.cgi
with signio payflow pro. Since I got word from support that those features
won't be appearing "anytime soon". Meaning within a month of two.
Hopefully I'll be done within a week or two... Just in time to catch the
0-31 day transfer ranges... argh!
Alex
Jim Carey writes:
> 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: owner-dev-list@opensrs.org [mailto:owner-dev-list@opensrs.org]On
> > Behalf Of Tiger Technologies
> > Sent: Thursday, 15 February 2001 5:19 AM
> > To: dev-list@opensrs.org
> > 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
> >
>
Alexey Zilber
DAYAK
Need to register or transfer a domain?
www.dayak.com charges only $15/year.
40 megs of hosting space? $10!
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:36:15 EDT