adyen / adyen-shopware6 Goto Github PK
View Code? Open in Web Editor NEWAdyen Payment plugin for Shopware 6
License: MIT License
Adyen Payment plugin for Shopware 6
License: MIT License
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:
Expected behavior
Second attempt at payment should not get stuck with error
Add paybylink to the plugin
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"
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:
Expected behavior
Payment is handled by merchant, customer sees the confirm/finish page instead of a 404 error
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:
Expected behavior
No error to occur.
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.
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
Does support Cards payment for PWA? Because now I get error when try use it for PWA
Implement Gift Cards as a payment method
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
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
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:
Expected behavior
The plugin should use the current sales channel configuration and no error should be triggered.
To Reproduce
Steps to reproduce the behavior:
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
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:
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
Implement gift card component with order API
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?
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:
bin/console dal:validate
Expected behavior
There should be no errors reported.
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):
Smartphone (please complete the following information):
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:
Expected behavior
I expected a success message
Screenshots
I think a description is plentiful in this case
Desktop (please complete the following information):
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')));
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:
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
Not sure, if I have found them all yet but in one project, the checkout is setup like this:
This results in:
Possible solutions:
paymentMethodId
has not been provided as that is the current valid payment method ID then as it didn't change.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
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
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
Expected behavior
The plugin updates without an error
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
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
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:
ESLINT_DISABLE=false
set in .env
file./bin/build-administration.sh
./bin/watch-administration.sh
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
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:
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):
Additional context
Previous analysis / checked items:
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
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
There are reports of payments failing for non-default customer groups.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Payments should be processed for all customer groups.
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]
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:
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
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
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
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
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:
Expected behavior
Normal cookie configuration view
Desktop (please complete the following information):
Support unified commerce with the Terminal API
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
https://www.example.com/adyen/redirect-result?_csrf_token=....&_sw_payment_token=....
https://www.example.com/en/adyen/redirect-result?_csrf_token=....&_sw_payment_token=....
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
Expected behavior
Would expect no error
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:
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:
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.
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:
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
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:
composer require store.shopware.com/adyenpaymentshopware6
./bin/console plugin:install --activate AdyenPaymentShopware6
Expected behavior
Plugin is installed & activated
Screenshots
If applicable, add screenshots to help explain your problem.
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:
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
.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-subscriberDescribe 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:
example.com/en
.example.com/en
.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):
Additional context
Add any other context about the problem here.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.