fields in template do not contain any type in error handling like shopware provides for all their fields. this should be implemented by default.

see summary

Documentation for Shopware: http://www.payone.de/uploads/media/PAYONE_Dokumentation_Shopware-Payment-Plugin_01.pdf

404

BR
emtii

Hello,

i noticed some flaw in the Payone AmazonPay order handling which is done in Controllers/MoptPaymentAmazon::finishAction().

At the beginning of the function the order number is reserved for transmission to Amazon:

        // pre-reserve Shop Order Number
        if (empty($this->session['moptAmazonOrdernum'])){
            $my_sOrder = new sOrder();
            $this->session['moptAmazonOrdernum'] = $my_sOrder->sGetOrderNumber();
        }

Later on when the process was successful, the order is saved and therefor a new order number created:

            $orderNumber = $this->saveOrder(
                $txid,
                $this->session->paymentReference
            );

Afterwards the newly created order number is overwritten by the one already sent to Amazon:

            // replace the new order number with the already reserved one, which is already sent to amazon
            $sql = 'UPDATE  `s_order` SET ordernumber = ? WHERE transactionID = ?';
            Shopware()->Db()->query($sql, array($this->session['moptAmazonOrdernum'], $txid));

This happens, as seen, only for the s_order table but not for the s_order_details table. Meaning that in the s_order table the order number sent to Amazon is used but in the s_order_details table it is still the one set by saveOrder. Creating two different order numbers for the same orderID.

Is that behaviour intentional? And if yes, whats the reasoning behind?

Best regards
Marco Fritsche

Uninstalling the plugin does not remove all created entries from s_core_menu so it causes duplicate entries issues when trying to reinstall the plugin one more time.

In the following code sequence

Hi,
currently we face the issue that in a setup with loadbalancer the plugin always submit the ip of the loadbalancer to payone instead of the customer ip.

Could you please have a look into that one? Thank you.

[17-Aug-2016 12:33:36 Europe/Berlin] PHP Fatal error:  require_once(): Failed opening required '/var/www/XXXXXXXX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/CSRFWhitelistAware.php' (include_path='/var/www/XXXXXXXXXXXX/htdocs/engine/Library:.:/usr/share/php5:/usr/share/php') in /var/www/XXXXXXXXXXXXXX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Bootstrap.php on line 32

If the UST ID Validation runs to timeout because f.e. the VATID portal is not reachable, at Shopware/Plugins/Community/Core/SwagVatIdValidation/Subscriber/CheckoutFinish.php at Line 71
you get NULL and the function fails.

$orderDetails = Shopware()->Session()->get('sOrderVariables')->getArrayCopy();

So the jump back to the shopware shop fails and independent if the payment was successful or not, the order is lost at the shop. Best case is payment failed too otherwise the customer paid and nobody will recognize that a new order ist there.

Installed plugin version is 3.6.0, Shopware Version 5.2.27.

I have registered a new account in shopware (completely new, no checkout, no order), then i clicked on my account and payment types, the following error occurs:
Fatal error: Uncaught Error: Unsupported operand types in .../engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Subscribers/FrontendAccount.php:70
Stack trace:
#0 .../engine/Library/Enlight/Event/Handler/Default.php(91): Shopware\Plugins\MoptPaymentPayone\Subscribers\FrontendAccount->onPaymentAction(Object(Enlight_Hook_HookArgs))
#1 .../engine/Library/Enlight/Event/EventManager.php(296): Enlight_Event_Handler_Default->execute(Object(Enlight_Hook_HookArgs))
#2 .../engine/Library/Enlight/Hook/HookManager.php(191): Enlight_Event_EventManager->filter('Shopware_Contro...', NULL, Object(Enlight_Hook_HookArgs))
#3 .../var/cache/production_201707131430/proxies/ShopwareControllersFrontendAccountProxy.php(17): Enlight_Hook_HookManager->executeHooks(Object(Shopware_Proxies_ShopwareControllersFrontendAccountProxy), 'paymentAction', Object(Enlight_Hook_HookArgs))
#4 .../engine/Library/Enlight/Controller/Action.php(159 in .../engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Subscribers/FrontendAccount.php on line 70

I think the line "$subject->View()->sUserData += $paymentData;" has to be within the not empty if.

