30knees

Thanks. ws_key works in the browser but the third party still isn't working. I'll trouble their support some more and if that doesn't work I'll submit a ticket with you.

I am trying to connect a webservice to domain/api and get a 401 error. Using Insomnia, I see this reply: < HTTP/2 401 < server: nginx < date: Tue, 09 Apr 2024 12:53:23 GMT < content-type: text/html; charset=utf-8 < www-authenticate: Basic realm="Welcome to PrestaShop Webservice, please enter the authentication key as the login. No password required." Does anybody have an idea would the problem could be? When I try connecting via the browser https://www.domain.com/api?Authorization=KEY I get the pop up asking for username and password. I enter they key as username and no password and the pop up keeps asking.

I am curious about this. Does that mean that eg all order confirmation emails should typically have a minimal delay?

Is this still current?

I've used Panda and Community. I'm now with Community. I found Panda to be better in terms of customisability but they stopped updating it, which is why I switched. I believe Panda has been updated in the meantime.

I'm getting a couple of these via PayPal. Did your customer use PayPal and are you using our tb native module?

Does nobody else have any problems?

As this is a tb native module, would you be able to help here, @datakick?

No problems so far. I see that the module offers Stripe Checkout: https://docs.stripe.com/payments/checkout I have selected it. Does the Checkout integration use this feature? https://docs.stripe.com/payments/dashboard-payment-methods Because I cannot get Apple Pay to show, see here: If Apple and Google Pay don't work, is it a major thing to implement them, perhaps using the dashboard payment method? See:

Is it ready "enough" to test in a live site? Then I'd be happy to test it.

Thanks. Please also let us know if you don't update the module so we can then look for another solution.

Thanks, Adik. By the way, do a lot of customers sign up for SMS notifications? Might be a nice thing to offer. I've noticed that customers don't always check their emails.

The Stripe module looks good. I prefer to support our tb native / developer modules, though. I'm hoping our native Stripe will be updated (happy to pay for it, too).

I got this email from Stripe about the tb native Stripe module rearding required changes. Will tb be updating the module and perhaps also adding other payment methods? We’re reaching out about changes that are required to your Stripe integration. You are currently accepting giropay, Przelewy24, iDEAL payments using the Sources API, a legacy integration that will be deprecated on May 15, 2024. Starting May 15, all non-card source types will be turned off on the Sources API. In order to continue accepting giropay, Przelewy24, iDEAL, you’ll need to upgrade to the Payment Intents API. How to update your integration Follow the instructions in our Docs to upgrade to the Payment Intents API, and then add giropay, Przelewy24, iDEAL to your payment flow. You can visit the Stripe Dashboard to view your recent Sources payments and confirm that you have no remaining traffic on Sources once your migration is complete. If you choose not to update your integration, we recommend that you remove giropay, Przelewy24, iDEAL from your checkout to avoid customer-facing breakages. Additional benefits of upgrading to the Payment Intents API Payment Intents is a simpler and unified payments API that supports a single, global integration for all payment methods. On Payment Intents, you can access our optimized payment surfaces like the Payment Element or Checkout, which offer: Access to more than 100 global payment methods when using the Payment Element Ability to run A/B tests for payment methods to understand their impact across conversion, average order value, cost, and share of wallet, right from the Stripe Dashboard Compatibility with Link for one-click checkout, Radar for fraud protection, and Terminal for in-person payments We’ve provided answers to the most common questions on our Sources migration support page. If you have any further questions, please reach out to our dedicated support team by submitting this contact form. — The Stripe team

The latest stable version is 1.5.1.

And a follow-up question: Is there any analytical benefit to using the native Matomo module compared to just using the tracking code? Also, sometimes when I visit the settings page I get this error and then suddenly it's gone again, without any changes being made:

I'm unable to get the use proxy script feature to work. While researching, I came across these instructions: https://github.com/matomo-org/tracker-proxy?tab=readme-ov-file It doesn't look like the files mentioned that should be downloaded are installed via the tb native Matomo module: Is this because the native module is out of date or is it because of something else?

Yes, how to get 500 users. For sure it would need to go out to the theme stores and be promoted in the Prestashop forum. I would like to know how many people here in the forum would pay you how much for your theme and pay up front eg a two-year subscription. Of course, we've not seen the theme. But assuming it's sweet and we all love it. :-) And in order to really show that people mean it, they could pay a non-refundable deposit. And you could say: I'll only go ahead with this if at least XX people make the deposit.

Has anybody gotten Apply Pay to work?

@Smile, do you have any plans?

Agree. It's also hard to find a good theme designer. If anybody knows somene, please share. :)

I noticed that orders with an "awaiting payment" status have a payment prepopulated for the time of order creation. Why is this?

Was there a difference between the payment methods by any chance?

Hi, Is it possible to sort / order the payment methods in Chex beyond via Modules>Positions? So eg within the Stripe module the individual payment methods? Or would this have to be done via the Stripe module (which does not offer this feature)?

I've noticed that for some intra-EU orders that use the Mollie module the taxes are wrong in some places and correct in others. Settings applicable to all examples that follow: I am based in Germany. I use EU Advanced Compliance module (in case relevant) with proportional taxes for shipping. Payment using the Mollie module (not all payments via Mollie are wrong, though). Example An order from France. The order has items with the standard and with the reduced tax rates. These should be calculated using the French rates. Observations id_tax in order_detail_tax shows me only one wrong tax id (Germany, reduced) with a wrong unit_amount and total_amount. Where does this get filled from? tax_name and tax_rate under order_detail show me only wrong German taxes, not Austrian ones. The tb generated invoice shows me the correct French tax rates. Where else might I want to check to figure this out? How to check yourself The file orders-eu-tax2.php in the excellent Prestools https://www.prestools.com/Prestools_Suite.zip can help you see if there's an issue. Looking at Austria, I can see that 5 orders (column Ordercount) use a tax rate of 7% (column Tax rate), which I know is Germany's reduced tax rate. Austria's reduced tax rate is 10%. You can click on Ordercount to see which orders are affected.