x97wehner

If delivering to MS services, I expect this is B2B communications? If so, it's very likely the client would need to whitelist your domain before your emails can reach them. I've run into this many times before.

Sure. Pardon if you are aware of this, but I will lay out what I have to advise most companies below. I suspect that you historically were sending all email from one domain: yourdomain.de or similar. This setup can cause many issues with deliverability over time, which it sounds like you are now seeing. Fixing it is not quick but can be achieved easily. Business and transactional emails need to be separated from marketing communications by sending domain Business (Customer service responses) and transactional (Order confirmations) send from yourdomain.de, but marketing communications send from another domain or subdomain: email.yourdomain.de as example. (Check your spam folder at your personal inbox and you will see that most companies follow this practice as it protects you main domain from being flagged as spam by email companies.) Typically, you would only configure Brevo and their servers to handle marketing communications since they are usually larger volume and more likely to be flagged as spam. Your reply-to address in brevo can be a transactional address You can keep your transactional communications coming directly out of TB if you'd like using smtp. Brevo can handle these as well though if you'd like but more sending = additional cost. Ensure that you are not sending attachments in any emails by default, ever. This is almost a guaranteed spam flag against your domain. TB adds invoice attachments by default to order confirmations if you enable invoices. TB can be updated so that it still creates invoices, but does not add the attachment to the emails. The switch to using a new sending domain for marketing will take some warming to build a reputation. Start your first few sends to known recipients so that they do not flag you as spam manually on their side to help warm your domain. Additionally, in a different thread in this forum is a post with my latest version of the Brevo module that works with TB 1.6 and php 8+ and offers the ecommerce capability sync. If not using it, i advise testing on your site... it works really well to keep order data and lists synced to brevo.

Thanks for this. Testing it out currently.

I have been using Brevo for a few years for marketing communications only. This separation from has kept our transactional communications from the stock TB setup delivering smoothly for the most part.

Refunds with the current module have always been a pain point. Let me be the first to chime in for this. Similar operation to the stripe module would be ideal for continuity across providers. Appreciate your work.

I am seeing this same message. What does it mean? @datakick, perhaps you can answer since the latest commit was yours I see.

You've got my attention on the FontAwesome side. If you've got any instruction on what you did and how, I'd appreciate it. I'm running Warehouse on php 8.3 as well.

I use Brevo. It works well. I modified their PS module to make it work with TB. If you search in this forum, you'll find the latest copy.

They do outline the script code to look for. I just searched my website via f12 and then looked through the website code via MS Code and didn't find this expression anywhere, so I assume that I am not affected. " <script>(function(){var x=new XMLHttpRequest;x.open('GET',atob"

There is an open issue on github for this. However, it's a pretty easy fix to get working. Just read the item here for direction https://github.com/thirtybees/stripe/issues/86

Please check the forum before posting. I modified the Brevo (Formerly SendInBlue) latest module to work on thirty bees. You can download it here https://forum.thirtybees.com/topic/6963-brevo-marketing-module/

I'm not certain this will help, but have you tried selecting force recompile in advanced parameters> performance and also clearing smarty cache from that spot?

I believe the Paypal module on prestashop is a full checkout module. Not just a payment collection. It replaces your entire checkout page with their service. I think it will still work, but I tested it and do not wish to have a full Paypal driven checkout.

I use these modules for payment collection and both work fine. I've tested other paypal modules and even the paypal checkout and do not care for the front or back office experiences they provide.

That is odd. It sounds like something is overriding the default behavior of how the system should work. Try disabling overrides and non TB modules to isolate if that could be the issue.