Multiple Billing processors - GoFuckYourself.com

Mikeee · 03-13-2003, 01:02 PM

How does that work exactly, do you designate a different members folder for each processor because of possible conflict with password files?

Also, I'm looking for a secondary processor, not iBILL. So if you have any recommendations and really good experiences, please let me know.

Mikeee · 03-13-2003, 01:19 PM

help!

NetRodent · 03-13-2003, 01:24 PM

We use single common database for all of our members regardless of processor.

Other people use multiple htpasswd files for a common members area (I think you need a modified version of auth_basic for this though).

Nobody I know of uses complete copies of their site for different processors.

res · 03-13-2003, 01:29 PM

http://www.yambo.biz and tell them res sent you...

buran · 03-13-2003, 01:33 PM

We use one database regardless of processor as well. All the processors give you perl scripts which handle the actual adding and removing of the user data. In my case I replaced all that with PHP which handles the users in mysql. But there's no reason you couldn't use the scripts they give on the same .htpasswd file. Well, there might be file locking issues... YMMV. Storing your users in SQL lets you know more about them anyway.

We have affiliate software for sale which handles all of this and much, much more. Like, now how are you going to have your affiliates check their stats when you've got more than one processor? What about payouts, customer service, product codes, sites, brands, etc? Hit me up on ICQ if you're intrested, 1240050.

JimW · 03-13-2003, 01:34 PM

Mikeee,
you could also use a common .htpasswd file.

Make sure all your processor's addpassword scripts are writing to this one file.

Kimmykim · 03-13-2003, 01:34 PM

You'd have an easier time with all processors writing to the same set of pass files --

I would suggest that you create what I call an options page for your declines -- since a bank decline will be a bank decline no matter where you shop the cc...

On this 'options' page, which should be created by region I would steer the surfer towards ways he can join if his cc is declined based on where he lives.

Of course I would also set my join pages up initially to get the most thruput I could from surfers based on their location.

NetRodent · 03-13-2003, 01:38 PM

There is one catch with using a single htpasswd file with multiple processors. You have to be sure that once a username is added to your file, another processor can't try to add a user under the same username.

This is one of the reasons that I prefer processors who don't do password management.

03-13-2003, 01:02 PM	#1
Mikeee Registered User Join Date: Jun 2002 Posts: 516	Multiple Billing processors How does that work exactly, do you designate a different members folder for each processor because of possible conflict with password files? Also, I'm looking for a secondary processor, not iBILL. So if you have any recommendations and really good experiences, please let me know.

03-13-2003, 01:24 PM	#3
NetRodent Confirmed User Join Date: Jan 2002 Location: In the walls of your house. Posts: 3,985	We use single common database for all of our members regardless of processor. Other people use multiple htpasswd files for a common members area (I think you need a modified version of auth_basic for this though). Nobody I know of uses complete copies of their site for different processors. __________________ "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." --H.L. Mencken

03-13-2003, 01:33 PM	#5
buran Confirmed User Join Date: Mar 2002 Location: how'd I get here? Posts: 264	We use one database regardless of processor as well. All the processors give you perl scripts which handle the actual adding and removing of the user data. In my case I replaced all that with PHP which handles the users in mysql. But there's no reason you couldn't use the scripts they give on the same .htpasswd file. Well, there might be file locking issues... YMMV. Storing your users in SQL lets you know more about them anyway. We have affiliate software for sale which handles all of this and much, much more. Like, now how are you going to have your affiliates check their stats when you've got more than one processor? What about payouts, customer service, product codes, sites, brands, etc? Hit me up on ICQ if you're intrested, 1240050. __________________ [this signature intentionally left blank]

03-13-2003, 01:38 PM	#8
NetRodent Confirmed User Join Date: Jan 2002 Location: In the walls of your house. Posts: 3,985	There is one catch with using a single htpasswd file with multiple processors. You have to be sure that once a username is added to your file, another processor can't try to add a user under the same username. This is one of the reasons that I prefer processors who don't do password management. __________________ "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." --H.L. Mencken

03-13-2003, 01:19 PM	#2
Mikeee Registered User Join Date: Jun 2002 Posts: 516	help!

03-13-2003, 01:29 PM	#4
res Confirmed User Join Date: Nov 2002 Location: Europe Posts: 1,118	http://www.yambo.biz and tell them res sent you...

03-13-2003, 01:34 PM	#6
JimW Confirmed User Join Date: Dec 2002 Location: Dallas, TX Posts: 422	Mikeee, you could also use a common .htpasswd file. Make sure all your processor's addpassword scripts are writing to this one file.

03-13-2003, 01:34 PM	#7
Kimmykim bitchslapping zebras!!!!! Industry Role: Join Date: Jun 2001 Location: In a shack by the beach Posts: 16,015	You'd have an easier time with all processors writing to the same set of pass files -- I would suggest that you create what I call an options page for your declines -- since a bank decline will be a bank decline no matter where you shop the cc... On this 'options' page, which should be created by region I would steer the surfer towards ways he can join if his cc is declined based on where he lives. Of course I would also set my join pages up initially to get the most thruput I could from surfers based on their location.