Jump to content

IPS 4.2 observations


JohnDar

Recommended Posts

Posted

Liking the new features, particularly Clubs, but thought I'd mention a couple of things that I'd really like to see improved...

In Clubs, if you have your settings set so that all new clubs need to be approved by an admin, there doesn't seem to be any provision for sending out an email or notification that a new club is pending approval. At the moment, it's a case of just checking the clubs page to see if anything new has arrived. If I'm missing something, apologies, but I can't see where such a notification can be configured.

In Commerce, if you set up a product as a non physical subscription, then it makes sense to have it set so that only one can be purchased. That's great and prevents members from accidentally doubling up. However, if a subscription expires and the member decides, (a little later) to re-subscribe, they can't purchase the subscription because they have already purchased one. It doesn't seem to matter that it is expired. Ideally, members with an expired subscription should be able to purchase again, from scratch.

And lastly, just a small observation... it would be really handy if the IPS logo, top left of the ACP was a link to the Dashboard, (which is effectively 'home' in the ACP). It's a bit annoying, having to scroll up through the sections to find 'Dashboard', just to get back to the top level. Having the IPS logo as home would make this really easy.

Posted
15 minutes ago, JohnDar said:

And lastly, just a small observation... it would be really handy if the IPS logo, top left of the ACP was a link to the Dashboard, (which is effectively 'home' in the ACP). It's a bit annoying, having to scroll up through the sections to find 'Dashboard', just to get back to the top level. Having the IPS logo as home would make this really easy.

Good point

  • Management
Posted

Thanks for the feedback, John. 

1. We have this on our roadmap already and agree it's necessary. 

2. I can tell you from experience overseeing support, allowing users to repeatedly create new subscriptions instead of renewing expired purchases creates a lot of housekeeping issues and confusion, from PayPal billing agreements and beyond. In such cases where this isn't a concern, I'd recommend turning the single purchase limit off. I've not seen double orders as a technical issue in Invision Community 4.2. We will, of course, monitor this for further feedback and make any reconsiderations as necessary.

3. Great idea - this drives me a bit batty as well. I've put it on our roadmap. 

Thanks again.

Posted
3 hours ago, Lindy said:

2. I can tell you from experience overseeing support, allowing users to repeatedly create new subscriptions instead of renewing expired purchases creates a lot of housekeeping issues and confusion …

Fine, but that wasn’t the point though. We have paying customers who want to pay again and can’t – THAT is the actual issue that creates confusion, frustration and makes the admins loose money, because most users will just give up instead of clarifying the issue with an admin. 

 

Quote

instead of renewing expired purchases

Which is not an option, and that is the problem! There is absolutely no justification why it should be set up this way and should require manual admin actions first. 
The systems knows the product was purchased before and that the previous invoice is expired. The admin wants them to be able to automatically renew/buy again, but the system doesn’t let them for no good reason. 

 

Quote

We will, of course, monitor this for further feedback and make any reconsiderations as necessary.

I am not sure how much longer this must be “monitored“ though. It’s an issue for every admin selling subscriptions. Sooner or later they run into this and it was reported over and over again. 

Posted

I also want to add up to the frustration and gang up on Lindy :) I am introducing the subscriptions soon and I plan to just turn this protection off and deal with the headache if one user purchases twice at the same time. So glad I am reading the forums here so I know about this issue, who knows how many repeated customers I would have lost. But it shouldn't be this way - I want a smooth working system that is not confusing for both me and the users, I don't want to choose the lesser of two evils when there is not even a reason for these evils to exist. 

In fact, many of the commerce restrictions are useless and create more trouble then help. I have talked about the restriction that commerce can work only with real currency. There is also the restriction that when you order physical product you need to provide your home address. But in my country there is an option to deliver to chosen post office, in fact it is the most popular option, users don't need to provide their address. But there is no direct way to create that in Commerce. There is a workaround with custom fields, but it is a terrible one, online shopping should be as seamless as possible.

Please remove the stupid restrictions and give us the flexibility to configure the stores to our liking. If I want a fake currency - let me have it, if I want to deliver physical products without requesting address from the users - let me have it. The protections and restrictions are useless, you don't know my use case better then me. 

Posted
6 hours ago, Lindy said:

Great idea - this drives me a bit batty as well. I've put it on our roadmap. 

As a customer, it's great when I see responses like that! :)

