Advanced Search

Hi,

Thanks for all the valuable details.

1.a Yes, the PayPal Checkout plugin always use an in-context / popup flow that depends on JavaScript fetch requests.
This is how it is supposed to be done as per PayPal Checkout's API.

1.b

Some iOS WebKit builds aggressively block fetch requests immediately after closing an in-context window.

I didn't know this. That sounds strange. I would recommend activating the "debug" of the payment method. Then, check the "payment log file" of the HikaShop configuration. The payment plugin will log debug data in there on the server side while processing the fetch request. So, you can confirm whether the request reaches your website or not. It's possible that for some reason, there is some kind of error on the server side which leads to the response not being provided. You can also check the access log of your web server to confirm whether it sees the request or not.
If nothing is logged by HikaShop or the web server for the request, then it's likely that either the browser or the OS blocks the request before it can even get out of the phone.
If you get debug data for the request, then maybe there is something that can be done to fix the problem. For example, if the problem is that the request takes too long to process and the connection breaks before, something could be done to reduce the response time. However, since you said that the order is not even being confirmed, I doubt that something can be done on that end.

2. PayPal Checkout's API doesn't do that. However, their old API does. HikaShop has the PayPal payment plugin pre installed for it. This has been the workhorse of HikaShop for years in the past and it still works fine. It will redirect to PayPal at the end of the checkout, avoiding this fetch issue. So that could be an option. The plugin is marked as "legacy" as PayPal wants to sunset it in the future, but so far, no date has been decided for that.

3. Yes, that's normal. The system takes first into account the "error" parameter and the errorTitle and errorMessage are only changed and taken into account when the error parameter is set to true.

4. Removing the popup is not possible.
Following your messages, I've looked into it and found this page:
github.com/facebook/react-native/issues/35384
It says that the issue happens with POST requests and not with GET requests.
If you check the plugins/hikashoppayment/paypalcheckout/paypalcheckout_end.php file you can see :
{method: "POST"}
in several places. So the JS does a POST to fetch the request. However, the request could actually be made with a GET as it doesn't to transmit any data in the POST. We just used a POST because that was what was written in the example code provided by PayPal and it should normally work the same either way.
But maybe changing this to:
{method: "GET"}
could help circumvent the issue with iOS.
I would recommend trying this.

Hi,

1. We are not aware of such problems with mobile devices. As far as we know, it works properly, the same way as on desktop.
2. No, no modification should be necessary.
3. It is not a known issue.
4. No, it should not be.

Normally, when an issue like this happens, it means that something unexpected happened between the JS added by the plugin on the page and PayPal. More details about the problem should be available in the console of the browser.
So, if the problem was reproducible on desktop devices, I could look into it from where I am with my computer's browser.
Since this is not possible, I see 2 possibilities:
- This page stackoverflow.com/questions/37256331/is-...ome-on-android-phone presents several solutions to be able to check the console on a mobile device: using the Kiwi browser + its mini console extension, Chrome remote debugging, adding eruda JS tool to your website, etc
- 10 days ago, we released HikaShop 6.1.1:
www.hikashop.com/support/documentation/5...ashop-changelog.html
The update via the Joomla extensions updater system is not yet activated as we're waiting for a bit more feedback from early adopters. You can manually download the latest version install package on our website and install it on yours to get the update.
If you read the changelog of this new version, you can find this fix:

We fixed a javascript error which could happen in some cases on Joomla 5 on the payment page of the PayPal Checkout payment plugin when the payment would not succeed, preventing the plugin from displaying the error message to the customer.

This should hopefully allow you to get a better error message, properly explaining what is wrong.
So, this is the first thing I would recommend trying.

Hi,

The console indicates there is a PHP error.
You can see at the bottom left corner of your screenshot the text "SyntaxError: Unexpected token" which points at a PHP error, when it is expecting a JSON text to be returned by the server.
This is probably linked to the error you had in your second screenshot in your first message.
Are you not able to reproduce it with the "debug" setting of the Joomla configuration page activated ?
The extra details would allow us to tell you what to do.
Otherwise, PHP error log should also contain the full error message if you have access to it.

And if nothing is possible, please provide a backend access via our contact form so that we can directly reproduce the issue on your website and investigate deeper.

Hi,

Are you now using the 6.1.0 on your website ?
Could you provide again the payment log, like last time so that we can check on the details ?

