buckaroo-it / shopware6

Repository containing the Shopware 6 Payment Plugin by Buckaroo

Buckaroo Shopware 6 Payments Plugin

Index

• About
• Requirements
• Installation
• Upgrade
• Configuration
• Contribute
• Versioning
• Additional information

---

About

Shopware is a modular online shop system developed in Germany since 2004. It is available both as open source software and in commercial editions.

The Buckaroo Payments Plugin (Dutch or English) for Shopware 6 enables a ready-to-sell payment gateway. You can choose from popular online payment methods in The Netherlands, Belgium, France, Germany and globally. Start accepting payments within a few minutes.

Requirements

To use the Buckaroo plugin, please be aware of the following minimum requirements:

• A Buckaroo account (Dutch or English)
• Shopware 6.5.0 up to 6.5.6.1
• PHP 8.1

Installation

We recommend you to install the Buckaroo Shopware 6 Payments plugin with composer. It is easy to install, update and maintain.

Run the following commands:

cd S6_INSTALLATION_ROOT
composer require buckaroo/shopware6
ln -s ../../vendor/buckaroo/shopware6 custom/plugins/BuckarooPayments
bin/console plugin:refresh
bin/console plugin:install --activate BuckarooPayments
bin/console cache:clear

Upgrade

You can also upgrade/update the Buckaroo plugin with composer. To do this, please run the following commands:

composer update buckaroo/shopware6
plugin:update BuckarooPayments

Configuration

For the configuration of the plugin, please refer to our Dutch or English support website. You will find all the necessary information there. But if you still have some unanswered questions, then please contact our technical support department.

Contribute

We really appreciate it when developers contribute to improve the Buckaroo plugins. If you want to contribute as well, then please follow our Contribution Guidelines.

Versioning

• MAJOR: Breaking changes that require additional testing/caution.
• MINOR: Changes that should not have a big impact.
• PATCHES: Bug and hotfixes only.

Additional information

• Knowledge base & FAQ: Available in Dutch or English.
• Support: https://support.buckaroo.eu/contact
• Contact: [email protected] or [phone]

Please note:
This file has been prepared with the greatest possible care and is subject to language and/or spelling errors.

shopware6's Issues

[BP-1726] Unclear error message is shown to customer when (iDeal) payment provider is down.

We received an email from a client that showed a screenshot of a customer that couldn't finish the checkout process. She sent our client the following screenshot:

After investigating this issue, the moment of her not being able to pay using iDeal coincided with downtime of iDeal (16th of may between 10:00 and 11:00). The error message returned when this occurs has Issuer as message, not very useful for the customer.

The error message should be more user-friendly and descriptive.

Partial payments with a cancelled part

When a partial payment has one part that is cancelled, the order in shopware will be cancelled and remain cancelled. Even when another succesful part completes the entire payment.

What happens is when you have a failed part - for example when someone enters an incorrect pin on a giftcard - a push is sent to shopware with a 690 status. This causes the order state to change to cancelled.

Then when another payment part has been succesful a new push is sent to shopware with status 190. This is supposed to reopen the order and handle the payment. However the check to see if the order should be reopened breaks. This causes the order to remain cancelled. The rest of the handling fails because you will get illegal state transitions, since the order is still cancelled instead of reopened.

The issue is in the PushController at line 140 - the part that should reopen the order:

if ($this->checkoutHelper->isOrderState(['cancelled'], $brqOrderId, $context)) {
  $this->logger->info(__METHOD__ . "|35|");
  $this->checkoutHelper->changeOrderStatus($brqOrderId, $context, 'reopen');
}

The order state is being checked to see if the order has the state cancelled. This check fails, since it is being checked against:
StateMachineTransitionActions::ACTION_CANCEL which is cancel, not cancelled.

The check is in the CheckoutHelper->getOrderTransactionStatesNameFromAction

[BUG] Client sided Creditcards payment

When using creditcard clientsided payment i always get an error. The error is thrown when using shopware 6 but also when using the Shopware PWA.