I think it would be great if you and the other IPS staff could assign a quick badge, tag or something to a topic that indicates to customers when viewing the feedback forum or topic when a feedback suggestion has been accepted or added to the roadmap, or whatever. Keep it simple, not suggesting tagging ideas that are discounted as not taken on board or that don't make it. But it would be a good indicator of how much feedback is actually useful, accepted, provide a way to quickly check before duplicating an idea etc.

This got me thinking, it would be ideal if feedback topics had the up vote and down vote options like those available in the Q&A style forums. All the +1's and positive comments alone must be harder to determine if an idea is well liked by the community.

Posted
10 hours ago, JohnDar said:

No Commerce, se você configurar um produto como uma assinatura não física, então é sensato configurá-lo para que apenas um possa ser comprado. Isso é ótimo e evita que os membros dobram-se acidentalmente. No entanto, se uma subscrição expirar e o membro decidir, (um pouco mais tarde) para se reinscrever, eles não podem comprar a assinatura porque já compraram uma. Não parece importar que tenha expirado. Idealmente, os membros com uma assinatura expirada devem poder comprar novamente, a partir do zero.

I have the same problem and I made an adjustment I described in this topic. But we need a more intuitive solution for sure.

 

  • Management
Posted

To address the various Commerce discussions related to subscriptions:

I like simple solutions and we're leery of adding pages of potentially confusing settings to accommodate all possible usage scenarios - Admin A sells tiered subscriptions and only wants subscriptions in a group to be unique because he's fearful of a user purchasing multiple subscriptions at once. Admin B has an automotive repair support community and sells subscriptions based on what vehicles they need service info on and he WANTS people to be able to purchase "Chrysler, Ford and/or GM" subscriptions simultaneously in the "Domestic Vehicles" group. If Admin A's subscriptions expire, he wants them to buy a new one. Admin B wants them to be able to renew past invoices and NOT buy new subscriptions because his bookkeeping and analytic requirements dictate he needs to isolate new sales vs renewals. Admin C uses subscriptions to sell recurring online game credits that can stack, so his needs are also different than Admin A and B. Admin D wants to prevent people from ordering multiple subscriptions at initial checkout, but wants them to later be able to order simultaneous subscriptions once they're a client. Invision makes an attempt to specifically accommodate Admins A-D and Admin E comes along that wants to simply sell a single premium subscription and has difficulty because there's a series of what-if complications they need to traverse through.

I hope the above better explains why things are done for what you may consider "no good reason." As you know, users tend to get focused on their specific needs - totally understandable, we don't expect you to consider every possible angle, it's your needs that you should be most concerned about. Our job is to parse feedback and incorporate the simplest solution that benefits the most. On the simplest level, if your issue with selling subscriptions is people can't renew from expired invoices -- the solution is quite simple - don't expire the invoices. If you don't have a specific need, it's not a requirement and you can in fact disable that today. That seems to solve the brunt of the issue, which as best as I can tell are: you've set invoices to expire and also enabled one-purchase protection, so they can't pay expired invoices and they can't purchase a product they've already purchased. Both of these concerns are admin configured and changing only one of them resolves the issue at a basic level. 

If there are suggested tweaks that can be further articulated, I'm happy to act upon those internally. An example would be: a user tries to purchase a subscription that has protection enabled, we can modify that "error" to be more friendly and refer them to their purchases page, or even, a pending renewal invoice if one exists. Another potential solution to the expired invoice concern is to continue the global expiration time, but allow that to be overridden on a per-package level. So, for certain subscriptions, you may opt to allow the client to renew 10 years after it expired. Others, you may only want 30 days. Finally, it may be a good idea to allow for product groups (categories) to have the unique/one purchase protection for those that desire it. 

In short: we want you to be able to use the product to be successful. We are happy to make tweaks and try to accommodate various use-cases without overcomplicating the product. Again, the best solutions are often the simplest. If you agree, we'll proceed with further internal discussions and try to get these ideas materialized.

Posted

Hi @Lindy

Thank you for taking more involved interest in this. I fully agree that often the best solutions are the simplest ones. Speaking of which, in your post there are about 10 mentions of invoices. I do have a fair experience as a user with e-commerce and saas services, but I cannot think of another place where there are expiring invoices, renewing invoices, etc. You simply add a product to a cart or subscribe to monthly services and thats it. I cannot think of another e-commerce (being for physical or digital products) where I had to deal with invoices as a customer. Invoice in my mind is something for the accountant, not for me :) I suppose pretty much the same process goes everywhere, but for some reason with other e-commerce platforms it is transparent for me. So to summarize - if we want the thing as simple as possible, there is something to be done for the renewing, expiring and overly confusing invoices and transactions.

