Rfc
 

a while back we thought a service that monitored third-party billers and switched traffic between them when one went down was a good idea. there were a lot of complaints in the forums about processors going down, throwing errors, declining rampages, etc.

we added a couple of services like transaction recovery so a consumer who was declined at one processor could be redirected to another with a pre-filled form for a second/third shot, gave thought to ip routing so an international transaction could be sent to a particular biller or declined altogether, centralized access control, things like that to add redundancy and help capture more sales. we don't think there are any wrenches to be thrown at the idea, at least none we can't correct, but...

i'm wondering what you guys think of the idea. is it worth pursuing? is it something you'd use on your site or are you content with the "if this biller doesn't work, try this one" types of sales pages? is processor downtime an issue for you (our stats are showing that most billers are pretty reliable, but there are those times ...)? are your approval/decline ratios okay, or would switching between processors based on the a/d ratio not be helpful? would the switch screw up your revsharing if we didn't have a way to consolidate that as well?

thanks for any input.

-shane

nope not really

Don't you think that if one knows about a problem with a cardholder and rejects the card, but another processor accepts the card, not knowing the problem, there will end up being a problem with the card eventually? I mean, you sound like the guy whose idea of "fixing" a blown fuse is simply to put in another fuse without figuring out why the first one blew.

the concept of allowing a retry at a secondary processor was a result of two things: the card being in a fraud table for a chargeback at another site using the same biller or errors with the fraud checking at a particular biller (stale entries, etc). it isn't an attempt to get the charge through at all costs.

-shane