Describe the bug
Whenever we have a failed payment with Credit Card then we try to pay it again but this time with PayPal or Klarna we get this error: screenshot

We checked PaymentDetailsService.php#164 and we found a missing return statement there as you will see in the error.

When we checked the logs we found the following entries:

[2021-01-25 16:08:30] adyen_generic.ERROR: There was an error with the payment method. Result code "Error" in response: Array ( [pspReference] => 4556115909096866 [resultCode] => Error [merchantReference] => 10645 [paymentMethod] => paypal [shopperLocale] => de-DE ) [] []
[2021-01-25 16:11:46] adyen_generic.ERROR: There was an error with the payment method. Result code "Error" in response: Array ( [pspReference] => 4556115909096866 [resultCode] => Error [merchantReference] => 10645 [paymentMethod] => paypal [shopperLocale] => de-DE ) [] []
[2021-01-25 16:11:46] adyen_generic.ERROR: Field 'details' expected to be a Structure but is an Array [] []
[2021-01-25 16:17:19] adyen_generic.ERROR: The payment was refused, order transaction merchant reference: 10646 [] []

To Reproduce
Steps to reproduce the behavior:

1. With live mode enabled, make an order with a test card for example to get a failed payment.
2. As a logged in customer now, go to "My orders" in your account, and in your order history, you'll see the failed order.
3. Click on "Complete order" to go again to the checkout page.
4. use PayPal or Klarna as a payment method(the first time it happened to us with PayPal then we tried it again with Klarna and we saw the same error).
   5.Finish order and pay then you should see the error in the screenshot.

Expected behavior
To go to PayPal or Klarna payment page or in case of failer go back to the shop with an error message.

Additional context
We use version 1.4.0.

Describe the bug
The Test configuration button in the admin panel is not shown correctly and the click action triggers this error in console:

TypeError: Cannot read property 'null' of undefined

To Reproduce

1. View/click Test configuration button in Shopware 6.3.4.1

Describe the bug
Looks like there is a call to a domain that does not exist
When trying to go live we get this error

Possible reason:
Looks like this domain does not exist adyen-payments.com

Describe the bug
Calling watch-administration.sh results in an eslint error

  ✘  http://eslint.org/docs/rules/camelcase  Identifier 'locale_en_GB' is not in camel case  
  ../../../../../adyen/adyen-shopware6/src/Resources/app/administration/src/main.js:26:8

should be easy to fix by either adding an eslint ignore or renaming the variable.

To Reproduce
Steps to reproduce the behavior:

1. Installed production template
2. ESLINT_DISABLE=false set in .env file
3. Call ./bin/build-administration.sh
4. Call ./bin/watch-administration.sh

If the server is behind a loadbalancer there will be an Iframe issue because of the originKey

Implement gift card component with order API

Describe the bug
Changes to SalesChannelRepository cause issues with headless sales channels. The changes incorrectly assume that a default href domain is set for a sales channel (which is not possible for headless sales channels) or that the domain id in the sales channel context is not null. Since both can be null, a third fallback should be added to fetch a domain entity according to the sales channel id (like in version 3.6.0 of the plugin). Currently all of our payments via the Shopware PWA return a failed status even though they went through correctly.

Versions
Shopware version: 6.4.15.1
Plugin version: 3.7.0

To Reproduce
Steps to reproduce the behavior:

1. Setup a headless sales channel
2. Setup a Store API route
3. Make a call to this route using the API access key of the headless sales channel
4. Both hreflangDefaultDomainId and domainId in the sales channel context are null

Describe the bug
When we have the Adyen plugin installed we can't use manual created payment methods anymore (Invoice, Pay at delivery, Pay at pickup etc.). The user gets redirect to /checkout/order with a 404 message.

The following error is visible in the logs:

