dynambee

PS and TB both offer a "speed grade" setting in the database (the column name is "grade" and it is the last column in the tb_carrier table) that doesn't actually seem to be used for much in the checkout process. If there are different shipping options that share the same speed grade it would be great if the system automatically combined these together into a shipping option for the customer. Ideally there would be a way to assign a name to a given speed grade. Speed Grade 6 = "Express Mail", Speed Grade 4 = "Airmail", etc. Then when speed grades are combined together the Speed Grade description is shown to the customer. This would allow stores to have "free shipping" for some items and "billed shipping" for other items and then present a unified & tidy shipping option list during checkout. Finally, if there are no shared speed grades between all items in the shopping cart then a system could be devised to offer reasonable shipping options to customers. For example, the highest speed grades combined together (cost for each one added together of course), followed by the lowest speed grade combined together. There are different ways this could be done but as long as the customer sees 2 or 3 different options it should be enough for most situations.

@Havouza said in What is going with the Paypal module? EU, USA modules?: All EU by law, but the banks is probably reluctant if they dont know you I have several multi-currency accounts here in Japan, including one with Shinsei Bank who gives the best exchange rates I have ever seen from a bank. IF you get to their Gold (easy to attain) or Platinum (still not so difficult to attain) customer level the rates are even better. Unfortunately I can't make use of it with PayPal or Stripe. :(

@Havouza said in What is going with the Paypal module? EU, USA modules?: We sell on Ebay also but to higher price than in the shop. And explain why the price is higher. I have notised many customers that buy first time on ebay but next time directly, because they find the shop address in the delivery note This is our goal as well. We sell about 80% on eBay right now and about 20% to repeat customers who just contact us by email. With the website we hope to reverse that and sell about 20% on eBay and about 80% away from eBay. Ideally 10/90, but I'd take 20/80 too.

@MockoB said in What is going with the Paypal module? EU, USA modules?: @dynambee I'm not sure if you could accept withdraw in multiply currencies. I think if your bank account is in eur and you wish to withdraw usd there is no way to get over their exchange rate. In some countries PayPal and Stripe allow you to specify the currency of your bank account. You can add multiple accounts, each with a different currency -- of course the account actually needs to match that currency or you will probably have problems with your bank! Once you have this set up you can withdraw from PayPal in multiple currencies without having to do conversions at PayPal's rate. This service is offered in most (all?) EU countries but outside the EU you generally are forced to convert at PayPal's exchange rate to your national currency before you can withdraw funds.

Looks like Stripe and PayPal are both nicer to EU companies than to US or JP companies. In the US and Japan currency exchanges upon withdrawal are forced to the national currency. In the EU that's not the case and accounts can withdraw in multiple currencies. While there are certainly downsides to heavy regulation there is the occasional win too, and I'm betting this is one of those wins.

@Havouza Unfortunately here in Japan even if you have a USD-denominated PayPal account they force you to convert to JPY before withdrawal. It's one of the reasons we have a US company as we can then bill in USD and manage the conversion ourselves. In the end though the higher rates just get passed along to customers as part of the price, just like PayPal fees and any other costs or fees needed to sell. If more consumers understood this I think sites like eBay would quickly go bust.

Most of these brokers cover their losses by different kind of fees, and they do it well it seems. Paypal is one of them and the worst fee is if you get paid in one currency and then either want to pay a supplier in another currency or want to transfer the money to your bank account that is in another currency. No one has as bad exchange rate as Paypal PLUS a fee. PayPal doesn't charge a separate fee for exchange, at least not here in Japan nor in the USA. The exchange rates they give are terrible though, and that is how they make a lot of money on FX transactions. Some examples: Current xe.com TTM midmarket EURUSD rate: 1.11525 Typical bank TTB rate, based on current TTM rate: 1.10525 Current PayPal Rate: 1.08403 Current xe.com TTM midmarket USDJPY rate: 111.561 Typical bank TTB rate, based on current TTM rate: 110.561 Current PayPal Rate: 1.08035 Etcetera. They are not great rates but there are no separate charges. Maybe you guys in Europe get screwed even worse, I'm not sure. The big credit card brokers mainly use the official bank rate I've never managed to find a card processor that does this. Most give TTB -1% or -2%, better than PayPal's typical TTB -2.5% but not always a huge difference. Based on Stripe's website they say 2% from TTM, so they're better than PayPal but if you're a high volume PayPal customer you'll get better fee rates with PayPal than Stripe, so it about averages out. None of this changes anything about using rolling reserves and payment holds for risk management. No credit card processor would stay in business long once it got out that they weren't properly managing their fraud risk.