I do want to repeat two additional suggestions that are very much in tone with your keep it simple principle:

1. Give us the ability to use made up currencies. You think that by limiting us to real currency you make it simple for us, but it is quite the opposite, many points systems on the marketplace cannot integrate well with commerce, because of this restriction. 

2. Give us the ability to customize shipping options for physical products (custom fields are excellent for that) without asking specifically for customer address. I know that again you want to make it simple for us to not forget where to deliver the product (DUH!), but again - there are valid use cases where you can ship physical product without the need to know the customer's home address. Many of the users are reluctant to add their home address in an online community and in result they don't buy the product. It is annoying, especially when you can order the thing to be delivered at your local post office, incredibly simple and easy for both user and admin and it keeps the privacy of the user intact.

It is true that the same people have no problems sharing their home address with amazon and even some no name stores. But the thing is, they don't participate in discussions there, they don't have an online persona visible for others, online persona that  many of them want to keep separate from the physical one. This makes them very reluctant to share physical address on an online community, even if it is in private with the admin only. To summarize - users home address should be asked as an absolutely last resort and should not be slapped to every physical purchase out of supposed convenience. 

In my community I do have repeated requests by people asking how to buy stuff from the shop. And these are people that are usually very proficient at booking airline tickets, hotels, rentalcars, etc. - process that is usually much more involved then buying a t-shirt. If such kind of people cannot figure out how to use Commerce it says quite a lot about your trying to keep things simple approach. 

Posted

Since commerce plays a huge part in paid memberships, I would like to see something like this added specifically for service related items and have "product" language changed to service, membership, plan(s), etc. 

image.thumb.png.8e15b78fb8173b498db4c0c1ff30c066.png

Why not create a type that is a service (non-physical), membership, service plan, labor fee, etc.

Posted

Or, how about IPS segregate out Subscriptions inside of Commerce? That should make it easier from a user perspective, as well as from an application perspective, keep things modular and simple.

Posted
11 hours ago, Lindy said:

To address the various Commerce discussions related to subscriptions:

I like simple solutions and we're leery of adding pages of potentially confusing settings to accommodate all possible usage scenarios - Admin A sells tiered subscriptions and only wants subscriptions in a group to be unique because he's fearful of a user purchasing multiple subscriptions at once. Admin B has an automotive repair support community and sells subscriptions based on what vehicles they need service info on and he WANTS people to be able to purchase "Chrysler, Ford and/or GM" subscriptions simultaneously in the "Domestic Vehicles" group. If Admin A's subscriptions expire, he wants them to buy a new one. Admin B wants them to be able to renew past invoices and NOT buy new subscriptions because his bookkeeping and analytic requirements dictate he needs to isolate new sales vs renewals. Admin C uses subscriptions to sell recurring online game credits that can stack, so his needs are also different than Admin A and B. Admin D wants to prevent people from ordering multiple subscriptions at initial checkout, but wants them to later be able to order simultaneous subscriptions once they're a client. Invision makes an attempt to specifically accommodate Admins A-D and Admin E comes along that wants to simply sell a single premium subscription and has difficulty because there's a series of what-if complications they need to traverse through.

I hope the above better explains why things are done for what you may consider "no good reason." As you know, users tend to get focused on their specific needs - totally understandable, we don't expect you to consider every possible angle, it's your needs that you should be most concerned about. Our job is to parse feedback and incorporate the simplest solution that benefits the most. On the simplest level, if your issue with selling subscriptions is people can't renew from expired invoices -- the solution is quite simple - don't expire the invoices. If you don't have a specific need, it's not a requirement and you can in fact disable that today. That seems to solve the brunt of the issue, which as best as I can tell are: you've set invoices to expire and also enabled one-purchase protection, so they can't pay expired invoices and they can't purchase a product they've already purchased. Both of these concerns are admin configured and changing only one of them resolves the issue at a basic level. 

If there are suggested tweaks that can be further articulated, I'm happy to act upon those internally. An example would be: a user tries to purchase a subscription that has protection enabled, we can modify that "error" to be more friendly and refer them to their purchases page, or even, a pending renewal invoice if one exists. Another potential solution to the expired invoice concern is to continue the global expiration time, but allow that to be overridden on a per-package level. So, for certain subscriptions, you may opt to allow the client to renew 10 years after it expired. Others, you may only want 30 days. Finally, it may be a good idea to allow for product groups (categories) to have the unique/one purchase protection for those that desire it. 