request.ERROR: Uncaught PHP Exception Shopware\Core\Checkout\Payment\Exception\UnknownPaymentMethodException: "The payment method 1a116955b1294a45a64aa6e1507e9028 could not be found." at /var/domains/domain.com/application/vendor/shopware/core/Checkout/Payment/PreparedPaymentService.php line 56 {"exception":"[object] (Shopware\\Core\\Checkout\\Payment\\Exception\\UnknownPaymentMethodException(code: 0): The payment method 1a116955b1294a45a64aa6e1507e9028 could not be found. at /var/domainsdomain.com/application/vendor/shopware/core/Checkout/Payment/PreparedPaymentService.php:56)"} []

Versions
Shopware version: 6.4.11.1
Plugin version: 3.4.2

To Reproduce
Steps to reproduce the behavior:

1. Pay with manually created payment method
2. Error above is thrown

Expected behavior
Payment is handled by merchant, customer sees the confirm/finish page instead of a 404 error

Implement Gift Cards as a payment method

Support unified commerce with the Terminal API

Describe the bug
Guest customers are not able to complete a payment after a failed payment. API call made to store-api.order.set-payment requires login and we get this 403 response (see screenshot).

To Reproduce
Steps to reproduce the behavior:

1. Add product to cart and proceed to checkout as guest
2. Select a failing payment method (e.g card with wrong CVC)
3. Click the 'Change payment method' link in the resulting error message.
4. Attempt to complete payment

Expected behavior
Second attempt at payment should not get stuck with error

Screenshots

To Reproduce
Steps to reproduce the behavior:

1. Fail a payment attempt.
2. Attempt to edit the order payment

Expected behavior
The edit order page is displayed and the payment method can be edited.

Actual behavior

Argument 2 passed to Shopware\Storefront\Controller\AccountOrderController::__construct() must be an instance of Shopware\Storefront\Page\Account\Order\AccountEditOrderPageLoader, instance of Shopware\Core\Checkout\Order\SalesChannel\OrderRoute given, called in /home/vagrant/shopware-dev/custom/plugins/adyen-shopware6/src/Storefront/Controller/AdyenAccountOrderController.php on line 49

I see a note on the Shopware 6 extension page that the plugin will no longer be maintained. Is this true?

https://store.shopware.com/en/adyen70424242359f/adyen-payments-for-shopware-6.html

Describe the bug
Not sure, if I have found them all yet but in one project, the checkout is setup like this:

• Step 1: Enter shipping method and addresses
• Step 2: Select payment method
• Technicall still step 2 but only after the payment method has been selected: Enter payment details
• Step 3: Summary plus entering additional data (one is required)

This results in:

• The adyen payment data is deleted as soon as one enters data in step 3 as you clear the context on all context changes which can also just be a currency change: https://github.com/Adyen/adyen-shopware6/blob/1.5.0/src/Subscriber/PaymentSubscriber.php#L370
• Saving the adyen data requires the payment method ID to be sent with it. However, as mentioned above, this can be done in a separate request and then it does not make sense to sent it again: https://github.com/Adyen/adyen-shopware6/blob/1.5.0/src/Subscriber/PaymentSubscriber.php#L341

Possible solutions:

• Use payment method ID from context, if the parameter paymentMethodId has not been provided as that is the current valid payment method ID then as it didn't change.
• Clear the adyen payment only for some context changes, e.g. if the payment method changes. Probably the only one it should be cleared actually.
• Add a scheduled task (like you already did for other stuff) that periodically checks if there are old/expired entries and remove them to avoid old payment data from incomplete checkouts filling up the database table. Maybe in combination with the context lifetime parameter: https://github.com/shopware/platform/blob/v6.3.5.1/src/Core/System/SalesChannel/Context/SalesChannelContextPersister.php#L35

Describe the bug
Cannot install & activate plugin when required with composer

Versions
Shopware version: 6.4.5.1
Plugin version: 3.2.0

To Reproduce
Steps to reproduce the behavior:

1. Require plugin with composer: composer require store.shopware.com/adyenpaymentshopware6
2. Install & Activate plugin ./bin/console plugin:install --activate AdyenPaymentShopware6
3. Error is thrown: Cannot declare interface Psr\Log\LoggerAwareInterface, because the name is already in use

Expected behavior
Plugin is installed & activated

