haylau

Our default country is the United Kingdom Our shipping methods are based on Postcode (zip code) so we have states disabled. This means when a customer goes to the shopping cart they get the generic "no shipping options available" until they add their address. Can anyone think of a way of setting a default postcode (hidden) so that some shipping methods are shown. They will be automatically updated when the customer adds their own address

We continued to have those issues with the Prestashop module on thirty bees. However we recently switched to the ThirtyBees paypal module and we have not had any of those issues - Yet. I say "'yet" becaause the issues were random and we could go weeks without it happening previously. So fingers crossed it is now ok. I do believe the way the ThityBees module works is different to the Prestashop one so hopefully all is OK

It is really funny that people are often happier to phone and give card details to someone they do not know rather then enter them into a secure wesbite :)

You type in their card details onto your checkout? What if 3D kicks in and asks or their password details (Visa / mastercard) We were warned not to do that. Apart from anything you need to be fully PCI compliant. Even so, you will not be able to do that after Semptember as that extra check will be much more widespread

Hmm, good question I will ask them. Is SCA not just for online sales though? Perhaps if someone is talking to us directly on the phone / in person then it is not the same system

We tend to create the order on the front, not back office. Our welcome email says "if this account has been created for you please use the forgot password link to re-set the password" For payment we have an "office use only" payment. We take the card details over the phone and use Paypal virtual terminal for this situation.

Yep - hopefully that will help someone to help you. do you have any modules installed that add functionality to the product page in admin? For example we have PRODUCT EXTRA TABS installed by the Panda Theme Try disabling all those modules which will show if it is a conflict. Not sure Panda has been certified yet

Any clues in the browser console?

It has 3d checks -is that not the same? When I enter card details it does ask for postcode as a check and also the 3d Mastercard page appears) However if we use the checkout form rather than the card form then it goes to the stripe checkout page so that should cover it? I will also talk to the devs and see what they say - Damn Paypal for spoiling my life !

Yes we are use a third party OPC module (PRESTEAMSHOP)- and the Panda theme. I have rolled bacl by deleting module and re-installed the earlier version and that seems to be working (touch wood)

With stripe checkout enabled, customer can click the button in the cart without filling in any details such as name , address, choosing carrier etc Also now getting this VM680:37 custompayments <p class="payment_module">…</p> VM680:37 stripe <p class="payment_module" id="stripe_payment_button">…</p> v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:4 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. send @ v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:4 quick-order:1 Uncaught SyntaxError: Invalid or unexpected token at v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:3448 at window.checkOffer (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:3439) at callback_placeorder (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:3447) at callback_load_address (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:3465) at Object.complete (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:3466) at Object.complete (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:2812) at j (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:2) at Object.fireWith (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:2) at x (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:4) at XMLHttpRequest.b (v_55_e5d76424a76f0ac34aaa82e1467f2b8d.js:4) i want to cry

Actually the stripe checkout does not work either as it bypassess all of the log in systems.

We are in the process off working with Stripe. Looks good. Just a shame we are having to say goodbye to £4000 a month turnover in Ebay!

Installed. We only had the STRIPE CREDIT CARD FORM enabled. When customers make payment it is not processed. Our website just says "submitting" continually. But I can see the log (not payment) in Stripe. I have switched that off and enabled Stripe checkout and that seems to be fine { "payment_method_types": [ "card" ], "amount": "67", "currency": "gbp" } Response body { "id": "pi_1EvMDdIPi9KHxLDypCzeLcDL", "object": "payment_intent", "amount": 67, "amount_capturable": 0, "amount_received": 0, "application": null, "application_fee_amount": null, "canceled_at": null, "cancellation_reason": null, "capture_method": "automatic", "charges": { "object": "list", "data": [ ], "has_more": false, "total_count": 0, "url": "/v1/charges?payment_intent=pi_1EvMDdIPi9KHxLDypCzeLcDL" }, "client_secret": "pi_1EvMDdIPi9KHxLDypCzeLcDL_secret_M2YQlC21Rgs3rRZEmpedj8wph", "confirmation_method": "automatic", "created": 1562928193, "currency": "gbp", "customer": null, "description": null, "invoice": null, "last_payment_error": null, "livemode": true, "metadata": { }, "next_action": null, "on_behalf_of": null, "payment_method": null, "payment_method_types": [ "card" ], "receipt_email": null, "review": null, "setup_future_usage": null, "shipping": null, "source": null, "statement_descriptor": null, "status": "requires_payment_method", "transfer_data": null, "transfer_group": null }

Because we started selling on Ebay then to our own website we have PayPal - and they are (were) our only payment processor. They have switched us off! No warning, no discussion, just an email this morning saying they did not want to work with us any more. Apparantly we are too risky. Obviously we are not risky at all, we sell nuts and bolts. We have never had a claim against us and keep over £20000 in the account and a monthly turnover of around £30000 I am of course trying to appeal, but it is difficult to appeal when they have not told us why we are too risky and there is no real appeal process and we are not allowed to talk directly to the reiew team. Only standard support are allowed to send them a message andthe review team "might" respond. But probably not I actually think this is a PayPal website glitch. They asked us to apply for their new debit card which we did and they asked for some documents to upload which we can't because everytime we try their site crashes (multiple browsers, multiple computers) So that is it. With no prior warning we are stuck with over £20000 in the account that is on hold for 180 days. We have to effectively close our £5000 per month ebay account as you cannot sell on Ebay unless you offer PayPal Our website also naturally takes a hit. Luckily a very quick review of thirtybees modules pointed me to Stripe and that is now installed and up and running. So we do have some consolation (actually liking the look of stripe anyway and will probably keep that even if payPal come back to us. And the Thirtybess module is great So really just wanted to say a couple of things 1) Sorry for the grumbling but I am well and truly pi**ed off after a very trying day 2) Thanks for a great Stripe module 3) To advice you all to "Be Prepared". Make sure you all have a fall back plan should your payment processor decide to put you under suspension for no reason