-- url of the page with the problem -- : newwavepeptides.co.uk/
-- HikaShop version -- : 6.0.0
-- Joomla version -- : 5.3.2
-- PHP version -- : 8.2.28

When the customer is on the payment option of the PayPal for where they can chose to click the PayPal button or fill in the credit card details, there is also a button that say 'Cancel and choose another payment method'

When you click this button, it goes back to the homepage and clears the cart.

How to I stop this from happening? I want them to go back to the payment selection page.

Thanks.

Hi,

When a payment via a payment gateway (like PayPal, Stripe, etc) is received for an order, the payment plugin will trigger the sending of an email to the customer for his payment. This will happen regardless of the "Send Details Of The Order" setting. It only depends on whether you've disabled or not the "order status notification" email via the System>Emails menu.

Usually, the status of an order being changed to "shipped" happens when the merchant manually changes the status of the order in the backend of the website. When he does so, there is a checkbox he can check to send an email notification to the customer. If that checkbox is checked, the "order status notification" email will be sent, provided it has not been disabled.

So, what you're asking for should already be happening, unless you don't check the "notify user" checkbox when you change the status of an order to "shipped" in the backend of HikaShop.

-- HikaShop version -- : 5.1.6
-- Joomla version -- : 5.3.1
-- PHP version -- : 8.1.32

Hi

Is there a way to set Hikashop to send a notification email to the customer when the status of their order changes?
Ideally I would like an email to be sent when the order status changes to 'shipped'.

We are using the Hikashop Paypal Payment plugin but have the option for 'Send Details Of The Order' set to 'No' as I think there was at some point, an issue with rounding up and Paypal which was popping up errors.
Is there a simple way to enable his email notification to be sent to customers when the order is set as 'Shipped'?

Many thanks.

Hi,

There is no dedicated integration available between HikaShop and Pirate Ship at the moment.
However, there are two ways you can use both together:

- If you use PayPal for the payments on your website, then you can link Pirate Ship to your PayPal account:
www.pirateship.com/integrations/paypal
That way, the details sent by HikaShop to PayPal for each payment will be sent to Pirate Ship so that you can have a seamless integration of HikaShop and Pirate Ship.

- You can use the CSV import of Pirate Ship:
www.pirateship.com/integrations/spreadsheets
You can configure a mass action on the "order" data with an action "export CSV file" in the System>Mass actions menu so that you can select the columns you want to be in the CSV file. You can also activate the "actions as a button" setting of the mass action. That way, on the orders listing, you'll have a new button with the name of your mass action. And when you select orders on the listing and click on the button, you'll automatically get the CSV for the selected orders. Importing on Pirate Ship is quite easy, and once you match the columns once, you won't have to do it again, so you'll save more time after doing it once.
While this is a bit more work than the PayPal integration, it should not be that much more work and this can work with any payment method.

Hi,

The order ID in HikaShop is incremented by 1 for every order. Based on your screenshots, I can see that the last order has the ID 2448. So you had orders previously from "1" to "2448". On the PayPal screenshot, it says that the "invoice ID" is 19893.
This means the transaction did not originate from HikaShop since it would have had an invoice ID between 1 and 2448.
Also, the description of the product purchased on the PayPal screenshot is "Total price Item #:".
But the PayPal Checkout plugin in HikaShop will either use the name of the product, or the text "Order number: XX" where XX is the order number of the order in HikaShop (when the "send order details" setting is turned off in the payment method). So again, this indicates that the transaction wasn't done through the PayPal Checkout plugin of HikaShop.

So it all indicates that the transaction comes from something else than HikaShop.

If PayPal says that the transaction comes from your website, then it must come from something else. What ? I don't know, but certainly not HikaShop.

Note that PayPal says that it comes from your website. What did they say exactly ? It could be that you have a test website or something, in a subdomain or a subfolder of your website, where you have another ecommerce solution setup (or half setup), or a PayPal, HTML button or something.
In any case, PayPal has all the log necessary to be able to point you at the problem. Normally, the PayPal support should be able to give you the exact URL from which the transaction originated. This should be enough to identify the origin of the problem. Could you check with them ?

Hi Nicolas

Thanks for the reply.
The email from PayPal saying a payment has been received shows a transaction ID and an Invoice ID along with an email address.
None of those things are showing in the Customers menu.