Screenshots
If applicable, add screenshots to help explain your problem.

Describe the bug
When we select an Adyen payment method in the frontend and want to complete the order, the modal to specify the payment details no longer opens and only the loader is displayed.

In the console we can find the following JS error:

schemeError: Component could not mount. Root node was not found.

Versions
Shopware version: 6.9410.1
Plugin version: 3.4.0

To Reproduce
Steps to reproduce the behavior:

1. go to checkout
2. fill out address
3. select adyen payment method
4. click on submit order
5. only loader is diyplayed, check browser console for error

Expected behavior
When submitting an order there should open an additional modal with the secure payment fields from adyen

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Browser: Firefox v100, Chrome v101

Additional context
Previous analysis / checked items:

• Shopware Upadte from 6.4.9.0 to 6.4.10.1
• Plugin update from 3.3.1 to 3.4.0
• Rebuild Storefront and JS (build-storefront.sh / build-js.sh)
• Cleared cache
• Uninstalled and reinstalled plugin

The problme seems to exist since 04/22/2022. It no longer works on any of our instances without a previous plugin update or deployment.

I already was in contact with Adyen Support, they advised I open up an issue here.

I hope anyone can help us out here.
Thanks.

Describe the bug
Developing in dev mode, this error occurs when cookie offcanvas appears.

Debugging with xdebux lead to "_uetvid" (and probably all of the following) which causes this error because ob missing "snippet_name" array index.
https://github.com/Adyen/adyen-shopware6/blob/develop/src/Framework/Cookie/AdyenCookieProvider.php#L33

