XenForo Wallet & Purchasable Features

[Alpha1]

It would be very useful if XenForo would have a Wallet for members.
Members would be able to fund their XenForo Wallet with through their PayPal account or credit card.
The balance in their XenForo Wallet could then be used to buy purchasable items, transfer amounts to other members or buy an account upgrade for other members.

The admin should be able to set purchasable items. For example:
- use feature X for Y amount.
- post content in node X for Y amount.
- download/access content in node X for Y amount.
- display custom field X for Y time for Z amount.

An important benefit of having this in the core is that addon developers can expand this in a lot of ways.
It would give the XenForo addon ecosystem an important boost.
As it's a financial feature that needs to be trusted and expanded by addon developers it's best to have this functionality in the core.
This function would make XenForo more profitable for webmasters as it would open a wide array of monetizing avenues.


Please note that I am not proposing a conventional credits system to reward users, but a financial wallet instead.

 

[Mouth]

Members would be able to fund their XenForo Wallet with through their PayPal account or credit card.
[...]
It would give the XenForo addon ecosystem an important boost.

If there was overwhelming support for it then it is something we could consider or at least understand what kind of framework would be required to support such a system.

+1 from me for being counted as overwhelming support.
I can really see the benefit and opportunities available by adding a framework to XF for a wallet system, whereby existing payment gateway setup is utilised to add funds to a framework/base wallet upon which add-on developers can utilise and extend upon.

 

[TPerry]

As for being "in core"... no thanks...
as for being a 1st party add-on like RM or XFMG, then yes, I could see that.

 

[Jake B.]

I might be reading this completely wrong, but I think this may do what we're asking. We also built the system in a modular way that it can be expanded upon by other developers. I may be completely wrong what you're asking for though, if so just ignore this post

 

[Alpha1]

Jake, its indeed not what I am suggesting. This is not about a points system.

 

[Jake B.]

Jake, its indeed not what I am suggesting. This is not about a points system.

Just read through your first post again, this part is covered by default with that add-on combined with the Shop extension:

The balance in their XenForo Wallet could then be used to buy purchasable items, transfer amounts to other members or buy an account upgrade for other members.

The other points would require some modification to work, but likely wouldn't be to many changes. You can disable earning points/credits through posts, etc. and make it so they have to buy them using PayPal, so I don't think its terribly far off from what you're wanting, though it defintely doesn't cover all of your points at this time

 

[Alpha1]

By definition this is not interesting as a 3rd party addon.

 

[Robust]

As an admin, I don't want to be responsible for storing/securing payment information for users. This opens up a whole new can of worms that most sites are totally unprepared to deal with.

Who said it'd store payment information? Probably use the same payment gateways the user upgrades function does, the same system, just this adds to your wallet.

If anything, this should be part of a bigger "Commerce" add-on.

Perhaps something @batpool52! wants to add to his marketplace add-on.

 

[Paul B]

To avoid this thread being derailed, I have split the discussion related to negative responses off to here: https://xenforo.com/community/threads/negative-responses-on-suggestion-threads.109621/

 

[Misayuki]

My personal opinion on this is that this would be better suited as an addon rather than in the core of the software as its only going to benefit a smaller group of forum owners. Again just my opinion.

How exactly can you be sure the amount of users this would apply to?

I personally think this would be a good feature to have apart of core.

 

[Ernest L. Defoe]

How exactly can you be sure the amount of users this would apply to?

I personally think this would be a good feature to have apart of core.

I'm saying this would apply to a smaller group of users compared to the whole of the user base of forum owners. I don't think it needs to be core. Why continue to add more and more bloat to the core of the software for a smaller percentage of forum owners. The reason most people like xF so much is because it's lightweight and fast. You start adding a bunch of code in there it will get bloated and sluggish. I see adding some kind of API system in core that can facilitate a 1st party addon or a quality 3rd party addon.

Me personally I don't feel I would ever have a need for it and neither would probably 60% of xF forum owners so to an extent that is still a rather niche need. I would have no problem with the xF Dev Team making a 1st party addon that could do what the OP is wanting.

I'm not saying what the OP suggested is a bad suggestion I'm just saying it doesn't need to be a core feature. That's all nothing more and nothing less.

 

[Alpha1]

This could indeed be 1st party addon or core. Either is fine.

The way I envision it is something similar to the user criteria system, where addon developers could create new criteria for making something purchasable.