In short: we want you to be able to use the product to be successful. We are happy to make tweaks and try to accommodate various use-cases without overcomplicating the product. Again, the best solutions are often the simplest. If you agree, we'll proceed with further internal discussions and try to get these ideas materialized.

I'm liking this post entirely because: 

Lindy says he likes simple.  Then spends four detailed paragraphs explaining simple, ha. :lol:

Posted

FWIW, I made (but have not publicly released) a plugin which changes the behaviour of "user can only purchase one" to "user can only have one active at a time". With that plugin enabled, I have found that a number of users end up with more than one subscription at a time because PayPal Billing Agreements sometimes fail to complete the transaction for some reason, and Commerce screws up when that happens. After a (relatively rare) less than pleasant experience with IPS support, and after the ticket was escalated to management, some improvements were made to handle this situation, but quite frankly it is still very poor, with users being charged without being granted access to the benefits that they have paid for, and with no mechanism in the suite to grant them access, even through manual action by the admin. My use of commerce is held up by the aforementioned custom plugin, a custom script that I direct users to which aims to resynchronise their permissions with the status of their billing agreement, and a lot of support tickets.

What I'm trying to say is that I agree that this is an important option to have, but I also believe that, at least if you use PayPal, if it is added you will still spend your time responding to users' support requests and issuing refunds (or receiving money for products that the users don't end up getting).

For the record, I have in a number of support tickets proposed solutions to most of the issues that I have brought up here, but they have not been implemented, and for the most part went ignored in the tickets.

We are currently in the process of migrating the payments off Invision Community and into a custom site. There are other reasons than just the problems with IPS, but it is really feeling like less effort to code the entire Stripe integration outside of IPS than it was to deal with the PayPal integration in IPS (and yes, I am aware that IPS supports Stripe. As I said, there are other unrelated reasons for the move).

  • Management
Posted
On 9/22/2017 at 4:56 AM, jair101 said:

Hi @Lindy

Thank you for taking more involved interest in this. I fully agree that often the best solutions are the simplest ones. Speaking of which, in your post there are about 10 mentions of invoices. I do have a fair experience as a user with e-commerce and saas services, but I cannot think of another place where there are expiring invoices, renewing invoices, etc. You simply add a product to a cart or subscribe to monthly services and thats it. I cannot think of another e-commerce (being for physical or digital products) where I had to deal with invoices as a customer. Invoice in my mind is something for the accountant, not for me :) I suppose pretty much the same process goes everywhere, but for some reason with other e-commerce platforms it is transparent for me. So to summarize - if we want the thing as simple as possible, there is something to be done for the renewing, expiring and overly confusing invoices and transactions.

Invoices are necessary to serve the varying needs of Commerce and its clients - I'm unsure where you've been shopping where you don't deal with invoices in some form -- some may call them "orders" but ultimately, they're invoices. They can be transparent to the client in Commerce as well. If you want to allow no grace period and change settings to focus more on instant transactions and you needn't mess with expirations, etc. 

Quote

I do want to repeat two additional suggestions that are very much in tone with your keep it simple principle:

1. Give us the ability to use made up currencies. You think that by limiting us to real currency you make it simple for us, but it is quite the opposite, many points systems on the marketplace cannot integrate well with commerce, because of this restriction. 

Please understand, it's an e-commerce product. The entire system relies on some form of valid currency and changing it to use a unapproved currency would be an expansive undertaking, for a rather niche use-case. If you're trying to sell points, you could perhaps consider the account credit feature, a custom field, or similar?

Quote

2. Give us the ability to customize shipping options for physical products (custom fields are excellent for that) without asking specifically for customer address. I know that again you want to make it simple for us to not forget where to deliver the product (DUH!), but again - there are valid use cases where you can ship physical product without the need to know the customer's home address. Many of the users are reluctant to add their home address in an online community and in result they don't buy the product. It is annoying, especially when you can order the thing to be delivered at your local post office, incredibly simple and easy for both user and admin and it keeps the privacy of the user intact.