#data: array:23 [▼
    "Key" => "TRANSAXCTION_KEY"
    "Status" => array:3 [▼
      "Code" => array:2 [▼
        "Code" => 491
        "Description" => "Validation failure"
      ]
      "SubCode" => null
      "DateTime" => "2021-09-02T11:22:55"
    ]
    "RequiredAction" => null
    "Services" => null
    "CustomParameters" => null
    "AdditionalParameters" => array:1 [▼
      "AdditionalParameter" => array:3 [▶]
    ]
    "RequestErrors" => array:5 [▼
      "ChannelErrors" => []
      "ServiceErrors" => array:1 [▼
        0 => array:3 [▼
          "Name" => "creditcards"
          "Error" => "ServiceUnknown"
          "ErrorMessage" => "'creditcards' is not a valid service name."
        ]
      ]
      "ActionErrors" => array:1 [▼
        0 => array:4 [▼
          "Service" => null
          "Name" => null
          "Error" => "ActionPrimaryMissing"
          "ErrorMessage" => "No primary action specified. Please specify 1 primary action."
        ]
      ]
      "ParameterErrors" => []
      "CustomParameterErrors" => []
    ]
    "Invoice" => "10014"
    "ServiceCode" => null
    "IsTest" => true
    "Currency" => "EUR"
    "AmountDebit" => 497.94
    "TransactionType" => null
    "MutationType" => 0
    "RelatedTransactions" => null
    "ConsumerMessage" => null
    "Order" => "10014"
    "IssuingCountry" => null
    "StartRecurrent" => false
    "Recurring" => false
    "CustomerName" => null
    "PayerHash" => null
    "PaymentKey" => null
  ]
  #curlInfo: array:37 [▼
    "url" => "https://testcheckout.buckaroo.nl/json/Transaction"
    "content_type" => "application/json"
    "http_code" => 200
    "header_size" => 441
    "request_size" => 478
    "filetime" => -1
    "ssl_verify_result" => 0
    "redirect_count" => 0
    "total_time" => 0.14999
    "namelookup_time" => 0.001644
    "connect_time" => 0.012173
    "pretransfer_time" => 0.042892
    "size_upload" => 1269.0
    "size_download" => 1153.0
    "speed_download" => 7738.0
    "speed_upload" => 8516.0
    "download_content_length" => 1153.0
    "upload_content_length" => 1269.0
    "starttransfer_time" => 0.055043
    "redirect_time" => 0.0
    "redirect_url" => ""
    "primary_ip" => "SOME_IP"
    "certinfo" => []
    "primary_port" => 443
    "local_ip" => "192.168.10.110"
    "local_port" => 58928
    "http_version" => 2
    "protocol" => 2
    "ssl_verifyresult" => 0
    "scheme" => "HTTPS"
    "appconnect_time_us" => 42837
    "connect_time_us" => 12173
    "namelookup_time_us" => 1644
    "pretransfer_time_us" => 42892
    "redirect_time_us" => 0
    "starttransfer_time_us" => 55043
    "total_time_us" => 149990
  ]
  #headers: array:10 [▼
    "server" => array:1 [▶]
    "date" => array:1 [▶]
    "content-type" => array:1 [▶]
    "content-length" => array:1 [▶]
    "cache-control" => array:1 [▶]
    "pragma" => array:1 [▶]
    "expires" => array:1 [▶]
    "authorization" => array:1 [▶]
    "x-robots-tag" => array:1 [▶]
    "strict-transport-security" => array:1 [▶]
  ]

This is a test payment here. I can't fid why it is not working. Do u guys have any idea what the problem could be?

[Question] Payment State

I have an issue where when i place an test order and i select it to be cancelled or success, the shopware 6 payment status doesn't get updated. Is there something like an extra setting i need to enable to get this functionality working?

Below u see my settings for the plugin:

As u can see in the last image all my orders have payment status open but u i have paid them.

Incorrect signature on partial payments

We have a few orders with partial payments: gift-cards + ideal or creditcard, that do not complete correctly.

An example is this order:

Partly successfully paid with gift-card (20 euro). then another successful gift-card (15 euro). Those are pushed to shopware and handled correctly.

Then two failed gift-card payments of (5.40 euro). An invalid pin was used for the gift-card twice. These got pushed to shopware successfully. The plugin then sets the order status to cancelled.

Then the last part - an ideal payment (5.40) for the remaining part, was paid succesfully. This gets pushed to shopware. But it isn't handled correctly. Shopware gets the data, logs it in the buckaroo log, then just this line:

[2021-09-18T09:12:03.447678+00:00] buckaroo_payment.INFO: Buckaroo\Shopware6\Storefront\Controller\PushController::pushBuckaroo|5| [] []

Which means the message has an invalid signature:

