Because they are allowing a sponsor to be able to add form variable that will override the cookie that holds the info WHO sent the surfer. So the problem is their way of handling form+cookies that are sent.
Right, and my example of changing the link to the join page to set a new cookie and new PA link in the form are just as dangerous. I can't believe you are wasting so much time on this.
If you can't trust the sponsor don't use them, it still isn't a CCBill issue.
If a cookie exist, CCBill should not use the variable that can set the webmaster ID.
If a cookie doesn't exist, they can use it.
There are 10 other ways to shave with ccbill...
No matter what ccbill does it will still be possible to shave. Same goes for any other affil processor/software, it's not possible to have an affiliate system where shaving is impossible...
Several got caught cheating when CCBill made it publicly available if and how long you were getting paid for signups and rebills.
Yeah.. but i doubt those are the ones shaving you
That really just proves my point, when they where able to hide it yes,,
Now that CCbill closed that hole and made it easy to check do you think that would be anyones prefered method of shaving.. NO, too easy to discover right.. Same with the Join page, too easy to discover too if theres shaving going on so anyone with a little sence would do it some other way.. Like hosting their own join page and making the shave after the join..
There are 10 other ways to shave with ccbill...
No matter what ccbill does it will still be possible to shave. Same goes for any other affil processor/software, it's not possible to have an affiliate system where shaving is impossible...
Does that automatically mean that softwares should not be improved or limiting the possibilities for shaving?
I believe it's better the fewer ways there are to shave.
Does that automatically mean that softwares should not be improved or limiting the possibilities for shaving?
I believe it's better the fewer ways there are to shave.
well, it turns out that there are legitimate uses for setting ccbill_referer variable... removing possible shave feature would also reduce ccbill's functionality...
well, it turns out that there are legitimate uses for setting ccbill_referer variable... removing possible shave feature would also reduce ccbill's functionality...
Tell me the legitimate reason to override the cookie and assign the signup to someone else?
Tell me the legitimate reason to override the cookie and assign the signup to someone else?
For example, it might be useful if an affiliate program wants to start paying pay per signup and process the payments themselves. So the pay per signup webmasters might send traffic like this: http://www.site.com/?id=123&pay=pps
Then, when the script sees pay=pps, on the join page it sets ccbill_referer to a house account, and then the rest of the sale tracking process is done using a custom script.
For example, it might be useful if an affiliate program wants to start paying pay per signup and process the payments themselves. So the pay per signup webmasters might send traffic like this: http://www.site.com/?id=123&pay=pps
Then, when the script sees pay=pps, on the join page it sets ccbill_referer to a house account, and then the rest of the sale tracking process is done using a custom script.
Then CCBill link codes are not used = no cookie is set.
For example, it might be useful if an affiliate program wants to start paying pay per signup and process the payments themselves. So the pay per signup webmasters might send traffic like this: http://www.site.com/?id=123&pay=pps
Then, when the script sees pay=pps, on the join page it sets ccbill_referer to a house account, and then the rest of the sale tracking process is done using a custom script.
why would it do that? You can't track the productive traffic/affiliates that way.
Since they still process with CCBill just turn on the per signup option in the admin.
I meant a situation like installing an affiliate script (mpa3 for example) and not forcing people to change all their old ccbill links. So new webmasters use mpa3, old webmasters continue getting credit for all sales generated through old ccbill linking codes.
I meant a situation like installing an affiliate script (mpa3 for example) and not forcing people to change all their old ccbill links. So new webmasters use mpa3, old webmasters continue getting credit for all sales generated through old ccbill linking codes.
but then what happens to old affiliates who created 1000s of tgp galleries with the old ccbill links? They have to change them? Or do those links not work anymore?
How can there be so many morons that have so little technical knowledge?
CCBill should only use that variable IF there is NO cookie.
Interesting CCBill haven't commented yet...
yea you know how ccbill should run thier business.
this thread is funny
there are a million ways for someone to shave if they really want to, some people were smart enought to find a way you could shave using ccbill and now think ccbill has to change things in thier system because there is a slight possibility that someone could use to to shave?
LOL
I would be suprised if someone from ccbill even comments here.
but then what happens to old affiliates who created 1000s of tgp galleries with the old ccbill links? They have to change them? Or do those links not work anymore?
Usually what sponsor do is that they have the old CCBill link code go to a separate tour with the old join page, no need to fiddle with the cookie or anything like that.
Or they force the webmaster to change link codes since they are doing cascading billing (you mentioned MPA3) now and have their own join/billing page, not CCBill's.
Tell me the legitimate reason to override the cookie and assign the signup to someone else?
Just thinking, Couldn't this actually be used as fraud protection..
Let's say you have some advare/spyware installed that changes refferal codes.. Now the adware overwrites the cookie with your refferal id, but the extention then overwrites the cookie changing the sale back to you..
That Imo. would be a pretty damn valid reason for overriding the cookie
Just thinking, Couldn't this actually be used as fraud protection..
Let's say you have some advare/spyware installed that changes refferal codes.. Now the adware overwrites the cookie with your refferal id, but the extention then overwrites the cookie changing the sale back to you..
That Imo. would be a pretty damn valid reason for overriding the cookie
That's a valid reason, for spyware that changes cookies. But if you weigh it against the shave reason, which is more likely to happen, I don't think it's worth it.
There's spyware that changes form variables directly, then you're pretty much screwed either way
Personally I dont see why CCBill should comment in this thread. This is not a CCBill issue, this is a matter of trust between the affiliate and the sponsor.
If a sponsor wants to steal from their affiliates, there are as many ways to do it as there are sponsors and affiliates. Billing companies and affiliate program software companies get jumped on day in and day out by affiliates for any and every little thing, whether or not it's a valid issue.
If you don't like your sponsors, or you can't trust your sponsors, start your own paysites and send your traffic to yourselves. Then you can be sure that you're getting exactly what you should. Oh wait, you still can't be sure, there are trojans, spyware, surfers that delete the affiliate links out of the url and re-type in the site name, and countless other things that can happen to fuck up a sale.
Or better yet, fuck CCBill, go get your own merchant account, custom write your own scripts for your own paysites and change up your link structure (after all it's your own traffic) every day or every week so the spyware thieves can't steal your joins, the billing companies can't steal your joins and the sponsor programs can't steal your joins.
If you want to replicate it, all the info is in my post. But I'm not going to say straight out what form variable you need to add. But it's very easy to find.
If it is so easy to find shut the fuck up and stop biching to ccbill about it. Even if they fix this there are always other ways to shave.
At least with this you can find it yourself and then out the program (which you should be doing, by not outing the program you are letting them fuck others)
Personally I dont see why CCBill should comment in this thread. This is not a CCBill issue, this is a matter of trust between the affiliate and the sponsor.
If a sponsor wants to steal from their affiliates, there are as many ways to do it as there are sponsors and affiliates. Billing companies and affiliate program software companies get jumped on day in and day out by affiliates for any and every little thing, whether or not it's a valid issue.
If you don't like your sponsors, or you can't trust your sponsors, start your own paysites and send your traffic to yourselves. Then you can be sure that you're getting exactly what you should. Oh wait, you still can't be sure, there are trojans, spyware, surfers that delete the affiliate links out of the url and re-type in the site name, and countless other things that can happen to fuck up a sale.
Or better yet, fuck CCBill, go get your own merchant account, custom write your own scripts for your own paysites and change up your link structure (after all it's your own traffic) every day or every week so the spyware thieves can't steal your joins, the billing companies can't steal your joins and the sponsor programs can't steal your joins.
So far no one has come up with a legit reason for having this "feature".
here is one
when i was running an affilite PPS program, to limit my exposure, i would make deals with affilites (mailers mostly) that during a certain period, i would pay out X amount per signup , up to 80 singups, or 250 signups, or whatever...i told them to keep an eye on the signups and to switch out my codes once that limit was reached, if they oversent, i was able to make the payment adjustment directly in my software, but i can see how people using the ccbill referrer system can do the coding on their end to switch out affilite codes once a # of signups has been surpassed, all with the understanding and agreement of the affilite that this is how it is being done
I asked a question. If you don't have anything to contribute, you know what to do.
I'm not talking about sponsors here, I'm talking about C C B i l l and their way of handling the join process.
My contribution made the most sense of anyones, so if you can't handle it then you know what to do. Just make sure you don't fall off your high horse and break a leg on soap box in the process.
My contribution made the most sense of anyones, so if you can't handle it then you know what to do. Just make sure you don't fall off your high horse and break a leg on soap box in the process.
Do you believe in minimizing possibilities to shave?
when i was running an affilite PPS program, to limit my exposure, i would make deals with affilites (mailers mostly) that during a certain period, i would pay out X amount per signup , up to 80 singups, or 250 signups, or whatever...i told them to keep an eye on the signups and to switch out my codes once that limit was reached, if they oversent, i was able to make the payment adjustment directly in my software, but i can see how people using the ccbill referrer system can do the coding on their end to switch out affilite codes once a # of signups has been surpassed, all with the understanding and agreement of the affilite that this is how it is being done
Interesting. That's one use for it.
Did you only host the join page or the whole tour?
Swedguy, you are absolutely correct in this, your goal is honorable and I hpope the people who really need to understand your point catch it - ie, ccbill.
Listen everyone, what he's saying is there is a flaw in the ccbill system that would be extremely easy for them to fix if they chose to. Assuming they decide to fix this, the end result is a cleaner system that is more beneficial to webmasters - unless you run a paysite that uses the technique in question here, you should be 100% behind Swedguy.
Did you only host the join page or the whole tour?
thanks, whole tour, you can really only do so much restrictions without affecting the functionality of a system
are you really going to demand that the 70% or more of programs using the *last cookie set gets the credit* rules change them to something not as effective overall because there is a possibility that they may insert their own cookie on the join page? no, of course not
Swedguy, you are absolutely correct in this, your goal is honorable and I hpope the people who really need to understand your point catch it - ie, ccbill.
Listen everyone, what he's saying is there is a flaw in the ccbill system that would be extremely easy for them to fix if they chose to. Assuming they decide to fix this, the end result is a cleaner system that is more beneficial to webmasters - unless you run a paysite that uses the technique in question here, you should be 100% behind Swedguy.
I am.
very nicely said, Wolfy.
Need a Text Writer?
Blogs|Reviews|Descriptions|Paysites|TGP's|Stories ICQ: 397892500
Swedguy, you are absolutely correct in this, your goal is honorable and I hpope the people who really need to understand your point catch it - ie, ccbill.
Listen everyone, what he's saying is there is a flaw in the ccbill system that would be extremely easy for them to fix if they chose to. Assuming they decide to fix this, the end result is a cleaner system that is more beneficial to webmasters - unless you run a paysite that uses the technique in question here, you should be 100% behind Swedguy.
I am.
It has legit uses as posted above...... so is it a flaw or a feature that *CAN* be misused? I for one dont see it as a flaw, but rather a feature that *CAN* be misused. I can think of at least 10 more uses for it other than what has been mentioned. CCBill is the processor, they provide tools to their clients. How their clients use those tools is up to them.
It has legit uses as posted above...... so is it a flaw or a feature that *CAN* be misused? I for one dont see it as a flaw, but rather a feature that *CAN* be misused. I can think of at least 10 more uses for it other than what has been mentioned. CCBill is the processor, they provide tools to their clients. How their clients use those tools is up to them.
If it can be misused, that's one thing. If it IS being misused, it should be stopped, and ccbill has the power to do so.
The question is, do you think they should put a stop to it? I do.
Comment