Page is a not externally linkable
rocknbil - 3:13 am on Jul 28, 2007 (gmt 0)
Absolutely agree, the payPal hysteria alone is enough to make it a less than wise choice for a serious processor. For the purpose of this discussion, I only mention the IPN methods as a model for what a processor should do for recurring billing. This is the "beauty" of it - in a credit card transaction, the IPN is sent almost immediately. In an eCheck transaction, it's sent several days later when the eCheck clears. Your script is always "listening" for a post from the processor to completely automate renewals. If this model were applied to recurrent billing, the attempted debits would only occur at a time you set for renewal - for example, renew at the hour of expiration, or hour before, or day before, etc. Nah the numbers would have to be in the thousands or hundreds of thousands to create serious issues with the functioning of a site. Unless your 100,000+ members all joined at the same time, the posts to the site should be comfortably spaced apart, depended on the date and time of the pending expiration. Actually the email my customer received from A.N. about the improvements is what got him to thinking. :-) We fully investigated it and it all sounded great until we got to how we update the database, which is why it wound up in this thread.
A note about PayPal... When does PayPal send the IPN? At midnight, or at the precise time of the renewal? If they process several hundred at a time (as a batch), I'm thinking several hundred simultaneous IPN's might do bad things to my site. Do you have the latest version of Authorize.net's Recurring Billing API?