if (!$this->checkoutHelper->validateSignature()) {
            $this->logger->info(__METHOD__ . "|5|");
            return $this->json(['status' => false, 'message' => $this->trans('buckaroo.messages.signatureIncorrect')]);
}

So this last push does not get registered/parsed successfully in shopware, and so the order is not re-opened and completed, but it stays cancelled. And in shopware we are missing the data that the order has been paid successfully.

This seems to happen with partial payment orders, that have failed parts in them.

I can provide you with order / transaction examples if needed. I do not want to post this data on github.

Finalize page not loaded correctly, order not set to paid

In src/Storefront/Controller/PushController.php the function finalizeBuckaroo doesn't work as expected. The request variables in my dump are uppercase, however the variables are set with lowercase:

$status        = $request->request->get('brq_statuscode');
$statusMessage = $request->request->get('brq_statusmessage');
$orderId       = $request->request->get('ADD_orderId');

These variables are all null. When I dump the variables you can see the difference:

dd(
	$request->request->get('brq_statuscode'), 
	$request->request->get('BRQ_STATUSCODE')
);

Because the variables are null it results in a empty finalize page and the order isn't set to paid in Shopware.

The plugin crashes shopware 6.4.9.0

When updating to shopware 6.4.9.0 on my development environment bin/console created a segmentation fault. This already happens in the composer update step that tries to run system:update:prepare.

The segmentation fault was caused by xdebug, which is running on my dev environment. Disabling xdebug fixed the segmentation fault, and showed the underlying cause. The process is trying to use an infinite amount of memory, probably caused by some looping issue.

As you can see here the memory limit of 2GB is reached by just running bin/console to get a list of commands. Increasing the memory to 4GB, 8GB, or 16GB, just makes it break at that limit.

For testing purposes this is being done a clean new shopware 6.4.9.0 installation with just the buckaroo shopware plugin installed, nothing else. I tested with php 8.1, 8.0 and 7.4, which all showed the same results.

Also tried versions 1.3.0 and 1.2.4 of the plugin, with similar results.

We did a bit of digging yesterday, the culprit seems to be in the the payment handlers somewhere. But haven't completely pinned the it down yet.

This issue is preventing the shopware 6.4.9.0 update for now.

[critical] Edit order - impossible

when installing the plugin the EDIT order button in the admin Order View is not there anymore

buckaroo-payment/extension/sw-order/index.js