There are only two payment plugins currently enabled, Paypal Checkout and Bank Transfer (which as far as I can tell, simply shows bank details for the customer to manually pay with) although there are older plugins that are on there but they are disabled. These are PayPal Pro, PayPal Plus and PayPal Express. These have not been used for a long time.

Hikashop is the only e-commerce solution that has ever been used on the site and I am unaware of any PayPal HTML buttons ever having been put on the site.

Regards

Jim

Hi,

When PayPal Checkout transmit the order information to PayPal, the email addressand order ID are always provided to PayPal.
The email address of the user might not be associated with a Joomla user account, that's correct. However, the email address will be associated with a user in the Customers menu of HikaShop for guest purchases.
Also, the order is always created before the PayPal Checkout payment plugin does anything. So you will be able to find an order with roughly the same creation date as the transaction date, with the same amount.
And since the order is always created, the plugin transmits the order ID as the "invoice ID" in the PayPal transaction details page.
So you should be able to match the order and the transaction together. Also, in the history of the order, which you can see at the bottom of the page if you open an order, you'll see the PayPal transaction ID recorded. So, that's also a way to match the order in HikaShop and the transaction in PayPal together.

If there is no invoice ID in the transaction, and you can't find any order in HikaShop, then the payment likely didn't went through HikaShop.
Maybe you were using another ecommerce solution in the past and it hasn't been disabled properly ? Or maybe you've installed another extension which can accept payments. Or maybe you've added somewhere a PayPal HTML payment button ? This can be easily done with just a copy/paste in a Joomla article, so it doesn't require any specific extension. However, that means that no information is available on the website. So that would also explain the situation.

-- HikaShop version -- : 5.1.6
-- Joomla version -- : 5.3.0
-- PHP version -- : 8.1.32

Hi

Please help.
Over the last month, several emails have come through from Paypal saying a payment has been received but there are no order details included and no order number. We have contacted PayPal who say that the payment was made through the site however there is no order created in Hikashop.
All of these orders it seems are from email addresses that are not registered on the site so I'm assuming they have checked out as guests.
All I can see from the emails from Paypal is how much the amount paid, by which email address and the date and time of the purchase but no order has been generated in Hikashop..

I am more than happy to provided login details for the site if required.

Many thanks.

Bonjour,

1. Oui, si vous n'avez pas besoin du détails de la commande dans le détail des transactions sur PayPal, il est préférable de désactiver cette option. Elle est d'ailleurs désactivée par défaut pour cette raison. Ainsi, cette erreur ne pourra pas arriver peu importe ce qu'il se passe dans le futur.

2. Normalement l'affichage du coupon devrait se faire avec le plugin installé aussi (mais ce n'est pas le même code qui gère cela dans corporate_invoice.php ).
Lorsque le plugin n'est pas utilisé c'est ce code:Lorsque le plugin est utilisé, c'est ce code:Si l'affichage est manquant lorsque le plugin est utilisé, soit il y a un bug dans ce code, soit ce code a été modifié ou supprimé de votre côté.
Donc vérifié déjà que vous ayez le code dans le fichier et qu'il correspond à ce que j'ai posté.
Si oui, alors il faudrait étudier le soucis directement sur le site. Peut être qu'il y a un cas particulier qu'il faut prendre en compte.

Bonjour ... et tout d'abord merci pour avoir répondu pendant la journée de la fête du... travail! Ce n'est pas donné à tout le monde...

1. En effet l'option "send order details" est activé autant côté site de production que sur le site dev et l'option "round prices during calculations" est activé dans la configuration d'HikaShop des deux côtés.

En désactivant l'option "send order details" dans la méthode de paiement du site dev, le problème disparaît.
Étrange car la configuration était la même sur les deux sites et seul le site de développement m'a donné cet erreur, je ne pense pas que cela est arrivé sur le site de production sinon on me l'aurait fait savoir.

Pour récapituler, pensez-vous qu'il est conseillé de désactiver l'option "send order details" dans la méthode de paiement Paypal également sur le site de production?


2. Vous avez raison, le plugin "multicoupon" n'était même pas installé sur le site de production, comment ai-je pu oublier...!
Bref, je suppose que maintenant j'aurai le même affichage que celui sur le site de développement, c'est à dire le nom du coupon sera affiché et il sera placé en dessous de "Livraison".
Concernant l'affichage du coupon dans le plugin PDF (la facture du client), pourquoi l'affichage du coupon se fait quand le plugin "multicoupon" n'est pas installé? Je suppose que je vais devoir copier du code supplémentaire dans mon fichier media/com_hikashop/plugins/corporate_invoice.php ?