A very simple purchasable item could be a donation. Which is something that many websites need.

 

[TPerry]

Generating income is a vital part of growing a community. Community hosting costs need to be covered somehow. Providing tools to generate income will be appealing to quite a few people. Whether its through donations, paid content, paid features, gifting or whatever.

Honestly, I think something like IPS's Commerce would be ideal for this. It was one of the reasons I originally went with IPS on my recumbent bike site (but took it back to XenForo for other reasons). I'd REALLY like the commerce ability, but would not really be crazy with it in as core - but as a 1st party add-on that could be easily extended by developers. That way, there would already be an infrastructure within the core of XenForo that could be extended without necessarily using the 1st party add-on.

 

[Mouth]

but as a 1st party add-on that could be easily extended by developers. That way, there would already be an infrastructure within the core of XenForo that could be extended without necessarily using the 1st party add-on.

I don't understand the difference between core and xf official add-on. Other than being able to charge additionally.
I'd also be interested in how many 3rd party add-on's extend xf official add-ons?

 

[TPerry]

I don't understand the difference between core and xf official add-on. Other than being able to charge additionally.
I'd also be interested in how many 3rd party add-on's extend xf official add-ons?

It's really simple.. core means that it's forced upon everybody - even those that may have no use for it. 1st party add-on means that it's OPTIONAL for those that want/need that function.
For some things that's not a big deal.. but for other things it IS a big deal since it adds overhead to the script typically.
Something like this most likely wouldn't be a just a few lines of code. It sounds like a lot of the features wanted are similar to a commerce app. Now, if talking about adding HOOKS into the system for developers to tie into, then that most likely would not be that bad.

 

[Mouth]

It's really simple.. core means that it's forced upon everybody - even those that may have no use for it. 1st party add-on means that it's OPTIONAL for those that want/need that function.

Nope. There's lots of core functionality at /admin.php?options/ that I can turn off and on as desired. Very little that's forced upon me.

but for other things it IS a big deal since it adds overhead to the script typically.

Yeah, people used to claim SSL was overhead on servers too.
If ... then logic add inconsequential overhead to scripts, for those with functionality off.

 

[TPerry]

Nope. There's lots of core functionality at /admin.php?options/ that I can turn off and on as desired. Very little that's forced upon me.

The code load is still there even though you can turn it "off".

Yeah, people used to claim SSL was overhead on servers too.
If ... then logic add inconsequential overhead to scripts, for those with functionality off.

It DOES add overhead.
https://www.maxcdn.com/blog/ssl-performance-myth/
Now, is it a significant addition to overhead? Depends on the hardware.

 

[Mouth]

The code load is still there even though you can turn it "off".

Your point was that it was forced upon. But's that's shown to be wrong. Now you're saying it's code load?
What stat's show code load is anything other than insignificant if I turn off registration, or notices, or bounce handling, or news feed, or search, or ........... ??

It DOES add overhead.

Measured in milliseconds. As I said, inconsequential.

 

[TPerry]

Your point was that it was forced upon. But's that's shown to be wrong. Now you're saying it's code load?
What stat's show code load is anything other than insignificant if I turn off registration, or notices, or bounce handling, or news feed, or search, or ........... ??

Really? So by flicking a switch the code lines miraculously disappear from the PHP code? Don't think so. It still has to be processed.
And YES, the code is forced upon the owner.. not the USE of the feature, but the underlying code and any impact upon performance that may have.

 

[Mouth]

Really? So by flicking a switch the code lines miraculously disappear from the PHP code? Don't think so. It still has to be processed.

Seriously? I already said an if .. then logic ringfencing a featured being turned off or on is insignificant processing. You really seem to grasping for breath here.

And YES, the code is forced upon the owner.. not the USE of the feature, but the underlying code and any impact upon performance that may have.

Ahhh ... the existence of code now. Pfffft ... who cares. It's not like anyone's worried about a couple of 100k of storage space on their server.
So much code is already forced on my by XF that I may have turned off in options. As if there's anything other than insignificant impact from adding some extra code size to XF downloads.

 

[TPerry]

The processing logic is still there.. and for something as large as a commerce app (which is what it sounds like the request is basically for) IS better placed as a 1st party add-on, no different than the gallery, the RM or the ES.
The point is CODE BLOAT, as in what some other scripts suffer from.