![]() |
can someone explain cascading billing to me
like giga cash has I think.... cascading billin through 3 proccesers... how does that work... how will the affalite get credit? I don;t understand....... does it automaticly scroll through all proccers or what?
|
BUmp... I am curious still.....
|
I think *true* cascading is like someone signs up, and it will run it through any number of processors until the cc is approved.
so if its declined by one, it automatically tries the next until approved. |
Quote:
|
I'll tell you if you tell me why you do a 50% partnership instead of a 30 or $35 per join. I always thought giving $30 made more money for the owner.
|
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
my offer still stands on the modeling thing :winkwink: |
Quote:
|
Quote:
|
Quote:
|
The way it goes is you have three processors which you agree to use with all three registrations and contracts filled out by you the company. Hire a programmer to incorporated these three processors into your affiliate system so that if the scrub limitations take hold of one processor it circumnavigates to the next one and so on until it gets authorization from that processor to bill the credit card. This sends back to the sale to your affiliate through the script your programmer made.
Although Im not sure 50% recurring is better than $30 or $35 a join... I think you can make more money with $ per join instead you should look into it. |
Quote:
|
Quote:
to me it makes sense to process initial transactions through your own merchant account...saves$$ then process recurring through a 3rd party to spread risk. but the tracking issue is a moot point, something thats easily handled at the integration level |
Quote:
|
Quote:
It works the same way as the CC processors systems do but its one level up on the chain. The affiliate program has one or several master accounts with the actual CC processors - and tracks the data and distributes to the appropriate affiliates. |
Quote:
LOL :thumbsup |
Quote:
I dont think so, you'd have your own custom back-end that would handle affiliate tracking accross all processors and you'd pay only one check. |
Quote:
|
Quote:
|
Quote:
|
Quote:
Its basically simply a matter of pulling data back and forth.... with your back-end consolidating all apllicable information from all three processors |
Quote:
|
In reply to most all of the above questions, and also to clarify.
Gigacash uses MPA2's cascading feature whereas a credit card will go through 3 processors before giving up on a transaction using credit card. It will then take you to alternate billing mechanisms that might work for that particular surfer. In Gigacash's instance we implemeted MPA2 cascading into Gigacash's existing affiliate program - this has resulted into Gigacash making more money in terms of much higher signup ratio for any webmaster sending traffic to their affiliate program. Win win for everyone, so go and sign up if you want to stop leaving money on the floor with your existing affiliate program. ;-) As for MPA2 and programs using it. You as the affiliate only need to sign up ONE TIME and with this you now have access to not only three processors in a PURE cascading environment, but also check processing via Electracash as well as NoCreditCard as a dialer. One affiliate code - three major processors (Epoch, CCBill and PSW), ACH (checks) processing (Electracash), and NoCreditCard. And I emphasize, all in one affiliate code! No need for the affiliate to sign up for anything else but for the program using the MPA2 backend. If curious about who is currently using it, send me a mail and I will guide you to them. Currently webmasters using MPA2 as their affiliate program can offer "Per Signup", "RevShare" as well as "Per Click" This of course only tell you about some of the features around the affiliate and cascading part of the program. There are lots and lots of more features that helps to simplify an affiliate program owners life to great extent. Spam this thread with more questions regarding these things and I will be more than helpful and answer them all... Anyone? |
Did that explain it? :)
|
It bills the surfer on all three processors at the same time.
Chances are the surfer wont be able to cancel all of em let alone notice them so you will be ok. If ya figure one out of 3 surefers will notice and call to get it fixed. You credit 2 processors and keep the one. But ya figure 2 out of three surfers wont know he's been charged 3 times. Easy money. |
If you want to have an MPA2 type system coded we can get you it done for between $5-$6k tunraround time would be something like 30 days max :thumbsup
Feel free to drop an email to our lead developer [email protected] Regards, Lee |
Quote:
Can european webmasters use it (you use epoch who says europeans are bastards). I also assume it no longer works with paypal. |
Quote:
Not sure of the specifics surrounding the sale though. Regards, Lee |
Quote:
|
Quote:
Way i look at it, if you plan on being in business for 2 years that works out to a cost of $300 x 24 months = $7200 on the monthly deal which is a good option for those who can not afford to pay for a custom solution upfront :thumbsup But if ya can afford to invest between 5k and 6k then custom would be the way to go imho But i am biased :thumbsup Regards, Lee |
Quote:
|
Quote:
|
I have been considering purchasing a cascading processing system, however I am now having a problem seeing where the advantage of cascading processing is in today's volatile cc transaction processing environment.
Is the cascading mainly to circumvent what might be considered heavy scrubbing by one processor by resubmitting it to a less demanding processor... until you find one that accepts the transaction? ... or is it to use as a backup to protect against processors servers being down and not responding? If it is for the latter reason, are that many of them down all that often? If it is to just give transactions a second, third or fourth chance by sending it to a softer scrubbing processor, aren't you taking a big risk? If, as I understand it, the 3rd party processors are in fact now passing on chargeback fees and fines to the site operators, and MC/visa now require that the chargebacks and returns be tracked to the individual site domains (and site owners) what is the sense of having cascading processing? It seems that if you put a real liberal low-scrub processor into the end of the "cascade" mix, (or if any one of the processors had some kind of a problem that led to a large number of chargebacks on your account) you would then be jeopardizing ALL of your processing relationships. If you go way over on chargebacks because of one liberal processor, or technical problems at one, and end up getting fined or canceled wouldn't it in theory affect your 3rd party relationships with ALL your processors who may process for those same domains, even though you may have always been within the Visa/MC allowances on the domains with them? and .. if you also happen to have your own merchant account in the cascade mix, as well as use the aggregates, you would/could be jeopardizing it as well. It seems like by using a cascading processing system you risk having "one bad apple spoiling the whole damn bunch" In the long run it seems like cascading processing might actually be a higher risk to the longevity of your business. I also don't see why any processor would want to be a part of, or especially at the bottom of, a cascading list of processors, knowing that they might get all the high-risk stuff that nobody else wants. Can they make enough on declined transactions to make it worthwhile enough to risk bad transactions somehow slipping through and raising their overall cb ratios? Is cascading really all it is cracked up to be? Any thoughts on this? |
i have heard that the monthly price of MPA2 will go up from $300 a month depending on the amount of joins you pull a month. can you give me the rates on this oystein?
|
If you want to use a cascade, you can use our soft: WebAdmin You can use ANY billing in the cascade!!! And you will not pay each month for it. Only once...
|
Quote:
dude you link and sig do not work. page not found. |
Note that even with the cascading system it requires resubmit
action from the user. With the current rules it's not allowed to automate this. So if a transaction is declined from processor one The user will get a prefilled form EXCLUDING CC INFO as it's not allowed to store CC info if you're NOT an IPSP. The user then needs to fill out his CC details again and resubmit the form to the next processor. I thought I should add this as it seems that this is not clear to everyone. DynaMite :2 cents: |
All times are GMT -7. The time now is 03:20 PM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123