The problem is the logical conclusion of that avenue is that no one will see adverts. So companies won't pay for adverts so they will loose trade - and quite likely Google et al will cease to exist You have to laugh though, do a search for adblockers and they all pay for ads to be top of google.

I believe knowing what is an actual visitor is not an exact science because bots get in the way (perhaps also things like multiple tabs from same user, ignoring your own specific IP addresss) So for a few reasons I don't think thwo systems will ever give the same results as it may depend on which bots are being ignored (and whether those lists of bots are up to date) This i about wordpress, but principles remain the same I suppose https://www.monsterinsights.com/docs/why-google-analytics-stats-different-from-jetpacks-stats/

Agree - there are other platforms for auctions and so probably better for being specific. For me, I don't think TB needs to be any different to what it is other than improving existing features and appearance in line with current trends. (I would personally like the faceted search (Block layered navigation) to be much better implemented (perhaps to allow ranges and multiple choice)

Been using PS / TB for a good fews years and never even looked here :) So how does "send both" work. Does the customer actually get two emails?

We are using a third party module for caching. But even without that the Advanced Search module seems to use smarty cache and their own sql tables

I have seen various cache warmers that can be run to visit all the pages in your sitemap which then adds that page to cache so that the next time a customer visits they get the cached version. Great - works a treat - for standard pages Our problem is that some (most) of our pages are accessed via the Advanced Search filter system. Basically customers use filters based on features and the URL is effectively created on the fly (Ajax??) See here: https://u-bolts-r-us.co.uk/125493-u-bolts So that link is the main page that is cached by the warmers. But when I select a filter the page Url changes to perhaps https://u-bolts-r-us.co.uk/125493-u-bolts/s-5/distance_between_legs_of_u_bolt-10:15 Or https://u-bolts-r-us.co.uk/125493-u-bolts/s-5/material_finish-t316_stainless_steel_a4/distance_between_legs_of_u_bolt-10:15 And the URL's can be quite random depending on the choice the customer makes So those pages do not exist for the cache warmer looking at the sitemap While the advanced search module do use a cache, everytime the product is updated (price, stock levels) or the search index is reset the cache is refreshed. Unfortunaltey we update stocks and prices 4 times a day. Even if I reduce this to once per day it does mean the cache is effectively useless So looking for a solution. I do have a couple of warmers I am working with https://canonicalized.com/prestashop-speed-optimization/?section=cache-module (not sure how to actually activate this one yet) and the one I am actaully using: https://github.com/khromov/sitemap-cache-warmer But can anyone advice if it is possible with any of these (or something different) how to make them visit the "filtered" results . Perhaps this could be with the URLs manually added to the program or manually added to sitemap Looking for inspiration

Thanks - So bleeding edge is safe to update to on working stores? Just thet "bleeding edge" sounds right on the limit as though it may still be dodgy. But you are saying no problem, bleeding edge is safe?

So for us non techie types wondering how and when we should upgrade. I checked our BO and see three modules. I "think" thirty bees updater v 1.4.1 is the original updater. Git based and Core updater (are they actually the same??) Are we now supposed to use Core Updater V1.01 and choose the bleeding edge option

Two reasons. 1) Because there are hundreds / thousands of products and would not want to go through each one in turn (and how would that work with combination orders) But mainly: 2) Because the examples were very simple examples. In reality it is a lot more complex. Where for example product 3 may be only 10g and cost £10 each so OK to send 1 by the cheap slow carrier 1, but if the customer purchase 100 we would not want to use carrier 1 even though the weight would still fall in this bracket. In that case carrier 1 may be £1.50, where as carrier 2 with tracking would cost £10 so customer would always choose the cheap carrier and we loose money. Again this is an simple example, reaility is more complicated with perhaps 10 carries and different postcodes. So carrier 1 may be £5 for postcode 1, and £20 for postcode 2 I know the OP has not mentioned tracking. They did not need to I was only giving an exaple of how and when a combined weight / price limit was appropriate. It is the kind of thing where country, product types make a difference. So I dont know what you sell or where you sell it. All I can say is that I know what solution I need (and I guess the OP) because of our particular business operates. Anyway enough to say that it is very complex and that there is a genuine need for a combined weight / price limit scenario - believe me I have been trying to get this right for over 7 years!

@Brent Dacus - No. You have misunderstood. It has to be a combination of both Example Product 1 weighs 100g and costs £1 . Carrier 1 and Carrier 2 can be shown . Carrier 1 is slow, cheap and does not have tracking, carrier 2 is exensive but quick and with tracking Product 2 weighs 100 g and costs £100 - carrier 1 is no good becuase it does not have tracking carrier 1 should be disabled and only carrier 2 is available