Multi store admin orders

[LB-Team-igniti]

Hello,

we are currently investigating some issues which are related to orders in general, including admin orders. All the payment types of our client are PayOne only. Two stores are affected, whereas the first store was there from the beginning and second store is a new one which was taken into the same system this year.

assumption / question

Momentarilly we asume, that the PayOne Magento2 module is not handling admin orders in a multistore correctly. Please verify or decline this, please.

Details from our investigation

Especially the IP-Check makes problems while creating admin orders. It seems that at this point is not taken the second store PayOne configuration of the IP-check, in which we included Germany besides Austria, because the admins are located in Germany and must be able to create orders for austrian customers as well. It throws errors and makes order creation impossible, until we deactivate the first stores IP-Check. So then we concluded to the above question: Is the module really using the correct configuration and payment portal or is maybe a generic problem with admin orders in multistores?

[LB-Team-igniti]

Update. I reached a colleague of you at the phone today. He confirmed, that the admin orders are still sent to the wrong portal-ID (subaccount) of PayOne.

Please could you have a look, if admin orders use the correct, store-specific and not default, configuration? Your colleague told me he will create an internal ticket and link this issue here with it, as well.

Please keep us updated. Thank you.

[hreinberger]

Hi @LB-Team-igniti sorry for the long response time. I've now gotten around to reproducing this issue. I created an additional Store View, setup different PAYONE merchant credentials for this store and made a backend order for this new store using PAYONE Invoice --> This worked for me

I'm not sure I understand what kind of IP Check you mean though? Are you using our own IP check located in our PMi or something else?

[LB-Team-igniti]

Hi Hannes, @hreinberger,

thank you. If "PMi" means PayOne merchant center then yes else no.

In this case we gained, that the payment was assigned to the wrong merchant sub-account inside PayOne. We have verified this by:

1. We deactivated the IP-Check Security option inside PayOne merchant center in the first account - it was not possible to send an order for the second store (connected with second PayOne account) from Admin - because the IP-Check of the first account was not allowing the country, so it checked the wrong account.
2. We called PayOne support and asked to which account the money was assigned to, because we are not able to see the subaccount which reached the money in the PayOne merchant center - the answer verified our result from the first action: it was the general (first) account instead of the (expected) second new account / merchant in which the money had arrived.

We have some different issues with this second PayOne account in the same Magento. In the first place we are searching glues, why this happens. Afterwards I'd open different issues, if we can reproduce the issues as directly related to the Magento2 module.

Which brought us to the question and issue question: Are multi-store admin orders completely supported / tested? Including splitted invoices and shipments, partial creditmemo with one and the same transaction ID from Magento-PayOne-module to PayOne and vice versa?

Kind Regards, Pierre.

[janteuber]

Hello Pierre, This described behavior does not seem to have its cause in the plugin. I have forwarded this case to my colleagues in Tech Support. They will have a look at the internal settings.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LB-Team-igniti]

@janteuber @hreinberger We finally got more details how to reproduce the issue. It's related to the fact that the portal ID (and merchant ID, sub-account ID etc) can be configured in two different places:

• Payone > General > Global
• Payone > Payment > Invoice (and the other payment methods, I use invoice payment here as an example)

Now please adjust your settings like this (note: I used Magento 2.4.2 and Payone extension 3.2.0):

• create 2 different websites (which I named "A" and "B" here), maybe 2 different store-views is enough as well but I did not test this yet
• use "X" and "Y" for the different portal-IDs, please use some working numbers here for testing
• set the following store configuration:
  • Payone > General > Global [scope: default values]: portal-ID = X
  • Payone > General > Global [scope: website B]: portal-ID = Y
  • Payone > Payment > Invoice [scope: default values]: “Use Global Settings” = Yes
  • Payone > Payment > Invoice [scope: website B]: use default values for portal-ID and “Use Global Settings”
• create a new admin order in website B
• check database table payone_protocol_api, column portalid

Expected:

• the used portal-ID is "Y" (because this is the value that has been configured in the global settings for this website)

Actual:

• the used portal-ID is "X"

In order to use the desired portal-ID for website B I have to set it in the store config Payone > Payment > Invoice on the website level and set "Use Global Settings" = No. Then it's using the correct portal-ID "Y"

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LB-Team-igniti]

@janteuber @hreinberger Could you reproduce the issue with the Payone extension for Magento2 ?

[janteuber]

Hello @LB-Team-igniti , Thank you for the detailed description. I have passed the issue to our technicians. As soon as I have new information, I will post it here.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LB-Team-igniti]

It looks like this issue has been fixed in the version 3.6.0 :+1: thanks! We'll give it a try ourselves as soon as possible.