Merci.

Bonjour,

Voici les deux problèmes que vous avez:

1. L'erreur avec PayPal Checkout avec un coupon, c'est parce que vous avez l'option "send order details" activée dans la méthode de paiement. Surement que vous avez l'option "round prices during calculations" désactivée dans la configuration HikaShop, qui fait que PayPal calcule diffère de celui d'HikaShop, ce qui peut résulter en des différences d'arrondi, et cette erreur "amount_mismatch".
C'est une erreur courante.
Le plus simple, c'est de désactiver l'option "send order details" dans la méthode de paiement. Ainsi, seul le total sera envoyé à PayPal et il n'y aura plus de problème de calcul.

2. D'après vos captures, sur un des deux sites vous avez le plugin "multicoupon" actif et pas sur l'autre. Lorsque le plugin est actif, les coupons sont transformés en "frais additionnels" dans HikaShop et le nom du coupon est utilisé au lieu du texte "coupon", car vu que vous pouvez avoir plusieurs coupons, ça n'aurait pas de sens d'avoir plusieurs lignes avec le même texte générique "coupon".
Lorsque le plugin n'est pas utilisé, alors c'est le texte par défaut "coupon" qui est utilisé vu qu'il ne peut y avoir qu'un seul coupon par commande.

Bonjour, plusieurs problèmes à ne rien y comprendre...

Pour voir si j'avais le même comportement j'ai essayé de passer une commande avec le bon de réduction sur la livraison et ceci sur mon site de développement.

J'ai différents comportements, pourtant le site de dev est la réplique du site en production, à quelques détails près.

J'ai essayé de passer une commande et de payer par PayPal Checkout en version Sandbox: premier problème, il n'est pas possible de payer par PayPal si j'ai une réduction sur le prix, j'ai un message d'erreur qui apparaît pour une fraction de seconde, j'ai réussi à faire un screenshot du message d'erreur:



Si je désactive le bon de réduction, le payement PayPal Checkout en version Sandbox se fait sans problèmes.

J'ai alors essayé de payer par virement bancaire.

Version Dev: payement par virement bancaire.

- La réduction sur le prix de livraison s'affiche bien en dessous de "Livraison" ("Spedizione" en italien) dans l'email envoyé à l'administrateur et au client.
- Le nom du bon "SHIPPING50" s'affiche aussi correctement.
- La réduction du prix de livraison dans le PDF (oui, j'avais oublié de spécifier que j'utilise votre plugin "PDF invoice") ne s'affiche pas dans le PDF.





Version production: payement par PayPal Checkout

- La réduction sur le prix de livraison s'affiche au dessus de "Livraison" dans l'email envoyé à l'administrateur et au client.
- Le nom du bon "SHIPPING50" ne s'affiche pas, j'ai uniquement le terme "Bon".
- La réduction du prix de livraison dans le PDF s'affiche, mais le nom du bon n'est pas correct et s'affiche toujours au dessus de "Livraison".





J'ai un override du fichier media/com_hikashop/plugins/corporate_invoice.php qui est le template que j'utilise et les deux fichiers sont strictement identiques, d'un côté comme de l'autre, je viens de recontrôler.

J'aurai voulu passer une commande sur le site de production et payer par virement bancaire comme je l'ai fait sur le site de dev pour voir si la méthode de payement peut influencer le type d'affichage, mais je voudrais éviter de générer inutilement des ordres qui vont incrémenter la numération des mes factures.

Si vous pouviez me donner une piste par où commencer parce que je suis un peu largué... merci.

-- url of the page with the problem -- : www.shangshungpublications.com/
-- HikaShop version -- : 5.1.5
-- Joomla version -- : 5.3
-- PHP version -- : 8.2

Hello, on the site shangshungpublications.com/ , an order was paid with Paypal but was not put in payment accepted, so it was not automatically put in paid.
Below is the error:Thanks

Hi,

I'm not able to access your link. I'm getting redirected to the page www.elster.de/eportal/login/softpse which requires to login, but I don't have an account on that website.

