dynambee

Sequential order numbers allow your competition to see how many orders per month you are doing. Randomized order numbers are much, much better.

@DavidP said in Recurring payments in thirty bees: You might want to take a look at AheadWorks Magento extension for this to get some ideas of how they do it. Agreed 100%. Look at the current market leaders and see what they are doing that makes them a market leader. Then find out what features they lack that stores would like and add them where possible.

@Havouza said in Recurring payments in thirty bees: I dont think the storing that is the problem. I think it is the possibillity of cheating when the consent to recurring payments is held by the store not the gateway. But it is my opinion With a tokenized system the authorization is (AFAIK) held by the gateway, not the store.

@Havouza said in Recurring payments in thirty bees: I just try to see it a little from the buyers perspective. Do they really trust an internal shop solution that get the right to charge their credit card without my authorization every time. With all the card fraud goingf around I would be very vary. I think (and I could be wrong) that what you are imagining isn't quite what happens. When the customer signs up they go through the checkout process and agree to have their card charged a certain amount ($25 for example) once in a certain period (every two weeks, once a month, etc). This is sent to the payment processing company who stores all the this information and then returns a token to 30bz. 30bz stores this token together with the subscription details for the customer. When it comes time to charge the customer 30bz will send this token to the payment processor and request that the charge happen. If the payment processor agrees that it is time to charge the customer then the charge is processed onto the customer's credit card and 30bz is told if the payment succeeded or not. This type of system means that 30bz does not have to be PCI compliant and that no customer credit card details are stored with 30bz.