Versions
Shopware version: [6.4.2.1
Plugin version: 3.0.0

To Reproduce
Steps to reproduce the behavior:

1. Set APP_ENV to "dev"
2. Delete all cookies
3. try to configure cookie settings
4. offcanvas with error appears

Expected behavior
Normal cookie configuration view

Desktop (please complete the following information):

• OS: Ubuntu 20.04.
• Browser Chromium
• Version 92.0.4515.107

Describe the bug
Missing reverse side on OrderTransaction for payment response. Just missing the corresponding EntityExtension.

To Reproduce
Execute bin/console dal:validate after installing plugin on Shopware 6.3.5.1

Describe the bug
Test Configuration Button in Admin backend always uses Test API Key, even if the Live Environment is activated.

Versions
Shopware version: [e.g. 6.4.11.1]
Plugin version: [e.g. 3.4.1]

To Reproduce
Steps to reproduce the behavior:

1. Go to the Admin Backend and into die Adyen Payments Configuration
2. Enter Valid Live API Key, Valid Merchant Account, valid live endpoint URL prefix and activate Live Environment toggle
3. Click on 'Test Configuration' Button
4. See error 'Unauthorised'

Expected behavior
I expected a success message

Screenshots
I think a description is plentiful in this case

Desktop (please complete the following information):

• OS: [Tested on Linux CentOs 7, Linux CentOs 8, Windows 10 and Windows 11 and Mac OSX]
• Browser [Tested in Chrome, Firefox, Safari and Microsoft Edge]
• Version [Current Versions]

Smartphone (please complete the following information):
No Smartphone was tested

Additional context
Just took me almost an entire work day to figure out why the plugin kept responding with Unauthorized. So I backtracked the requests, to find out that your plugin always uses the Test API Key, regardless of Environment configuration.
It is an easy, I would have created a Pull Request, but I am not that familiar with Github, so I didn't bother.

Steps to fix:

Change $client->setXApiKey($dataBag->get(ConfigurationService::BUNDLE_NAME . '.config.apiKeyTest'));
To: $client->setXApiKey($dataBag->get(ConfigurationService::BUNDLE_NAME . '.config.environment') ? ($dataBag->get(ConfigurationService::BUNDLE_NAME . '.config.apiKeyLive')) : ($dataBag->get(ConfigurationService::BUNDLE_NAME . '.config.apiKeyTest')));

Describe the bug
With multiple sales channels the NotificationReceiverController would require a corresponding Storefront sales channel with a correct domain configuration. It will not work for headless sales channels and it might also be tricky regarding which URL to use if the sales channel has multiple or one uses the same adyen configuration for multiple sales channels.

Instead if would make more sense to either use the admin API ACL definitions with a corresponding permission
or a custom route scope defintion.
The custom route scope is probably the way to go as you can define it for the adyen prefix, and can create your own authentication which you probably need for the web hooks. It should optionally be possible to specify the sales channel ID in the URL, e.g. as query parameter or suffix.

It would probably be necessary

Versions
Shopware version: 6.4.11.1
Plugin version: 3.4.1

Describe the bug
When executing dal:validate with Shopware 6.4.7.0 and the plugin in version 3.2.0 I get the following errors:

=========================================
Adyen\Shopware\Entity\PaymentResponse\PaymentResponseEntityDefinition
---------------------------------------------------------------------
 * Missing version reference for foreign key column order_transaction.id for definition association adyen_payment_response.orderTransaction
Adyen\Shopware\Entity\Refund\RefundEntityDefinition
---------------------------------------------------
 * Missing reverse one to many association for Adyen\Shopware\Entity\Refund\RefundEntityDefinition <-> Shopware\Core\Checkout\Order\Aggregate\OrderTransaction\OrderTransactionDefinition (orderTransaction)
 * Missing version reference for foreign key column order_transaction.id for definition association adyen_refund.orderTransaction

Versions
Shopware version: 6.4.7.0
Plugin version: 3.2.0

To Reproduce
Steps to reproduce the behavior:

1. Install a new Shopware instance (blank).
2. Add Adyen plugin (e.g. using composer).
3. Install and activate aAdyen plugin.
4. Executed bin/console dal:validate

Expected behavior
No error to occur.

Describe the bug
There seem to be some minor issues with the entity configuration according to dal:validate command.

As it runs in our pipeline to verify our own configuration, I noticed it immediately.

Output:

Checking for errors in entity definitions
=========================================

Adyen\Shopware\Entity\Notification\NotificationEntityDefinition
---------------------------------------------------------------

 * Missing property errorCount in Adyen\Shopware\Entity\Notification\NotificationEntity
 * Missing property errorMessage in Adyen\Shopware\Entity\Notification\NotificationEntity
 * No getter function for property errorCount in Adyen\Shopware\Entity\Notification\NotificationEntity
 * No setter function for property errorCount in Adyen\Shopware\Entity\Notification\NotificationEntity
 * No getter function for property errorMessage in Adyen\Shopware\Entity\Notification\NotificationEntity
 * No setter function for property errorMessage in Adyen\Shopware\Entity\Notification\NotificationEntity


Adyen\Shopware\Entity\PaymentResponse\PaymentResponseEntityDefinition
---------------------------------------------------------------------

 * Missing property token in Adyen\Shopware\Entity\PaymentResponse\PaymentResponseEntity
 * No getter function for property token in Adyen\Shopware\Entity\PaymentResponse\PaymentResponseEntity
 * No setter function for property token in Adyen\Shopware\Entity\PaymentResponse\PaymentResponseEntity

To Reproduce
Steps to reproduce the behavior:

• Install and activate the plugin.
• Execute bin/console dal:validate

Expected behavior
There should be no errors reported.

After I updated to Shopware 6.4.8.2 and Adyen plugin 3.1.1 the payment does not go through anymore. After entering card details in the popup (test visa card) I get a FRAMEWORK__ROUTING_INVALID_ROUTE_SCOPE. In detail:

• call to .../_proxy/store-api?path=/store-api/checkout/order
  results in `{"errors":[{"status":"412","code":"FRAMEWORK__ROUTING_INVALID_ROUTE_SCOPE","title":"Precondition Failed","detail":"Invalid route scope for route store-api.checkout.cart.order.","meta":{"parameters":{"routeName":"store-api.checkout.cart.order"}}}]}``

• call to _proxy/store-api?path=%2Fstore-api%2Fhandle-payment
  results in {"errors":[{"code":"VIOLATION::IS_BLANK_ERROR","status":"400","title":"Constraint violation error","detail":"Dieser Wert sollte nicht leer sein.","source":{"pointer":"\/orderId"},"meta":{"parameters":{"{{ value }}":"null"}}}]}

• call to _proxy/store-api?path=%2Fstore-api%2Fadyen%2Fpayment-status
  results in "Order ID not provided"

I guess the exception thrown in the first call is the reason for the other errors. The payload shows an "undefined" instead of an order id, e.g. http://sw01.test/checkout/finish?orderId=undefined

Any idea why this is happening?

Headless integrations have to add workaround for getting /paymentMethods data
With headless integrations such as PWAs it would be useful to extend each Adyen payment method entity to include the corresponding data from the /paymentMethods API response from adyen as well as fields like useAdyen: true, and type:scheme

Proposed solution
Create entity extension for PaymentMethodEntity and add new fields for usesAdyen, type as well as json field for the filtered /paymentMethods data for each PM.
Listen for requests to /store-api/v*/payment-method and update all adyen PMs with the latest data from the API
Find a way to include adyen info in the /store-api/v*/payment-method API response

Alternative solution
Another solution would be to periodically update the payment method entities via a cronjob instead of listening for payment-method requests

Describe the bug
There are reports of payments failing for non-default customer groups.

To Reproduce
Steps to reproduce the behavior:

1. Pay with a customer belonging to a non-default customer group using Klarna.
2. See logged error in screenshot.

Expected behavior
Payments should be processed for all customer groups.

Screenshots

Describe the bug
This problem occurs only on shops, that have another domain configured in saleschannel.
For example, the configured domain in saleschannel ist not example.com, but example.com/en.

To Reproduce
Steps to reproduce the behavior:

1. Log in to administration backend, and go to saleschannels
2. Scroll down to domains and change your existing domain to example.com/en.
3. Save the settings and visit the frontend. Check if address is example.com/en.
4. Buy a item and finish the checkout.
5. When example.com/adyen/redirect-result will be called, the shop is redirecting to example.com/en.

Expected behavior
On 5. it should redirect to example.com/en/adyen/redirect-result and than correctly to checkout/finish page.

Desktop (please complete the following information):

• OS: Manjaro
• Browser: Chrome, Firefox
• Latest Versions

Additional context
Add any other context about the problem here.

Describe the bug
I get "Call to a member function format() on null in the logs for AdminController:356 (using plugin version 3.4.1 in live mode). I guess, if updatedAt is null, there is no date object and hence no format(), but I did not further investigate.

Versions
Shopware version: [e.g. 6.4.12.0]
Plugin version: [e.g. 3.4.1]

The PaymentDetailsService throws an error "Call method on null' when calling it.
In the Shopware 6 OrderTransactionEntity the order is null, so no SalesChannelId of the OrderEntity is retrieved.

Versions
Shopware version: 6.4.2.1
Plugin version: 3.0.0
PHP version: ^8.0 | ^7.4

To Reproduce
Steps to reproduce the behavior:

1. Initialize PaymentDetailsService in a controller or an EventListener.
2. Pass the OrderTransactionEntity for the order.
3. Complete an order and check the PaymentDetails

Expected behavior
Return PaymentDetails from PaymentDetailsService

Code Example

`
........
class OrderEventListener implements EventSubscriberInterface
{
public function __construct(private LoggerInterface $logger, private OrderService $orderService)
{
}

/*
 * @return array<string, mixed>
 */
public static function getSubscribedEvents()
{
    return [
        'state_enter.order_transaction.state.paid' => 'onOrderStatePaidEvent',
    ];
}

public function onOrderStatePaidEvent(OrderStateMachineStateChangeEvent $event): void
{
    try {
        $this->logger->info('Paid order....');
        $order = $event->getOrder();
        if ($order instanceof OrderEntity) {
            $this->getPaymentDetails($order);
        }
    } catch (RuntimeException $exception) {
        $this->logger->critical($exception->getTraceAsString())
        );
    }
}

private function getPaymentDetails(OrderEntity $order): void {
    $transaction = ($order->getTransactions())->filterByState(OrderTransactionStates::STATE_PAID)->first();
    $paymentDetails = $this->paymentDetails->getPaymentDetails([], $transaction);
}

.......
}
`

Describe the bug
When we create a (headless) guest order through the saleschannel api we receive this error:

Line 401 of vendor/adyen/adyen-shopware6/src/Handlers/AbstractPaymentMethodHandler.php it tries to get this object: $salesChannelContext->getShippingLocation()->getAddress()->getCountryState() but getAddress() is null

This will produce an exception with message: Call to a member function getCountryState() on null

This is probably because the context is recreated on a guest order so it misses those addresses, but also f.e. the customer.
Why is the context expected to have this information? Is this expected to have that information? We noticed other payment methods using the order to get this information from.

To Reproduce
Steps to reproduce the behavior:

1. create a headless guest order

POST {{host}}/sales-channel-api/v3/checkout/guest-order
sw-access-key: {{swApiKey}}
sw-context-token: {{swContextToken}}
Accept: */*
Content-Type: application/json

{
    "billingAddress": {
        "street": "BillingStreet 1",
        "city": "City",
        "zipcode": "T11 A11",
        "countryId": "someid",
        "firstName": "First Name Billing",
        "lastName": "Last Name Billing",
        "salutationId": "someid",
        "additionalAddressLine1": ""
    },
    "shippingAddress": {
        "street": "shipping street 1",
        "zipcode": "T11 A11",
        "city": "City",
        "countryId": "someid",
        "firstName": "First Name Shipping",
        "lastName": "Last Name Shipping",
        "salutationId": "someid",
        "additionalAddressLine1": ""
    },
    "storefrontUrl": "https://someurl,
    "firstName": "Firstname Customer",
    "lastName": "Lastname Customer",
    "email": "[email protected]",
    "salutationId": "someid"
}

and than pay the order

sw-access-key: {{swApiKey}}
sw-context-token: {{swContextToken}}
Accept: */*
Content-Type: application/json

{
    "finishUrl": "https://someurl"
}

Expected behavior
Init the order process and get redirect url

Describe the bug
A clear and concise description of what the bug is.

See: https://github.com/Adyen/adyen-shopware6/blob/develop/src/Handlers/PaymentResponseHandler.php#L299

where for authorized, refused and errors, only the resultCode is provided but not refusal reason or code.

However, in order to provide the user with error codes related to the refusal reason, it is necessary to have this information in a PWA.

Describe the bug
The Shopware 6 affiliate marketing is not working with current adyen plugin, nothing is tracked.
The marketing tool ist described here (https://docs.shopware.com/en/shopware-6-en/tutorials-and-faq/affiliateprogram), the codes are attached to shop url and tracked after order in order data record.
When we deactivate adyen plugin and use shopware internal payment methods its working correctly.

Versions
Shopware version: 6.4.14.0
Plugin version: 3.6.0

Describe the bug
When trying to update the plugin via the shopware backend, there is an error message:
Required plugin/package "monolog/monolog ^1.16" does not match installed version == 2.4.0.0.

Versions
Shopware version: 6.4.9.0
Plugin version: 3.3.1

To Reproduce

1. Go to installed plugins
2. Click "update" for the Adyen Payments für Shopware 6 plugin

Expected behavior
The plugin updates without an error

Screenshots

Additional context
When manually changing the monolog version in the composer.json back to "^2" from "^1.16" the plugin update can be done via console.
Commit that does change the version constraint: 9e9e9e3

Describe the bug
PayPal shows N/A on the address line, because you don't split the house number from the address line.

Versions
Shopware version: v6.4.9.0 Stable Version
Plugin version: Version: 3.3.1

To Reproduce
Steps to reproduce the behavior:
Pay with PayPal

Expected behavior
House number should be split from the address line and should display correct on any payment, and in Adyen backend.

Desktop (please complete the following information):

• OS: any
• Browser any
• Version any

Smartphone (please complete the following information):

• Device: any
• OS: any
• Browser any
• Version any

Describe the bug
If your sales channel domain is not / the adyen redirect URL is generated wrong. The reason is that the Shopware only uses the storefront router, if certain prefixes are used: https://github.com/shopware/platform/blob/trunk/src/Storefront/Framework/Routing/Router.php#L185 is used.

Append the route with frontend. or payment..

To Reproduce
Create a sales channel with a domain like https://www.example.com/en and only that URL.

This will result in a payment redirect URL like: https://www.example.com/adyen/redirect-result.

** PR **
Created a PR for this: #137

Describe the bug
Since new Shopware version, we receive this error in the checkout:
Attempted to call an undefined method named "getShopwareVersion" of class "ContainerKsnNhda\StoreService_93b91c4
src/Service/ClientService.php:113

Versions
Shopware version: 6.4.8.1
Plugin version: 3.3.0

To Reproduce

1. Put items in basket
2. Go to checkout/confirm page in SW
3. You'll receive an 500 error, see error log

Expected behavior
Would expect no error

Screenshots

Is your feature request related to a problem? Please describe.
Whenever we refund a user from Adyen admin panel and the status doesn't change on Shopware backend.

Describe the solution you'd like

• We want to be able to make an order refund from Shopware backend by changing the order status.
• If we refunded a payment from Adyen admin panel the order status is updated at Shopware backend.

Describe the bug
When setting sales channel's specific configuration and there's no default value the library throws an exception about no environment being set.

To Reproduce
Steps to reproduce the behavior:

1. Create multiple storefront sales channels.
2. Set configuration for every sales channel.
3. Attempt to use the frontend/checkout

Expected behavior
The plugin should use the current sales channel configuration and no error should be triggered.

Describe the bug

If trying to install the plugin using the project's composer there is an error upon activating / refreshing the plugin list as it tries to require a missing autoload.php which is not necessary as the dependencies are already loaded by the project's main autoload.php.

To Reproduce
Add

    "repositories": [
        {
            "type": "git",
            "url": "https://github.com/Adyen/adyen-shopware6.git"
        }
    ],

to the project's composer.json.

Execute: composer require "adyen/adyen-shopware6:dev-develop"

Execute

bin/console plugin:refresh
bin/console plugin:install --clearCache --activate AdyenPaymentShopware6

Expected behavior
In the file for \Adyen\Shopware\AdyenPaymentShopware6 the require_once __DIR__ . '/../vendor/autoload.php'; should only be done, if not installed by composer. Probably the easiest way is to only require the file if it exists.

Describe the bug
It appears the custom fields like PSP transaction ID are not stored on the order transaction.
Not sure, if that is by design.

Expected behavior
Store custom fields on order transaction.
Also way not store the current PSP reference ID too. why only the original?

Additional context

You execute: $transaction->getOrderTransaction()->setCustomFields($customFields);
However, the Shopware DAL is not an ORM and therefore this does not store the fields at all. You just set it in the order transaction object.

In order to store custom data on the order transaction you need to do something like this:

        $context->scope(
            Context::SYSTEM_SCOPE,
            function (Context $context) use ($transaction, $customFields): void {
                   $this->orderTransactionRepository->update(
            [
                [
                    'id' => $transaction->getId(),
                    // Shopware uses JSON SQL functions to update only provided fields.
                    'customFields' => $cusotmFields,
                ],
            ],
            $context,
        );
            },
        );

Describe the bug
When the Adyen plugin receives a webhook: "OFFER_CLOSED" the Shopware order payment status is not updated. The order payment status stays "In Progress"

Versions
Shopware version: 6.4.12.0
Plugin version: 3.4.1

Expected behavior
The payment status on the order is updated to "Closed" or "Failed"

Screenshots

Describe the bug
In order to test all possible payment errors, it is possible to be able to specify additionalData.RequestedTestAcquirerResponseCode in the \Adyen\Shopware\Handlers\AbstractPaymentMethodHandler::preparePaymentsRequest method.

According to documentation: https://docs.adyen.com/development-resources/test-cards/result-code-testing/adyen-response-codes

Best would be to add the information somehow with the payment-details request or maybe automatically convert the holder name to the correct value that way it can be entered in the credit card form.

It cannot be set currently that way because all additional data is overridden here:
https://github.com/Adyen/adyen-shopware6/blob/develop/src/Service/PaymentStateDataService.php#L82
and in the php api library the CheckoutStateDataValidator removes it, if not set after calling it:
https://github.com/Adyen/adyen-php-api-library/blob/develop/src/Adyen/Service/Validator/CheckoutStateDataValidator.php

I tried the card holder option. However, not all error codes seem to provide the correct refusal code with the holder name. a lot just result in FRAUD instead of the corresponding refusal code but e.g. differentiating between refused and ERROR works with the holder name too.

Is your feature request related to a problem? Please describe.
Currently you replace the Storefront change payment method route to ensure you can set the adyen data there.

However, this is can be problematic, if e.g. other plugins would do this too, e.g. multiple payment plugins.

Describe the solution you'd like
These are not the only solutions but some possibilities:

• Create an EventSubscriber that listens to KernelEvents::REQUEST: https://symfony.com/doc/current/reference/events.html#kernel-request, checks $request->attributes->get('_route') to determine it is frontend.account.edit-order.change-payment-method. If it is, check if the adyen payment data is provided and then call your custom logic and setResponse to the corresponding RedirectResponse.
• Alternatively, might be simpler or necessary as Shopware determines various contexts with those events which you might need: Use a controller event (ensure correct priority according to KernelListenerPriorities from Shopware) https://symfony.com/doc/current/reference/events.html#kernel-controller and ìf the correct controller/route is used and the adyen payment data, use setController to have it use your controller instead. See also https://symfony.com/doc/current/components/http_kernel.html#component-http-kernel-kernel-controller and https://symfony.com/doc/current/event_dispatcher/before_after_filters.html#creating-an-event-subscriber

When a shopper selects card payment and checks the box to 'save for next use', we store the payment method in checkout, but the next time the shopper goes to checkout, the previously used PM (i.e. credit card) is pre-selected instead.
It would be an improvement to pre-select oneclick after customer pays with and saves credit card.

Describe the bug
Does support Cards payment for PWA? Because now I get error when try use it for PWA

Describe the bug
LineItem description ist not set on inherited variant name.
Therefore the payment request fails.

To Reproduce
Steps to reproduce the behavior:
1: Create an article and within variants with inherited name
2: Order the item
3: $lineItem['description'] is empty
4: Request fails and tells that InvoiceLines are missing (also wrong)

Expected behavior
Get the name ob the base article when imherited

This issue was first mentioned here:
#136

and was supposed to be fixed with the following PR:
https://github.com/Adyen/adyen-shopware6/pull/137/files

We've tested this with the newest Adyen & Shopware 6 version but the sales channel is still missing from the redirect url.

To Reproduce

• Create a sales channel with a domain like https://www.example.com/en and only that URL.
• Add a product to the cart and choose a payment method like Sofort.
• Finish the order with the test data.
• This will result in a payment redirect URL like: https://www.example.com/adyen/redirect-result?_csrf_token=....&_sw_payment_token=....
• The redirect URL should be: https://www.example.com/en/adyen/redirect-result?_csrf_token=....&_sw_payment_token=....

Add paybylink to the plugin

Hi,

I was not sure how to best let you know about this, so I just added an issue here.

I forgot to mention this during our meeting today but in the project I showed you, we use non default payment error handling:

• In that project we restore the cart upon order creation.
• And delete that cart if the payment was successful.

This allowed us to just return to the payment method step of the checkout upon payment errors and the user could leave the payment process but still continue with the order.

However, in a default checkout this is a bit differnt, upon failed payment the following could be done:

• Repay
• Change payment method and repay.

This should also be testet, if it works correctly with PWAs.
It should work fine as that is default Shopware behavior and functionality but as mentioned: In the project I showed, it is handled differently, so you probably should at least verify it works also with the default behavior.