The order number is added as the sales order id:
docs.peppol.eu/poacc/billing/3.0/syntax/...ce/cbc-SalesOrderID/
The order invoice number is added as the invoice id:
docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cbc-ID/
So I don't think there is a problem there. Please double check.

Please note that the plugin output invoices for orders already paid, so it is normal that the payment data is empty and the amount due is 0 since the customer already paid on your website with a normal payment method like PayPal.
Similarly, it's normal the due date is not set since the order is supposed to be already paid.
If you wish to have the customer purchase your products through payment methods included in the UBL file, then it would require the development of a payment plugin, where you could provide the payment details, which would trigger the generation of the UBL file at the end of the checkout with the payment details from the payment method, etc. In that case, it would make sense for the amount due to be the total amount, etc in the generated UBL.

Regarding the product codes, please note that you need to fill in the setting "Tax category code field" of the plugin with the column name of a custom field of the table "product", and that in each product, you provide the tax category code in that custom field.

Regarding the company name and email missing for the supplier, please note that you have corresponding fields in the settings of the plugin that you need to fill in so that they can be present in the UBL file.

Please review the settings of the plugin. You can click on the "toggle inline help" button at the top to get to see the instructions for each field of the plugin. That might help you fill in the settings properly.

Hi,

Thanks for the details.
So based on all of this and what I can see on your website at the moment, everything is configured properly.
The problem comes from your template. It has CSS code which hides the PayPal buttons area.
In the file neu.sachsenland-fruchtquell.de/templates.../css/animate.min.css there is the CSS code:which forces PayPal's area to be transparent...

That's something you need to report to your template provider. It's a big problem, not only for HikaShop, but any ecommerce solution which integrates with PayPal Checkout. They need to fix this in their template because PayPal won't change the way they do things.

I can see that in neu.sachsenland-fruchtquell.de/media/tem...ia/css/nexus.min.css they have CSS code like this:So maybe they are aware of the problem and they tried to counter the CSS of the animate library with that CSS ?
However, the nexus.min.css is loaded before the animate.min.css file in the headers of the page so the animate library has priority.
They would have to change the order of loading these CSS files so that their nexus.min.css file is loaded after the animate.min.css file for their opacity:1 override to be taken into account.

Hi,

1. It probably has something to do with the settings under the Checkout tab of the HikaShop configuration. Could you provide screenshots of these settings ?
For example, if the "read only" setting of the "address" area is turned on.

2. No, no extra plugins are necessary for that. It is possible by default. You must have changed something in the settings of the Checkout tab which results in this behavior.

3. You're saying that you want that "once a user is created, they can simply proceed to checkout and pay". And for a user to be created, you need the registration area. But you also say that you want to "remove the entire login and registration phase". These two are conceptually mutually exclusive. So, I'm not clear on what you want and thus I can't provide a precise answer yet. Could you clarify what you want for this point please ?

4. Supposing you don't want a login form and a registration form, you can set the "Registration" setting to "guest" and turn off the "login" setting under the Checkout tab of the HikaShop configuration. That way, the checkout will only provide a guest form where the user can provide his email address and physical address. No more login, and no more registration. Maybe that's what you want to do ?

5. Yes and no. Some payment gateways allow for this. For example, Authorize.js allowed for the credit card form to be displayed directly when the payment method is selected: www.hikashop.com/marketplace/product/150...e-js-by-obsidev.html
However, I can see that your website is in Italian, and Authorize.js is only available for US merchants, so you won't be able to use it.
The PayPal Pro payment plugin available by default in HikaShop also allows for it but that service is not allowed by PayPal in Italy either.
The normal PayPal Checkout payment plugin you're using currently doesn't allow for this. It has to be after the customer clicks on the "finish" button.

6. Yes. Just turn off the "order creation notification" email via the System>Emails menu.

7. If you want to modify the emails sent by HikaShop, you can also do it via the System>Emails menu.
However, for the issues you're talking about, you don't need to modify the emails I think. For example, for the notes from the customer:
Normally, to allow customers to provide extra information for their order, you want to create a custom field of the table "order" and of the type "textarea" via the menu Display>Custom fields. Once you do so, the customers will be able to see that text field during the checkout and fill it. And in the settings of the custom field, you'll have display settings you can use to configure if you want to display the entered value in the email notifications, on the invoice, in the order details page, etc. So no code modification should be necessary.