A few random ideas: An option to support automatic partial refunds. Some companies refund a prorated amount of the last subscription payment if a user cancels during the month. Other companies of course do not do this so it should probably be off by default so only those who want it can turn it on. Cusomizable cutoff dates for cancellations. Some businesses need a bit of lead time to prepare for whatever their customers are subscribing to. If a given business needs 5 days of lead time then the last allowed cancellation date would be 5 days before the next bill. Likewise customizable cutoff dates for new subscriptions. If it's a once-a-month service that needs lead time then any new subscriptions that sign up fewer than X days before the closest billing date are automatically sent to the following billing date. (Also, see groups below.) The ability to assign customers to groups with each group having it's own billing & shipping dates. Some box subscription services send their boxes out in batches. Customers in Group 1 get boxes sent on the 5th of the month. Group 2 on the 10th, Group 3 on the 15th, etc. Maybe every 10 days, maybe every day or every 3 days. It should be possible to assign customers to groups both automatically and manually. Ideally the system should assign new customers to a group close to their signup date (allowing for the lead times mentioned in #3...) but then if things get too far unbalanced then an admin should be able to move customers from one group to another to maintain some sort of balance. No point in having groups if 75% of all customers are in one group. An extension to the above, but if a customer is moved from Group 1 (earlier shipment date) to Group 3 (later shipment date) then the system must make sure that the customer isn't sent 2 boxes in one month. Likewise if a customer is moved from Group 3 to Group 1 the system must make sure that the customer doesn't get skipped for that month. Probably the best way to accomplish this is to make it so that group changes take effect from the following month onward. Ability to choose how many days before a group's shipping date that the group is billed. This gives some lead time and also gives customers some time to update their payment details if a payment is declined. And a question: How are payments going to be processed? We can't store payment details or PayPal authorization details so I assume this system would have to integrate with PayPal's and/or Stripe's subscription systems. That way all the PITA storage of payment details is managed by someone else. I suppose this could complicate the idea of moving customers from one group to another as mentioned in #4 & 5 above. Is it possible to change a subscription billing date without customer authorization?

@mdekker said in Let's talk about Search!: I'm not sure if it is compatible with those as well. It only has templates for default-bootstrap. Ah, I understand now. I'm certainly interested in @vincendenkspel's plan and hope that as a community we can put together a strong Elasticsearch module for 30bz.

:thumbsup_tone2:

@mdekker, from a technical standpoint (or any other standpoint!) do you have a preference for one of these themes over the other?

I would contribute to that, for sure. If possible please PM me details.

So if I switched to something like Transformer or Warehouse Brad might actually work better?

Yes. I will probably keep using it when I launch too, at least at first.

@mdekker said in Let's talk about Search!: To be honest, the list you made above looks like just ElasticSearch settings. So if BRAD would have had these additional settings, it would have been suitable for you as well, right? Pretty much, yes. When I had Brad installed I had some problems with category pages that went away when I uninstalled it. I'm not sure why that was though and it seemed to work for a while before I noticed the problems. Ideally I'd also like to figure out how to use the filters that Brad seems to offer, and of course would have to figure out how to get the brad search box to actually replace the standard 30bz search box rather than it creating a separate search box. Right now I'm fixing some other problems with our in-house automation but I plan to get back to the web-focused work soon and may try Brad again, perhaps on a fresh 30bz install.

I figured that since you mentioned 1.0.2 that it might be coming along soon. Excited to see what changes it contains! :grinning:

Disappointing that the expensive ES module uses the less efficient way. I might buy it anyway and then as a paying customer try to encourage them to make it more efficient... I guess it depends on how much work it would take to rewrite that part of it, and how much of a knock-on affect there would be to other parts of the module.

Is one of these methods better than the other?

I don't think there's really a perfect solution, only "best solutions" for different types of businesses. We export globally and a system that guesses the customer's location reasonably well would be a very big improvement over what PS does now. The module I linked to above works pretty well overall because for users that are already logged in it uses their shipping address but for guests it guesses based on IP geolocation. I would guess that most B2B businesses aren't dealing with a lot of guest customers but I could be wrong. I think who it really wouldn't work that well for are people who ship a lot domestically and who have different domestic shipping regions to work with. IP geolocation generally isn't accurate enough for that type of separation. In that case a default region or just a message for guests saying that shipping is calculated at checkout is the only workable solution (apart from "free" shipping of course.)

This module was mentioned by @30knees in our chat discussion. It was actually created because of a different discussion I had with the author on the PS forums about PS' shipping problems. I haven't bought the module yet or tried it out but it does fix a few big problems with the standard shipping system. Mainly: Non-logged visitors are shown shipping costs in the shopping cart based on their IP address' geo location. Currently PS just uses the default country which can lead to some very inaccurate results. Logged in customers are shown shipping options that are valid for their country. Doesn't require any changes to the shipping system to work and is compatible with all carriers & carrier modules. I know the list of feature requests is very long but a way to show customers accurate shipping costs before they get to the checkout process would be very cool indeed.

@mdekker said in Let's talk about Search!: I’m also curious if either @mdekker or @lesley is able to comment on how things are progressing with 30bz search and what sort of direction they have decided to go. No efforts have been made. We're still talking with several parties before we can continue with the modules. Thanks for the status update. I think I might try buying that 130 Euro ES module from the PS store and see how that goes with 30bz. They said it wouldn't work but I think it should, perhaps with some minor changes. I'll certainly let you know how it goes.

@mdekker said in Front office favicon: Or wait for 1.0.2 I know you guys are super busy and have many things going on behind the scenes that the rest of us can't yet see. That said... Is there a timeline or estimated release date for 1.0.2?

I looked at the page but managed to miss the tabs towards the bottom. Indeed, there is a compatibility badge there. Very nice!

@lesley, is the Piwik module from your site compatible with 30bz? It certainly looks like it would be a very useful module to have!

Yup, so many different icons needed for different devices, and different HTML needed in the header of each page as well. Annoying, but worth it.

I found it through this StackOverflow post which also gives a quick rundown of some of the different types of icons a website should ideally have: https://stackoverflow.com/a/19590415/2117677

I saw it, but the one I stumbled across is the most complete favicon site I've ever seen. Definitely worth checking out.

I found a most excellent favicon site: https://realfavicongenerator.net/ You can use it to test your site's current favicon and get a report about what problem(s) it might have, and you can use it to generate all the different favicons required, together with all the HTML required for them. @mdekker, is 30bz compliant with all the different favicons needed for different types of devices?