computed: {
isEditable() {
return !this.isBuckarooPayment || this.$route.name !== 'buckaroo.payment.detail';
},

changed redirect behaviour from Buckaroo

When i call the /store-api/handle-payment with ideal issuer i will be redirected to the following url at Buckaroo https://testcheckout.buckaroo.nl/html/testresult.aspx.

This is all okay and as it should but i sent a few params with the /handle-payment call see following parameters:

 const handledPaymentResponse = await handlePayment(
          order.id,
          routing.getUrl(`/order-success?orderId=${order.id}`),
          routing.getUrl(
            `/order-failed?orderId=${order.id}`
          ),
          apiInstance
        );

The redirect is an relative url and buckaroo will redirect to the following page resulting in a 404: https://testcheckout.buckaroo.nl/order-success?orderId=SOME_ORDER_ID

In the past Buckaroo would redirect me back to the storefront domain.com/order-success?orderId=SOME_ORDER_ID

Is this a problem on buckaroo's end or in Shopware 6?

I am using Buckaroo Plugin 1.4.0 and SW6 6.4.15.2

[Bug] FinishUrl ignored when using shopware 6 store-api

Hello,

I am using Shopware-pwa and shopware 6 for our ecommerce platform. We are using buckaroo as the PSP for our project. When we test a payment we will always get redirected to our Shopware 6 instance while the payment gets initialized by our pwa.

pwa.com-> we initiate payment -> shopware.com/store-api/handlePayment -> shopware6.com

I asked the Developer team of the Shopware PWA team how this was possible and this is what they say.

Hi guys, the payment plugin must handle finishUrl and errorUrl that are provided within handlePayment method after the order is placed. finishUrl is an only thing that can tell the backend on what page a customer should be redirected to, after the payment succeeds. It looks like the handlePaymentByOrder method (part of PaymentService) is being invoked internally in the plugin with some other finishUrl provided, so the correct pwa url is ignored during handlePayment call

is it possible to fix this so that the finishUrl and errorUrl in the handlePaymentByOrder method will listen to the values provided by the store-api so that we can use your plugin with our PWA.

Question about refunding

We were on plugin version 1.2.2 and now we are on 1.2.4 on Shopware 6.4.7.0, But when we placed a refund normally we could edit the totalPrice with an input. Is this not possible anymore? when i place a refund with the new plugin version i always place a refund of the full order and i cant edit the total anymore. Am i missing something?

Tag for version 1.1.3

The commit b90499c has updated the composer.json version to 1.1.3, but there is no tag created yet for this version. The latest tag is 1.1.1

Could you create a tag for version 1.1.3? Thanks in advance!

Uncaught PHP Exception TypeError: "round(): Argument #1 ($num) must be of type int|float, string given"

When placing an order that contains a product that has a price with more than 2 decimals, the following error is thrown:

request.CRITICAL: Uncaught PHP Exception TypeError: "round(): Argument #1 ($num) must be of type int|float, string given" at /var/domains/customer/application/vendor/store.shopware.com/buckaroopayments/src/Storefront/Controller/PushController.php line 202 {"exception":"[object] (TypeError(code: 0): round(): Argument #1 ($num) must be of type int|float, string given at /var/domains/customer/application/vendor/store.shopware.com/buckaroopayments/src/Storefront/Controller/PushController.php:202)"} []

The provided CSRF token is not valid

After updating to 1.3.0 the following error occurs when adding an line item to the cart

[2022-03-01T08:44:38.451352+00:00] request.ERROR: Uncaught PHP Exception Shopware\Storefront\Framework\Csrf\Exception\InvalidCsrfTokenException: "The provided CSRF token is not valid" at /Users/melvinachterhuis/sites/customer/vendor/shopware/storefront/Framework/Csrf/CsrfRouteListener.php line 117 {"exception":"[object] (Shopware\\Storefront\\Framework\\Csrf\\Exception\\InvalidCsrfTokenException(code: 0): The provided CSRF token is not valid at /Users/melvinachterhuis/sites/customer/vendor/shopware/storefront/Framework/Csrf/CsrfRouteListener.php:117)"} []

When disabling the Buckaroo plugin the error is gone and adding items to the cart works as expected.

Version in composer.json is not updated

There is a new release tag 1.2.2, however the version in composer.json is stil 1.2.1. So when you install this plugin with composer, it won't update to 1.2.2.

Partial payment - transition issue

This commit 799ec8e introduced a side effect. That causes an exception when receiving successful partial payment pushes:

[2021-08-08T14:00:25.904393+00:00] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\UndefinedMethodError: "Attempted to call an undefined method named "paidPartially" of class "Shopware\Core\Checkout\Order\Aggregate\OrderTransaction\OrderTransactionStateHandler". Did you mean to call "payPartially"?" at /var/www/vhosts/shopware/releases/20210806125400/vendor/buckaroo/shopware6/src/Helpers/CheckoutHelper.php line 247 {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\UndefinedMethodError(code: 0): Attempted to call an undefined method named \"paidPartially\" of class \"Shopware\\Core\\Checkout\\Order\\Aggregate\\OrderTransaction\\OrderTransactionStateHandler\".\nDid you mean to call \"payPartially\"? at /var/www/vhosts/shopware/releases/20210806125400/vendor/buckaroo/shopware6/src/Helpers/CheckoutHelper.php:247)"} []

Partial payments - order gets incorrectly cancelled

With partial payments, a push gets send for each paid part. When a part fails, for whatever reason, the order state is set to cancelled on that push. When a push for a successful payment part is done after that, the order is reopened. This works when the pushes all get send in the correct order.

But recently we had an order, that was fully paid in parts (giftcard + ideal). All succesful payments parts got pushed. But 8 seconds after the last successful push, another push with status 490 was sent. This last push, caused the the order in shopware to be transitioned to cancelled, even though it was fully paid. In turn this prevents the rest of our order process to be initiated.

I think the core issue is that a cancelled/failed payment part should probably not cancel the order in the first place since the payment is likely still in progress.

But definitely the order should not be cancelled when it's been fully paid.

last_used_creditcard has not been set for a new Customer

https://github.com/buckaroo-it/Shopware-6-plugin/blob/9fe3867255641b13094b135a8968744a48530b7f/src/Subscribers/CheckoutConfirmTemplateSubscriber.php#L181

When an customer creates a new account, the value 'last_used_creditcard' is not available and generates an error.