@Havouza said in What is going with the Paypal module? EU, USA modules?: I sell in 4-5 EU countries and use Paypal, except in Sweden where we use a national broker that has also invoice possibility. Its expensive machines most. But for the rest I am not interested in being a bank and because abroker want to earn money. I pay in advance to the supplier for all sold goods Why should I have to wait. There is no technical problems. The delays are frustrating and I'm pretty unhappy that Stripe Japan is doing the same thing to all Japanese accounts. However from the card processor's standpoint it is risk management. The card processor is extending the store owner credit by allowing the funds to be withdrawn before the customer has received their goods, but this is something that many store owners don't seem to grasp. If the goods don't arrive, are damaged, or were never shipped to begin with, the customer will open a complaint with the processor (PayPal, Stripe, etc). If the store owner has disappeared or gone bankrupt then it is the credit card processor who will be on the hook for those funds. To mitigate this risk many processors use rolling reserves or payout delays. PayPal generally only implements these types of things on accounts that have shown a higher degree of risk. However if you open a new PayPal account and try to run $100k of sales through it in a short period of time you will quickly find your account restricted while they ask a lot of questions to make sure your business is legit and that PayPal won't be on the hook for $100k in customer claims. And especially when different merchants are treated differently depending on where the have the business Long payout delays by credit card processors are unfortunately very common here in Japan so it doesn't surprise me too much that Stripe is doing the same thing here. Pretty much anyone can open a Stripe account and accept credit card payments and that means there will be more higher risk individuals using their service. It sucks for me (low risk business owner) but I do understand it from their side as well.

Very interesting post! I spend quite a bit of time looking at the PS / 30bz database tables directly while working with the API so it's interesting to hear about what has changed. I'd upvote you, but the site seems to give a very limited number of upvotes per day, and I've run out!

@yaniv14 said in Duplicate friendly sub-category URLs from within different categories: I haven't tested this yet, but maybe you should take a look at the new section "duplicate urls" under preferences. Does this exist in 1.0.1? I looked but can't see anything there. If not, how do I add it to try it out? The idea is to get a new name to one of those categories, like: korg-1 or something. I read the thread where one user proposed adding IDs to category URLs to avoid collision problems, and adding numbers to create unique category names is also possible, though not particularly visually appealing. Another idea would be to include the category path in the URL instead of just the final category. In this case instead of both URLs converting to /korg, one would convert to /audio-video-equipment/by-brand/korg and the other would convert to /musical-instruments/by-brand/korg. The problem is that I don't know if the longer URL path is a good idea or if it is even possible in 30bz. On the surface including the full category path in the URL (or having the option to do so) seems like an elegant solution. On the other hand I have no idea what the downsides are (SEO? technical?) to doing this. About being penalized, why do you think you will be penalized? I've never run a site where I had to be actively concerned about SEO before. I'm learning but it's still somewhat of a black art to me. Conventional wisdom seems to be that including IDs in URLs is bad for SEO, but as shown in the thread you linked to, not everyone thinks this way. It certainly looks inelegant to include IDs in URLs but looking inelegant doesn't always mean it's a bad solution. Likewise, something looking nice (like a category path URL) doesn't automatically make it the best choice.

I've now uploaded about 1000 products to my development store, complete with creating categories, manufactures, etc. This has all be done over the API, which so far has been working very well. Today however I came across a problem with the friendly URLs. I suspect this problem may exist "by design" but I would like to confirm. One thing we have with certain categories is a subcategory "by brand" with the various brands listed under it. Many brands make more than one type of product so their brand can exist in multiple places. Korg for example makes both AV equipment and musical instruments, so we have the following two categories: https://www.inxonline.com/index.php?id_category=448&controller=category and https://www.inxonline.com/index.php?id_category=587&controller=category However when I enable friendly URLs these both get shortened to "korg" with no category path included in the URL: https://www.inxonline.com/korg The friendly URL won't work right now because I turned the feature off while I figure this out. Is there anything that can (or should) be done about this? If it's really necessary I can remove the "by brand" sections, but if there is an effective workaround that won't penalize SEO then I'd be interested in learning how to make it work.

@ssimard PayPal bought Braintree some years ago and I think they might have the goal of moving their direct credit card processing business off the PayPal platform and onto Braintree. AFAIK they haven't stated this publicly but the changes they are making kinda-sorta-maybe (it's PayPal after all...) seem to point in that direction.

Unfortunately the Prestashop shipping system is quite weak. If you have items in your store that require a separate carrier (oversize items, for example) then the checkout will crap itself if a customer tries to buy one "special carrier" item together with a "normal carrier" item. If the checkout can't find at least one carrier shared by all items in the cart it will try to combine different carriers together and give a total price, but it won't show any text to the customer explaining what the different shipping options being proposed are. :unamused:

@MockoB said in Different shipping rule for different categories: What if customer buy only products which are free delivery? The customer will see two carrier options, one free and one not free as all products in the cart will have free and non-free shipping options available.