It's not that we're trying to just make it simple for you in terms of knowing where to deliver the product. If you pay via credit card with PayPal, an address is required. Most merchant processors - auth.net, etc. are going to require an address. 2checkout, at last check, requires one. If you're handling physical products, you're most likely supposed to be collecting tax based on the customer's location (which you wouldn't know, if you didn't get their location), fraud screening won't work properly, fraud rules in Commerce won't work properly. I understand you have an edge case... from my experience, not requiring an address for physical products is, by far, the exception, not the norm. It may seem "simple" to just allow people to do whatever they please with the product with no engineering limitations at all, but we do have an obligation to maintain the integrity of the product, keep support minimal and try to avoid issues the client may not have considered (ie: "I don't require addresses and I've gotten 30 chargebacks!", "I don't require addresses and now the revenue service is auditing me.", "I don't require addresses and I can't get PayPal to work if the user is using a credit card.") etc. We allow you to ignore all of that for non-physical products if you really, really want to - but the extremely limited cases where you'd even be able to sell a physical product online without knowing who your client is at all, do not warrant the potential ramifications. Nonetheless, I will investigate the ability to have a power user setting - no promises. In the interim, if it's a sticking point for you, then I suppose you could try (I've not tested) editing the language strings for the address fields and instruct them to put "n/a" if they don't want to provide an address if you're ok with that, you're using a payment processor that doesn't require addresses and you're not using fraud rules.

Quote

In my community I do have repeated requests by people asking how to buy stuff from the shop. And these are people that are usually very proficient at booking airline tickets, hotels, rentalcars, etc. - process that is usually much more involved then buying a t-shirt. If such kind of people cannot figure out how to use Commerce it says quite a lot about your trying to keep things simple approach. 

If you'd like to PM me, I'd be happy to review your shop and make suggestions. Commerce shouldn't be difficult for end-users, if you can articulate further feedback, we would be happy to review. 

On 9/22/2017 at 7:38 AM, AlexWebsites said:

Since commerce plays a huge part in paid memberships, I would like to see something like this added specifically for service related items and have "product" language changed to service, membership, plan(s), etc. 

image.thumb.png.8e15b78fb8173b498db4c0c1ff30c066.png

Why not create a type that is a service (non-physical), membership, service plan, labor fee, etc.

I like this idea a lot and will log it internally. Subscriptions is, by far, the most common usage scenario for Commerce, so I would agree making it easier to add and manage would make total sense. On it! 

@Colonel_mortis - I just want you to know, why perhaps irrelevant now, we've not ignored your feedback on PayPal billing agreements. We have been working with PayPal and have made changes to the gateway for agreements in 4.3. 

As for the original invoice concern - are we good on that? 

Posted

@Lindy thanks for taking the type into consideration and if you do implement something like this for membership subscriptions, please include a way to easily move from product to subscription without any major disruption for past purchases. My concern would be that anyone that has subscribed by purchasing a product type using a gateway such as PayPal would be disrupted causing a new subscription start or something funky. I could be wrong though.:unsure:

Posted

I need to add optional membership subscriptions in a last ditch effort to help fund my largest community site, since Google Ads and now Amazon Affiliates have failed dismally. However I don't need the raft of hosting and product sales elements of Commerce for this community, I don't have physical or digital products to sell, so that effectively mean unnecessary bloat and paying for lots of functionality and features I don't need.

The initial cost of the current 'one size fits all' aka 'kitchen sink' implementation of Commerce is quite high if you don't have a need for much of the intergrated features, and hence it becomes quite a gamble if, like in my case, you need to purchase and invest in it to actually offset costs and try to save your community or hopefully avoid switching to inferior free forum solutions.

So I'd love to see a light version of Commerce that handles memberships and renewals, or official plug-ins for Commerce to add the relevant hosting or product sales elements for those who specifically need them.

Posted
19 hours ago, Lindy said:

Please understand, it's an e-commerce product. The entire system relies on some form of valid currency and changing it to use a unapproved currency would be an expansive undertaking, for a rather niche use-case. If you're trying to sell points, you could perhaps consider the account credit feature, a custom field, or similar?

Fair enough. But I can argue whether this is rather niche. Point systems have been around since forever as an option to improve dedication and reward members for their contributions. But what can you do if you collect zillion points? Almost nothing, you get the warm feeling that you are on top of some leaderboard and thats it.  At the same time we have Commerce, whose integration with downloads can provide excellent options to exchange those points for something valuable - it might be digital download or physical product, you name it. But no, you can't do it. 

We have the various point/awards systems, which are very good at providing the members with virtual points, we have commerce which is very good at providing products, but it is impossible to link them together. If I am the only one that can see the enormous potential of such integration (much bigger potential then reputation and the leaderboard), so be it. If the ability to reward your good members with something meaningful is niche, I have nothing to add.

