Home
Suggestions and new ideas
Shopping-Cart Money-Transfer
4 years ago submited by Julian Wolf
Quote:
However it ends up being sorted out, I agree that it's a good idea.
Thank you.
My suggestion:
Let´s keep it simple in PAP: Being able to "lock" Payout-methods as you said.
Let´s make it big in the PMP-Module: Different kinds of affilistes, with different backends for "partners" and "affiliates" and so on. That gives the module a great frame. What do you think?
In this case, the PMP-Module can also be a kind of a bonus-module. You simply set the affiliate always the same as the custommer, and then you can promise: Whatever you buy in our shop-network, you will get a 10% cashback ... cash or to buy something.
Best wishes, Julian!
Shopping-Cart Money-Transfer
This module could also be a part of the PMP-Module. However, I´d like to post it here seperately first, but I am also happy with a "double-module" in PAP. ;-)
I´d like to have to different kinds of affiliates:
- customers, who refer friends
- marketers, who hardly work on that for business
The customers I´d like to pay with a bonus in the shop. So when they earned 20 Dollars, they should be able to transfer the money to XTC, to OSC or to whatever system I use.
This can also work for merchants, who simply like to offer another payout-option. In my case, I don´t want to offer the customers a "money-payout", so this should be blockable by user-group. But I can also imagine that simply the choose for the affiliate is a nice thing.
There should be a way to work with different commissions on the different payouts. If the users buy something with me, I can pay out more commissions. So again, there are two ways:
- If they choose from the begining to get the money as a bonus for the shop, they get higher commissions. But they also can´t change that choose without deleting all existent commissions.
- If the commissions are the same, then possibly a factor could solve it. This can work like "Take your money to the shop and get 150% out of it! So the commissions of 100 Dollars will result in a 150-Dollar-Bonus in the shop.
What do you think about that?
Best wishes, Ju lian!
I´d like to have to different kinds of affiliates:
- customers, who refer friends
- marketers, who hardly work on that for business
The customers I´d like to pay with a bonus in the shop. So when they earned 20 Dollars, they should be able to transfer the money to XTC, to OSC or to whatever system I use.
This can also work for merchants, who simply like to offer another payout-option. In my case, I don´t want to offer the customers a "money-payout", so this should be blockable by user-group. But I can also imagine that simply the choose for the affiliate is a nice thing.
There should be a way to work with different commissions on the different payouts. If the users buy something with me, I can pay out more commissions. So again, there are two ways:
- If they choose from the begining to get the money as a bonus for the shop, they get higher commissions. But they also can´t change that choose without deleting all existent commissions.
- If the commissions are the same, then possibly a factor could solve it. This can work like "Take your money to the shop and get 150% out of it! So the commissions of 100 Dollars will result in a 150-Dollar-Bonus in the shop.
What do you think about that?
Best wishes, Ju lian!
Good idea
4 years ago Alan Tutt
What I gather here is that you'd like to set up a different payout definition that may be assigned to a specific campaign, with the payout being defined as "points" or "gift certificates" to be used in the shopping cart.
I think this is a good idea and could be useful for many shops. The disadvantage here is that each shopping cart will need to have a module in which these "points" could be used as payment, so the integration will depend on which carts have this capability.
This module may also depend on the ability to have PAP connect to the shopping cart's database, as I mentioned in the thread about "General User Sync". In this case, PAP would have to write the "points value" to the shopping cart's database during the payout process.
To extend this idea a bit further, some website owners may want to give their customer/affiliate the choice whether they are paid in points or with actual money, so maybe this is defined in the affiliate profile rather than in the campaigns. Maybe each campaign would define it's payouts in $, %, and points, and the individual affiliate account defines which of these payouts is rewarded to that affiliate.
In this case, the admin would need a setting to define whether the affiliate gets to choose, or whether the choice is made for them depending on certain conditions, such as where the affiliate application was submitted.
As PAP is now, this is technically possible, although admittedly not elegant. Just define a new payout method (points), and when you go to pay your affiliates, these points-based affiliates are included in the export file, which may then be imported to the shopping cart for final processing, which may include adjusting the $payout to some other value.
To fully implement the idea, some new settings would need to be implemented in PAP to control which affiliates are forced to receive points, and a different point value for each campaign if different from the normal $/% payout. Maybe even a global setting to convert normal $/% payouts to points.
Good idea, Julian.
__________________
- Alan Tutt
I think this is a good idea and could be useful for many shops. The disadvantage here is that each shopping cart will need to have a module in which these "points" could be used as payment, so the integration will depend on which carts have this capability.
This module may also depend on the ability to have PAP connect to the shopping cart's database, as I mentioned in the thread about "General User Sync". In this case, PAP would have to write the "points value" to the shopping cart's database during the payout process.
To extend this idea a bit further, some website owners may want to give their customer/affiliate the choice whether they are paid in points or with actual money, so maybe this is defined in the affiliate profile rather than in the campaigns. Maybe each campaign would define it's payouts in $, %, and points, and the individual affiliate account defines which of these payouts is rewarded to that affiliate.
In this case, the admin would need a setting to define whether the affiliate gets to choose, or whether the choice is made for them depending on certain conditions, such as where the affiliate application was submitted.
As PAP is now, this is technically possible, although admittedly not elegant. Just define a new payout method (points), and when you go to pay your affiliates, these points-based affiliates are included in the export file, which may then be imported to the shopping cart for final processing, which may include adjusting the $payout to some other value.
To fully implement the idea, some new settings would need to be implemented in PAP to control which affiliates are forced to receive points, and a different point value for each campaign if different from the normal $/% payout. Maybe even a global setting to convert normal $/% payouts to points.
Good idea, Julian.
__________________
- Alan Tutt
I don´t want to built a new currency like "points"
4 years ago Julian Wolf
I don´t want to built a new currency like "points". What I want is to make a difference between an affiliate, that uses the money to buy products with me and an affiliate, that wants to earn money with me.
There are many differences, that I need to figure out, between this two kinds of affiliates. The PMP-Module is for my opinion exactly the right way to sort that out. And the money-thing: How it is solved in the shop is not really PAPs Problem. For me it´s enough when PAP can make the difference between "payout" and "bonus".
Best wishes, Jul ian!
There are many differences, that I need to figure out, between this two kinds of affiliates. The PMP-Module is for my opinion exactly the right way to sort that out. And the money-thing: How it is solved in the shop is not really PAPs Problem. For me it´s enough when PAP can make the difference between "payout" and "bonus".
Best wishes, Jul ian!
Yes, I understand
4 years ago Alan Tutt
Yes, I understand that you perceive this situation as a different type of affiliate, however, in the programming logic, it is more appropriate to define this affiliate 'type' as locked in to a different payout method.
However it ends up being sorted out, I agree that it's a good idea.
__________________
- Alan Tutt
However it ends up being sorted out, I agree that it's a good idea.
__________________
- Alan Tutt
Let´s keep it simple in PAP
4 years ago Julian WolfQuote:
However it ends up being sorted out, I agree that it's a good idea.
Thank you.
My suggestion:
Let´s keep it simple in PAP: Being able to "lock" Payout-methods as you said.
Let´s make it big in the PMP-Module: Different kinds of affilistes, with different backends for "partners" and "affiliates" and so on. That gives the module a great frame. What do you think?
In this case, the PMP-Module can also be a kind of a bonus-module. You simply set the affiliate always the same as the custommer, and then you can promise: Whatever you buy in our shop-network, you will get a 10% cashback ... cash or to buy something.
Best wishes, Julian!