@ajensen27 said in Onepage Check-out like presta 1.7: We are all brainstorming. This is always a GOOD thing for development. Checkout is the most crucial part of any e-commerce store so making it the best it can be by brainstorming ideas, especially from a community of e-commerce store owners, is a GOOD thing. Brainstorming is a good thing before development begins. Once a project is well under way having a bunch of different people try to pull it in their own desired direction is a nightmare. I speak from volumes of personal experience in my past corporate life, unfortunately. As I mentioned above, there are also limitations to what is possible for the standard checkout process in 30bz 1.0.x. There will be more flexibility in future versions but the standard checkout will always have to support things like multiple payment gateways which make certain designs difficult or impossible. Not all sites need these types of features but as it is the standard checkout process it has to provide them because some sites will need them. I'm sure there will be 3rd party checkouts offered at a later date once the 30bz modules & themes store goes live. Finally, @mdekker is the only developer actively working on 30bz right now. I think we all need to be more appreciative of the time, effort, and skill he is contributing. He's doing a kickass job and 30bz is already light years ahead of where PS 1.6 ever was.

@ajensen27 said in Onepage Check-out like presta 1.7: You apparently haven't done much research on the subject of guest checkout (see my post above). And guest checkout still stores the customers name, address, etc for tax purposes. It seems you didn't understand what I wrote because your reply basically agrees with my post.

@wakabayashi said in Onepage Check-out like presta 1.7: @dynambee I think this discussion helps @mdekker to make a good checkout. It's not so easy to customize checkout for coders/designers... It has to be good in core already... There are some limitations to what is possible with the standard checkout due to the need to support multiple payment gateways and the need to maintain PS 1.6.x compatibility for now. Not all sites need these things of course but some do and as this is the standard checkout process it needs to provide them. I'm also a developer (though unfortunately I don't know PHP) and when there are many users trying to pull the discussion in different directions it becomes difficult to form a cohesive plan to move forward. I contributed to this myself above, but looking back at all the messages it is IMO too much information and too many requests. There are also time limits and making constant changes to the design becomes a huge time sink. We've already seen the great improvements that @mdekker has made to 30bz and I think he'll do just as good a job with the new checkout process. If it turns out there are problems they can be addressed in future versions & revisions.

@DavidP said in Onepage Check-out like presta 1.7: Yes it is a mess in PrestaShop but it's a psychology effect, people feel it's more anonymous, are lazy or feel they don't want their personal information recorded. Guest checkouts are proven to increase sales in certain markets. I personally use them all the time via PayPal payments so my details aren't recorded. I understand what you're saying and I agree that having guest checkout enabled is a good idea for most shops. However not creating an account changes nothing* about what information the store keeps or doesn't keep with regards to your sale. For physical goods they will have your shipping address, for any sort of goods they will have your email address. Anything paid by PayPal gives at least your name and an email address. If you're paying by credit card then the site owner gets all sorts of information from the card company. Any legitimate tax paying business has to keep basic customer records in case of an audit and some companies must keep more than just basic records. For my business, for example, we have to have names, addresses, proof of export shipment, and of course details about what was purchased. We have to maintain these records for at least 7 years. * Well, technically it means they don't store your hashed password, but everything else is the same.

I think at this point we should trust @mdekker to produce a much improved checkout experience for standard use in 30bz. It sounds like he has made great progress, and no matter the exact path taken there will be no one design that fits exactly with each user's perfect checkout wishlist. Once the 30bz module & theme store goes live there will no doubt be 3rd party checkout solutions available that are tailored to the needs & desires of different segments of the 30bz community.

@alwayspaws Some hosts make it very easy to duplicate a website. If you're not sure how to do it you may find details in your hist's help area or you may need to contact support and ask them for help. Both the files and db need to be duplicated and you will need to update PS to point to the new copy of the db. You'll also need to update the domain setting in PS.

@alwayspaws said in Install PS in test site, then migrate it to thirty bees - good idea?: What thoughts do you have about putting a copy of PS 1.6.1.11 in a test environment and then migrating that to thirty bees? Do you want to do a test migration of an existing shop? If so then making a copy of your existing shop and doing multiple test migrations (modules on, modules off, etc) is an excellent idea. It's always advisable to do one or more test migrations on a non-production copy of your shop before doing any migration or upgrade on a live shop. Of course when you do finally migrate your live production shop you should make a full backup first in case something still manages to go wrong. It's always easier to restore from backup than to try to fix or roll back a borked upgrade or migration.

@mdekker said in Currency format: The format depends on the locale (so both country + language). We thought that CLDR would be perfect for this since it has all the combos. Perhaps using that as a basis, but allowing for an override per language/country combo might be a better idea? This sounds perfect to me.

Thanks everyone. It seems like something that would make an ideal standard back office option for 30bz, but I'm sure there are other higher priority things to implement. For now I will manage this through the API by setting the "displayed" option as needed depending on if there are any available items in a given category.

Is there any way to automatically hide categories (front office) that don't have any products assigned to them? Basically if there are products in the category I want customers to see the category. If there aren't products in the category then I'd prefer if the category doesn't appear in the front office.

It does seem like having an easy way for ~~customers~~ site owners to determine the currency format for each country would be a nice touch. Even though a given country may have an "official standard" for currency format it's quite possible that multiple standards are used in practice and/or depending on the region of the country. Edit: As noted. No idea what I was thinking.