on our 5.1.3 if you order as a guest and don`t fill your birthday in "registration" but on payment page you get an error on ajaxHandlePayolutionPreCheckAction() in MoptAjaxPayone.php

for me it was this line (near line 394):
$config = $this->moptPayoneMain->getPayoneConfig($this->getPaymentId());

"$this->getPaymentId()" is empty... seems that the whole session ist empty at this point! For me I changed the function getPaymentId() to:

protected function getPaymentId()
{
 if($this->session->sOrderVariables['sUserData']['additional']['payment']['id'] != '') 
          return $this->session->sOrderVariables['sUserData']['additional']['payment']['id'];
 else {
     $userData = $this->admin->sGetUserData();
      return $userData['additional']['payment']['id'];
    }       
 }

and in "buildAndCallPrecheck()" i need to change this (near line 520):

if ($personalData->getBirthday() !== "00000000" && $personalData->getBirthday() !== "") { $request->setBirthday($personalData->getBirthday()); } else { $request->setBirthday($paymentData['dob']); } if ($paymentData && $paymentData['mopt_payone__payolution_b2bmode']) { $request->setBirthday(""); }

into this

if ($personalData->getBirthday() !== "00000000" && $personalData->getBirthday() !== "") { if($personalData->getBirthday() == '') $request->setBirthday($paymentData['dob']); else $request->setBirthday($personalData->getBirthday()); } else { $request->setBirthday($paymentData['dob']); } if ($paymentData && $paymentData['mopt_payone__payolution_b2bmode']) { $request->setBirthday(""); }

i am not 100% sure about my changes can anyone confirm?

[Tue Jun 28 15:57:38.284902 2016] [:error] [pid 6433] [client 10.6.219.2:44823] PHP Fatal error: Uncaught TypeError: Argument 1 passed to Payone_Protocol_Logger_Log4php::setConfig() must be of the type array, null given, called in /var/www/XX.XX.XX.XXX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Payone/Builder.php on line 355 and defined in /var/www/XX.XX.XX.XXX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Payone/Protocol/Logger/Log4php.php:186\nStack trace:\n#0 /var/www/XX.XX.XX.XXX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Payone/Builder.php(355): Payone_Protocol_Logger_Log4php->setConfig(NULL)\n#1 /var/www/XX.XX.XX.XXX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Payone/Builder.php(288): Payone_Builder->buildServiceProtocol(Array, 'api')\n#2 /var/www/XX.XX.XX.XXX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Payone/Builder.php(161): Payone_Builder->bui in /var/www/XX.XX.XX.XXX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Payone/Protocol/Logger/Log4php.php on line 186, referer: http://XX.XXX.XXX.XXX.de/checkout/cart

Liebe Kollegen,

insgesamt 4 Entwickler haben einen Tag lang vergeblich versucht, Verwendungszweck / Usage die Variable {$sBookingID} für die Zahlungsart PayOne Prepayment einzubinden. Es gelang uns zwar zuerst im Finishing (Ansicht im Checkout, nachdem Zahlung abgeschlossen wurde), aber beim Versuch, die BookingID auch im Druckansicht-PDF (aus dem Finishing erzeugt) und in der von Shopware automatisch generierten Rechnung einzubinden, sind wir gescheitert.

Eine letzte Rückmeldung unserer Entwickler ist: Finish page is using the third snippet from your screenshot.png (FinishPayinadvanceData, as I already wrote before), so it uses {$sBookingID} variable.
PDF generated in admin (EN invoice pdf.png) uses the first snippet from screenshot.png, so it's once again with {$sBookingID} that once again returns nothing.
I guess it's better to ask the other developer why this variable doesn't show anything.

Gibt es hierzu eine Lösung, bzw. könnte es so dokumentiert werden, dass erfahrene Shopware-Entwickler in der Lage sind, dies zu implementieren?

Hello,

I'm writing a plugin that imports retours from a logistics service as CLI command.
When a retour comes in the plugin has to refund the returned positions.
So I thought I'll have a look into the workflow that is used in the backend (see \Shopware_Controllers_Backend_MoptPayoneOrder::moptPayoneDebitAction()).

Because you use $this->Request() here, which is understandable, I copied your controller and had to refactor the init() method in this controller to inject the services.
This makes hell a lot problems because the needed classes aren't available in the DIC.

So my question is: Do you have any services in your plugin that let me refund orders?

Hi,
it would be nice, if we can get two public available function (over your plugin Bootstrap.php) to refund or capture values.

class Shopware_Plugins_Frontend_MoptPaymentPayone_Bootstrap extends Shopware_Components_Plugin_Bootstrap
{
    // some other code ...

    /**
     * do a capture for order position with specified $orderDetailId (s_order_details.id) with $amount
     * @param int $orderDetailId
     * @param float $amount
     * @return bool success?
     */
    public function doCapture($orderDetailId, $amount)
    {
        // do caputre
    }

    /**
     * do a refund for order position with specified $orderDetailId (s_order_details.id) with $amount
     * @param int $orderDetailId
     * @param float $amount
     * @return bool success?
     */
    public function doRefund($orderDetailId, $amount)
    {
        // do refund
    }

    // some other code ...
}

Trying to open Customers > Payment Payone > Konfiguration

404

Ext.define('Shopware.apps.Index', {
extend:'Enlight.app.SubApplication',
bulkLoad: true,
loadPath: '/backend/Index/load',
controllers:[
'Main',
'Widgets',
'ErrorReporter',
'ThemeCacheWarmUp'
],
requires: [
'Shopware.container.Viewport'
],
views: [
'Main',
'Menu',
'Footer',
'Search',
'widgets.Window',
'widgets.Sales',
'widgets.Upload',
'widgets.Visitors',
'widgets.Orders',
'widgets.Notice',
'widgets.Merchant',
'widgets.News',
'widgets.Base',
'merchant.Window',
'themeCache.ThemeCacheWarmUp'
],
models: [
'Widget',
'WidgetSettings',
'Turnover',
'Batch',
'Customers',
'Visitors',
'Orders',
'News',
'Merchant',
'MerchantMail',
'ThemeCacheWarmUp'
],
stores: [
'Widget',
'WidgetSettings',
'ThemeCacheWarmUp'
]
});
Ext.define('Shopware.apps.Index.bestitTbOneWidget.model.State', {
extend: 'Ext.data.Model',
fields: [
'name',
'state'
]
});//
Ext.define('Shopware.apps.Index.bestitTbOneWidget.store.State', {
extend: 'Ext.data.Store',
model: 'Shopware.apps.Index.bestitTbOneWidget.model.State',
remoteSort: true,
pageSize: 25,
autoLoad: true,
proxy: {
type: 'ajax',
url: '/backend/BestitTbOneWidget/getStates',
reader: {
type: 'json',
root: 'data',
totalProperty: 'total'
}
}
});
Ext.define('Shopware.apps.Index.bestitTbOneWidget.view.Main', {
extend: 'Shopware.apps.Index.view.widgets.Base',
alias: 'widget.bestit-tb-one',
resizable: {
handles: 's'
},
minHeight: 350,
maxHeight: 600,
initComponent: function() {
var me = this;
me.stateStore = Ext.create('Shopware.apps.Index.bestitTbOneWidget.store.State').load();
me.tools = [
{
itemId: 'refresh',
type: 'refresh',
scope: me,
handler: me.refreshView
}
];
me.items = [
me.createStateGrid()
];
me.callParent(arguments);
},
createStateGrid: function() {
var me = this;
return Ext.create('Ext.grid.Panel', {
border: 0,
store: me.stateStore,
columns: me.createColumns()
});
},
createColumns: function() {
return [{
dataIndex: 'name',
header: 'Bezeichnung',
xtype: 'gridcolumn',
flex: 1
}, {
dataIndex: 'state',
header: 'Status',
xtype: 'gridcolumn'
}
]
},
refreshView: function() {
var me = this;
if(!me.stateStore) {
return;
}
me.stateStore.reload();
},
openTradeByte: function() {
openNewModule('Shopware.apps.BestitTbOne', {
action: 'list',
params: { }
});
}
});//
Ext.define('Shopware.apps.Index.bestitBvbCoreWidget.model.State', {
extend: 'Ext.data.Model',
fields: [
'name',
'state',
'module'
]
});//
Ext.define('Shopware.apps.Index.bestitBvbCoreWidget.store.State', {
extend: 'Ext.data.Store',
model: 'Shopware.apps.Index.bestitBvbCoreWidget.model.State',
remoteSort: true,
pageSize: 25,
autoLoad: true,
proxy: {
type: 'ajax',
url: '/backend/BestitBvbCoreWidget/getStates',
reader: {
type: 'json',
root: 'data',
totalProperty: 'total'
}
}
});
Ext.define('Shopware.apps.Index.bestitBvbCoreWidget.view.Main', {
extend: 'Shopware.apps.Index.view.widgets.Base',
alias: 'widget.bestit-bvbcore',
resizable: {
handles: 's'
},
minHeight: 125,
maxHeight: 300,
initComponent: function() {
var me = this;
me.stateStore = Ext.create('Shopware.apps.Index.bestitBvbCoreWidget.store.State').load();
me.tools = [{
type: 'refresh',
scope: me,
handler: me.refreshView
}];
me.items = [
me.createStateGrid()
];
me.callParent(arguments);
},
createStateGrid: function() {
var me = this;
return Ext.create('Ext.grid.Panel', {
border: 0,
store: me.stateStore,
columns: me.createColumns(),
});
},
createColumns: function() {
return [{
dataIndex: 'name',
header: 'Modul',
xtype: 'gridcolumn',
flex: 1
}, {
dataIndex: 'state',
header: 'Status',
xtype: 'gridcolumn',
flex: 1
}, {
xtype: 'actioncolumn',
width: 50,
items: [{
iconCls:'sprite-ui-scroll-pane-list',
tooltip: 'Log öffnen',
handler: function(view, rowIndex, colIndex, item, event, record) {
openNewModule('Shopware.apps.BestitBvbCore', {
params: {
filter: record.get('module')
}
});
}
}]}
]
},
refreshView: function() {
var me = this;
if(!me.stateStore) {
return;
}
me.stateStore.reload();
}
});//

/backend/MoptConfigPayone/load/?f=m/Config|m/Signal|m/Payment|v/main/Window|v/main/Detail|store/Con…:263 Uncaught TypeError: Cannot read property 'data' of undefinedme.submit.failure @ /backend/MoptConfigPayone/load/?f=m/Config|m/Signal|m/Payment|v/main/Window|v/main/Detail|store/Con…:263Ext.apply.callback @ ext-all.js?201604081130:21Ext.define.afterAction @ ext-all.js?201604081130:21Ext.define.run @ ext-all.js?201604081130:21(anonymous function) @ ext-all.js?201604081130:21

me.submit.failure @ /backend/MoptConfigPayone/load/?f=m/Config|m/Signal|m/Payment|v/main/Window|v/main/Detail|store/Con…:263
Ext.apply.callback @ ext-all.js?201604081130:21
Ext.define.afterAction @ ext-all.js?201604081130:21
Ext.define.run @ ext-all.js?201604081130:21
(anonymous function) @ ext-all.js?201604081130:21

Hey,

we currently have a problem, if a customer returns less items of an order position than he has ordered. Example: The customer orders 3 shirts and returns 2.
Because the returned quantity is not considered in Bootstrap::refundOrder, the request contains the wrong quantity and we get an 1610 error (Article list faulty or incomplete|customermessage=An error occured while processing this transaction (wrong parameters)).

see: https://github.com/PAYONE-GmbH/shopware-5/blob/master/Frontend/MoptPaymentPayone/Bootstrap.php#L835

The function only process the "id" and "amount" of the given $orderDetailsParams

$orderParams = array_combine(array_column($orderDetailParams, 'id'), array_column($orderDetailParams, 'amount'));

We should be able to pass the quantity and it should be further processed.

The next function where this needs to be considered is the Mopt_PayoneParamBuilder::getInvoicingFromOrder. (https://github.com/PAYONE-GmbH/shopware-5/blob/master/Frontend/MoptPaymentPayone/Components/Classes/PayoneParamBuilder.php#L1283)
There the quantity is fetched from the order - this needs to be changed to consider the passed quantity.

Hi,
we currently have a project which needs us to capture pre-authorized order amounts automatically once the shop owner sends a shipping confirmation of the order to the shop.

The external API functions requested in #32 seemed to be exactly what we needed.
However, we found three drag-downs in the current implementation:

The described "quantity" is not working for the $orderDetailParams parameter. Passing the amount is mandatory at the moment.

Each exception thrown in the captureOrder() method is getting echoed. Is this intended? We would need output buffering to get those exception texts.

The parameter $includeShipment does not seem to have any effect. The variable is not being used in the buildCustomOrderCapture() method of the Parambuilder.

Could you please introduce tags into this repo and mark them as stable for customers? Actually I just use master and "hope" but do not really know which version this is and which bugs it fixed.

Really would love to see versions / tags in this industry product. thx!

Shopware 5.2.26 und PHP 7.0.14

paymentData ist bei uns false

Hi there,

I noticed the default styles that come with new installations don't really work even with the standard template. I had a look at the defaults and found that the iframe heights don't really match the height of the fields in them with the standard CSS.

Could you alter the defaults so that the standard height of the iframes is 40px? This alone would go a long way to a useable standard. While you're at it, making the width of the expiremonth 80px and expireyear 90px would also look great. And I think the width of the cardpan field should be 100% rather than 100px to match the width of the name above. Finally, adding a "border-radius:3px;" to the standard CSS would perfectly match the default styles of the surrounding fields.

I found the line in which the standards are written to the db but I'm not familiar with pull requests or anything so all I can do is open this issue. Thanks in advance!

Currently there is a load of barzahlen.css everytime we are on the payment page. Which is not needed, as we do not use barzahlen in general. The method is deactivated. Make sure you do not load resources which are not needed, please.

Additionally.... this file only has one selector

div.barzahlencode img {
display: initial;
}

Hi,

the button "duplicate payment method" is right from "save", should be left from "save" button because this is where you expect to click "forward" or "save" an action.

I always duplicate the payment methods when doing some changes to a method.

just found this one:

[Tue Oct 04 18:01:37.121008 2016] [:error] [pid 4936] [client 10.6.219.2:48338] PHP Fatal error: Uncaught Error: Call to a member function getArrayCopy() on null in /var/www/xxxxxxxxxx/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Controllers/Frontend/MoptShopNotification.php:77\nStack trace:\n#0 /var/www/xxx.xxx.xxx/htdocs/engine/Library/Enlight/Controller/Action.php(159): Shopware_Controllers_Frontend_MoptShopNotification->indexAction()\n#1 /var/www/xxx.xxx.xxx/htdocs/engine/Library/Enlight/Controller/Dispatcher/Default.php(523): Enlight_Controller_Action->dispatch('indexAction')\n#2 /var/www/xxx.xxx.xxx/htdocs/engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))\n#3 /var/www/xxx.xxx.xxx/htdocs/engine/Shopware/Kernel.php(176): Enlight_Controller_Front->dispatch()\n#4 /var/www/xxx.xxx.xxx/htdocs/vendor/symfony/http-kernel/HttpCache/HttpCach in /var/www/xxx.xxx.xxx/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Controllers/Frontend/MoptShopNotification.php on line 77

installed the plugin, tried to activate it, caused:

Fatal error: Uncaught TypeError: Argument 1 passed to Shopware\Plugins\MoptPaymentPayone\Subscribers\AddressCheck::__construct() must be an instance of Shopware\Plugins\MoptPaymentPayone\Subscribers\Container, instance of ShopwareProductionProjectContainer given, called in /var/www/XX.XX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Bootstrap.php on line 336 and defined in /var/www/XX.XX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Subscribers/AddressCheck.php:23 Stack trace: #0 /var/www/XX.XX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Bootstrap.php(336): Shopware\Plugins\MoptPaymentPayone\Subscribers\AddressCheck->__construct(Object(ShopwareProductionProjectContainer)) #1 /var/www/XX.XX.XX/htdocs/engine/Library/Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Frontend_MoptPaymentPayone_Bootstrap->onDispatchLoopStartup(Object(Enlight_Controller_EventArgs)) #2 /var/www/XX.XX.XX/htdocs/engine/Library/Enlight/Event/ in /var/www/XX.XX.XX/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Subscribers/AddressCheck.php on line 23
503 Service Unavailable

We encounter a serious problem with duplicates in the s_order table that are created by the plugin.

This occurs under certain circumstances:

• The shop is under high load
• Many sessions are being created in a very short amount of time

The MoptShopNotification::indexAction is called asynchronously by the PayOne servers after a user has completed a payment process. (we see 2-3min delays in our logs).
If the shop is under high load, the probability that the garbage collector has removed the user session increases. If this has happend - the MoptShopNotification service will create duplicate entries in the s_order database table.

This is due to the fact, that in the following code segment, the order is saved using the core Shopware method Payment::saveOrder, which in turn uses the session.

        if (!$isOrderFinished) {
            $orderHash = md5(serialize($session['sOrderVariables']));
            $customParam = explode('|', $request->getParam('param'));

            if ($orderHash !== $customParam[2]) {
                $this->logger->error("Order for {$transactionId} corrupted - order hash mismatch", ['transactionId' => $transactionId]);
                $orderIsCorrupted = true;
                $paymentStatus = 21;
                $orderNumber = $this->saveOrder($transactionId, $request->getParam('reference'), $paymentStatus);
            } else {
                $this->logger->debug("Save order for {$transactionId} - order hash validation succeeded.", ['transactionId' => $transactionId]);
                $orderNumber = $this->saveOrder($transactionId, $request->getParam('reference'));
            }

            $order = $this->loadOrderByOrderNumber($orderNumber);
        }

Payment:.saveOrder

        $sql = '
            SELECT ordernumber FROM s_order
            WHERE transactionID=? AND temporaryID=?
            AND status!=-1 AND userID=?
        ';
        $orderNumber = Shopware()->Db()->fetchOne($sql, [
                $transactionId,
                $paymentUniqueId,
                Shopware()->Session()->sUserId,
            ]);

This is a serious issue, because the duplicate orders lead to many failed requests during the further processing of orders (capturing, refunding..)
Furthermore the above code to check the integrity of the order by using an order hash will always fail, if the user session could not be properly restored.

Our proposal would be

• to eliminate the usage of the Shopware function to save the order and instead use a custom implementation to update the required fields.
• Properly handle the case, if a user session could not be restored

We gladly help with more input if needed.

Greetings
Thomas

Hey,
we found a issue with the account payment switcher while the payone plugin is active. I guess the problem is the usage of += which throws a fatal error on php7.

PHP: 7.0.24
Plugin Version: 3.6.0

Hi,

please consider replacing calls toShopware()->Modules()->Basket()->sGetBasket() with Shopware()->Modules()->Basket()->sGetBasketData() where possible.

As a call to sGetBasket() will always trigger a recalculation of the whole basket and executes all attached subscribers again. This is not a big problem at all for small baskets with 5 to 10 items but has an large impact for baskets with more than 20 items.

Hi,

while using the external API function captureOrder of the Plugin-Bootstrap we came across a few bugs / exceptions / deprecated calls:

• "Missing argument 2 for Doctrine\ORM\QueryBuilder::from()" in .../Frontend/MoptPaymentPayone/Models/MoptPayoneConfig/Repository.php on line 22
• "Undefined variable: invoicing" in .../Frontend/MoptPaymentPayone/Bootstrap.php on line 1055
• "Undefined index: payolution_b2b" in .../Frontend/MoptPaymentPayone/Bootstrap.php on line 1153
• "Shopware()->__call(MoptPayoneBuilder) is deprecated since version 4.2 and will be removed in 5.3. Use the Container instead" in .../Frontend/MoptPaymentPayone/Bootstrap.php on line 1143

The following exception is thrown if you ignore the deprecated warning above. However, it is only thrown when used in a Shopware Console-Command:

• "Method "Shopware::MoptPayoneBuilder" not found failure" in .../Frontend/MoptPaymentPayone/Bootstrap.php on line 1143

Additionally, it seems like the taxes of the shippings costs are not calculated correctly if you compare the two methods getParamCaptureAmount and getParamCustomAmount of the Mopt_PayoneParamBuilder class.

We have noticed a change in Paypal Express behaviour in the recent version 3.7.0.

Before this release a check was made if the user is logged in and if not a new user was created. Code example Controllers/Frontend/MoptPaymentEcs.php createrOrUpdateAndForwardUser() function:

        if (!$this->isUserLoggedIn($session)) {
            $this->createUserWithoutAccount($payData, $session, $paymentId);
        } else {
            $user = $this->updateUserAddresses($payData, $session, $paymentId);
            if ($user === null) {
                return $this->ecsAbortAction();
            }
        }

This changed with 3.7.0. Now always a new user is created which also results in a new session and the user is not logged in anymore after using Paypal Express as payment mean. Code example Controllers/Frontend/MoptPaymentEcs.php createrOrUpdateAndForwardUser() function:

        if ($this->isUserLoggedIn($session)) {
            $user = $this->updateUserAddresses($payData, $session, $paymentId);
            if ($user === null) {
                return $this->ecsAbortAction();
            }
        }
        $this->createUserWithoutAccount($payData, $session, $paymentId);

Was this change made intentionally and if yes, could you explain the reasoning behind it please?

Thanks in advanced.

Best regards
Marco Fritsche

Hallo PAYONE Support,
ich habe noch einen Fehler in der Version 3.4.0_5908 auf Shopware 5.2.9 entdeckt. Es geht um wiederkehrende Zahlungen über das Backend, wie sie z.B. von AboCommerce genutzt werden.

Der Fehler stellt sich wie folgt dar:

Einer unserer Kunden benutzt das Plugin AboCommerce um monatlich Abonnement-Bestellungen im Backend zu erzeugen. Dabei wird die recurringAction des PAYONE-Plugins angesprochen. Beim Erstellen des Request an PAYONE werden die Request-Parameter durch die Klasse Mopt_PayoneParamBuilder erzeugt. Innerhalb dieser Klasse gibt es die Funktion getBasketItems, die die Warenkorbparameter für den Request an PAYONE zusammenstellen (pr, no, de, va, etc.). Bei der Berechnung des Parameters pr wird auf das Array-Element $article['netprice'] zugegriffen. Dieses Element existiert allerdings nur im Frontend, da es aus der Session bezogen wird. Somit wird der Preis für alle Positionen immer mit 0 berechnet. Dadurch dass die Summe der Positionen dann nicht mehr mit dem an PAYONE übermittelten Gesamtbetrag (amount) übereinstimmt, schlägt der Request an PAYONE immer fehl.

Danke,
Jens Peters

Added a max basket value of 1000 € to several payment methods in the backend then added 100 products with summarized value of 3000 € to the basket. I am still able to choose the payment method in the bottom left corner in shopwares pre shipping costs calculator.

In around 40k orders in my application the attribute is never been set, would be useful to have this information in some occurences. Thank you very much.

installed the plugin and used sw:plugin:update from sw console --shell, got:

PHP Warning: Declaration of Shopware\CustomModels\MoptPayoneConfig\MoptPayoneConfig::fromArray($array = Array) should be compatible with Shopware\Components\Model\ModelEntity::fromArray(array $array = Array) in /var/www/admin.dev.b2c/htdocs/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Models/MoptPayoneConfig/MoptPayoneConfig.php on line 1274

Plugin MoptPaymentPayone has been updated successfully.

When rebuilding the order attribute model for Shopware 5.3 we should rename the mopt_payone_payolution_clearing_reference attribute to reflect its actual use. The attribute is used for all kinds of clearing references, not only Payolution.

Same goes for mopt_payone_payolution_workorder_id, as other payment methods might need workorderid reference in the future.

Added a value of 1000 € to max basket value for several payment methods in the backend config Payments > Payone > Konfiguration

Added 100 items to the basket with summarized value of 3000 €.

I am still able to choose all payment methods.

We are experiencing problems when customers get should get a refund. In the API-Logs we get an errorcode 1610 (Article list faulty or incomplete)

In Bootstrap::refundOrder on line 870 the method PayoneParamBuilder::getInvoicingFromOrder is called with the 4th parameter ($debit) set to "false". This seems to be a bug, because we are in the "refundOrder" method.

if ($config['submitBasket'] || Mopt_PayoneMain::getInstance()->getPaymentHelper()->isPayoneBillsafe($paymentName)) {
    $invoicing = Mopt_PayoneMain::getInstance()->getParamBuilder()
        ->getInvoicingFromOrder($order, array_column($orderDetailParams, 'id'), $finalize, false, $includeShipment);
}

The result of this parameter is, that the returned list of articles that will be send to the API ist wrong - hence the "Article list faulty" error message.

See PayoneParamBuilder Line 1265 -> here the articles that have a captured amount set in the DB will be skipped because $debit is set to "false". This leads to the wrong article list for the refund.

if (!$debit) {
    $positionAttribute = $this->payoneHelper->getOrCreateAttribute($position);
    if ($positionAttribute->getMoptPayoneCaptured()) {
        continue;
    }
}

Hallo PAYONE Support,
das PAYONE Payment Plugin für Shopware erzeugt in der Version 3.4.0_5908 auf Shopware 5.2.9 einen Fehler.

Der Fehler stellt sich wie folgt dar:

Bei einem unserer Kunden können B2B-Kunden im Shop in netto bestellen (s_order.net = 1). Wenn ein Benutzer nun im Backend den Bestellstatus dieser Bestellung ändert, werden die Preise der Positionen neu berechnet. Bei jeder Statusänderung steigt der Preis. Dies betrifft auch Bestellungen, die gar nicht mit einer PAYONE-Zahlungsart getätigt wurden (z.B. Vorkasse).

Sobald man das PAYONE Payment Plugin deaktiviert, lassen sich Statusupdates ohne falsche Preisberechnungen durchführen.

Wir benötigen hier dringend einen Bugfix, da in den betroffenen Shops unserer Kunden keine Bearbeitung der Bestellungen mehr möglich ist.

Danke,
Jens Peters

uninstall plugin and try to reinstall, this causes

Unable to install, got exception: An exception occurred while executing 'INSERT INTO s_core_menu (name, onclick, style, class, position, active, pluginID, controller, action, shortcut, parent) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params ["PAYONE Kontrollzentrum", "Shopware.ModuleManager.createSimplifiedModule("FcPayone", { "title": "PAYONE Kontrollzentrum" })", null, "payoneicon", 0, 1, 67, null, null, null, 65]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'PAYONE Kontrollzentrum-65' for key 'name'

When push a transaction status to an instance running on PHP7 we receive the "error processing request" response from the MoptShopNotification controller at https://github.com/PAYONE-GmbH/shopware-5/blob/master/Frontend/MoptPaymentPayone/Controllers/Frontend/MoptShopNotification.php#L81

Somehow the array mapping in the Transaction Service doesn't work, but I can't quite put my finger on it.

This file should get implemented:

/engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Views/frontend/_resources/javascript/mopt_checkout.js

by shopwares own compiler collector.

example

<php
// Subscribe the needed event for js merge and compression
$this->subscribeEvent(
    'Theme_Compiler_Collect_Plugin_Javascript',
    'addJsFiles'
)

public function addJsFiles(Enlight_Event_EventArgs $args)
 {
  $jsFiles = [
            $this->Path() . 'Views/frontend/_public/src/js/mopt_checkout.js'
        ];

        return new Doctrine\Common\Collections\ArrayCollection($jsFiles);
 }

We have the following undefined variables in the code:

• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Controllers/Backend/FcPayone.php ll. 128-129 $data, $params
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Components/Classes/PayoneHelper.php l. 174 $userId
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Components/Classes/PayoneParamBuilder.php ll.178, 180 $alreadCapturedAmount
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Subscribers/AddressCheck.php ll. 219-221 $session
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Controllers/Frontend/MoptPaymentPayone.php l. 261 $moptPaypalEcsWorkerId
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Subscribers/AddressCheck.php ll. 299-301 $session
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Components/Classes/PayoneParamBuilder.php l. 407 $payment
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Controllers/Backend/FcPayone.php ll. 626, 647, 669, 690 $myForm; l. 776 $params, l. 777 $data, l. 1000 $breadcrump
• shopware/engine/Shopware/Plugins/Default/Frontend/MoptPaymentPayone/Subscribers/AddressCheck.php l. 633 $userId

They need to either be defined or removed from the code.

Ich mach mal in deutsch :-)

In der Datei MoptPaymentPayone (Frontend Controller) ist die Funktion payolutionErrorAction (ca. Zeile 985) anders aufgebaut als die Funktion danach ratepayErrorAction was dazu führt, dass bei Fehlermeldungen durch den Zahlungsanbieter Payolution immer nur die gleiche nichts aussagende Fehlermeldung "Es ist ein Fehler aufgetreten" ausspuckt wird. Ich habe die wie folgt geändert:

$session = Shopware()->Session(); $errorCode = $session->payolutionErrorCode; $errorMessage = $session->payolutionErrorMsg; $this->View()->errormessage = Shopware()->Snippets()->getNamespace('frontend/MoptPaymentPayone/errorMessages')->get('errorMessage'.$errorCode, $errorMessage.' (Fehler '.$session->payolutionErrorCode.')', true);
und dementsprechend in Zeile 694

$this->forward('payolutionError')

ersetzt durch

'$session->payolutionErrorCode = $response->getErrorcode();
$session->payolutionErrorMsg = $response->getCustomermessage();
$this->forward('payolutionError');'

solltet ihr mal offiziell machen :-)

vor dieser Änderung wurden die Payolutionfehler auch nicht in den Api-Logs geloggt, das scheint nun aber zu gehen!?

There are two snippet folders in the same directory path:

Frontend/MoptPaymentPayone/Snippets
Frontend/MoptPaymentPayone/snippets

That causes filename conflicts on case-insensitive filesystems (e.g. on Windows and macOS). I am suggesting to merge the two directories to avoid these conflicts.

Cf. https://github.com/shopware/shopware/blob/5.3/UPGRADE-5.3.md

Many of the Errormessages aren't displayed in the Storefront.
Instead of just printing the customermessage from the response, the message is loaded from the snippets via the moptGetErrorMessageFromErrorCodeViaSnippet function, which mainly returns an empty string.

Here in the mopt_payone__handleDirectFeedback function, the ratepayError gets the status directly from the response, but almost all other load it from the snippet.

  protected function mopt_payone__handleDirectFeedback($response)
    {
        $session = Shopware()->Session();
        $paymentId = $this->getPaymentShortName();
        if ($response->getStatus() == 'ERROR' && $paymentId === 'mopt_payone__fin_ratepay_invoice') {
            $session->ratepayError = $response->getCustomermessage();
            $this->forward('ratepayError');
        } elseif ($response->getStatus() == 'ERROR') {
            $session->payoneErrorMessage = $this->moptPayoneMain->getPaymentHelper()
                    ->moptGetErrorMessageFromErrorCodeViaSnippet(false, $response->getErrorcode());
            $this->forward('error');
        } else {

I would recommend to either always load the customermessage or use the customermessage as a fallback.

Bei Lastschriftzahlung gibt es folgenden Bug:

• Wenn ich Land, Kontoinhaber, Konto-Nr. und BLZ ausgefüllt habe kann ich nicht bestellen. D.h. ich MUSS einen IBAN angeben.

Gewünschte Lösung:

• Wenn Land, Kontoinhaber, Konto-Nr. und BLZ ausgefüllt sind, ist der Iban kein Pflichtfeld mehr!
• Wenn Land, Kontoinhaber und Iban gefüllt sind, sind die Felder Konto Nr und BLZ keine Pflichtfelder mehr.

summary says

Since last store update payone is using a newer basket function which does not exist in Shopware 5.1.
That currently brokes the cart.

Message:
Fatal error: Call to undefined method Shopware_Proxies_sBasketProxy::sGetBasketData() in engine/Shopware/Plugins/Community/Frontend/MoptPaymentPayone/Components/Classes/PayoneMain.php on line 186503