19 hours ago, Lindy said:

If you pay via credit card with PayPal, an address is required. Most merchant processors - auth.net, etc. are going to require an address. 2checkout, at last check, requires one...

Obviously my suggestion is not applicable for paypal, stripe, 2checkout, etc. The solution here is that if I disable the address field, then commerce will disable these payment gateways. Problem solved - no chargebacks, no support work for you and integrity of the software is not compromised as this way we won't be able to use the popular gateways. You already do that, if I add a currency, which Paypal does not support, it is not available as a payment gateway. Please consider doing the same for when we ignore the address field. 

You argue that again this is very niche, but in-store pick up is very popular in USA as well, while cash on delivery is most popular in many countries and I am not speaking about third world. https://en.wikipedia.org/wiki/Cash_on_delivery

19 hours ago, Lindy said:

If you'd like to PM me, I'd be happy to review your shop and make suggestions. Commerce shouldn't be difficult for end-users, if you can articulate further feedback, we would be happy to review. 

Thanks for the offer, I will probably post another topic, I don't think you will be able to give me useful suggestions considering my store is not in English and there are various workarounds I had to implement to get around the restrictions we are discussing here. But really appreciate it. 

Posted
Quote

Fair enough. But I can argue whether this is rather niche. Point systems have been around since forever as an option to improve dedication and reward members for their contributions. But what can you do if you collect zillion points? Almost nothing, you get the warm feeling that you are on top of some leaderboard and thats it.  At the same time we have Commerce, whose integration with downloads can provide excellent options to exchange those points for something valuable - it might be digital download or physical product, you name it. But no, you can't do it. 

We have the various point/awards systems, which are very good at providing the members with virtual points, we have commerce which is very good at providing products, but it is impossible to link them together. If I am the only one that can see the enormous potential of such integration (much bigger potential then reputation and the leaderboard), so be it. If the ability to reward your good members with something meaningful is niche, I have nothing to add.

Just chiming in as another customer with demand for this. I bought Commerce over the weekend explicitly for the purpose of creating a points reward shop. I was able to get virtual currency to work with a third party application from the marketplace. Sure it gets the job done, but native support would be better and feel more simple to me.

Posted
12 minutes ago, Hezeber said:

Just chiming in as another customer with demand for this. I bought Commerce over the weekend explicitly for the purpose of creating a points reward shop. I was able to get virtual currency to work with a third party application from the marketplace. Sure it gets the job done, but native support would be better and feel more simple to me.

I have the same opinion on this subject. :thumbsup:

Posted

Since people are talking about points economies, just as a brief public service announcement I will once again mention @Kevin Carwile's free Points Economy app, which allows you to create as many different points systems as you want.  As I don't currently have the Commerce module, I don't know exactly how Points Economies interacts with it - but some people here might benefit from it.

Posted
52 minutes ago, liquidfractal said:

Since people are talking about points economies, just as a brief public service announcement I will once again mention @Kevin Carwile's free Points Economy app, which allows you to create as many different points systems as you want.  As I don't currently have the Commerce module, I don't know exactly how Points Economies interacts with it - but some people here might benefit from it.

Thats the system we are talking about. It provides some integration with commerce, but it is barely viable (not Kevin's fault as far as I know, he said that even the current integration is a small miracle). For example, you can't list the prices in points, you can't have points only store and you cant show the amount of points that are going to be deducted before checkout. 

Posted
On 9/23/2017 at 11:44 PM, Lindy said:

Please understand, it's an e-commerce product. The entire system relies on some form of valid currency and changing it to use a unapproved currency would be an expansive undertaking, for a rather niche use-case. 

Sorry to bother you again @Lindy, but this comment really bugs me. There is another aspect I haven't touched - the loyalty programs. Pretty much all airline, hotel chain, rental car company, bank and credit card have some kind of loyalty scheme where you collect points which you can exchange for tangible and intangible goods.

You also have it in Best  Buy:

image.thumb.png.5bba3cd9252763c7622fb824036ab9e4.png

Macy's:

image.thumb.png.a94e8195d496764b68d2ed336c62b23a.png

Starbucks:

image.thumb.png.00593f8d2f222489c52163eadf659df9.png

and many, many more. 

If you believe developer resources are better spent elsewhere, that's fair. But virtual currencies are not niche, both in e-commerce and retail.  

 

  • Management
Posted

I'm sorry, I misunderstood your feedback based on "don't force us to use real currency." I understand your use-case and we can consider it in a future release. 

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...