Adyen Adapter (deprecated)

General supported functionality

Method	Implemented status
Payment
Capture Full / Partial	/
Credit Full / Partial	/
Cancel

Adapter Specific Functionality

| Functionality | | ----------------------- | ----------------------------------------------- | | Supported Services | Adyen Checkout SDK | | Verified Payment Types | Card
Invoice
Direct Payments
Paypal | | B2B support | No | | Gift Card Functionality | No | | PayLater | Yes |

We are using what is called the “Classic Checkout SDK“, and it is now a legacy SDK that is replaced by the Adyen Drop-In solution. When looking at their API explorer, our endpoints are under the “Classic Checkout SDK“ part. Adyen API Explorer

The PaymentSession call takes care of all the information that is needed to set up the payment, but that is also the only endpoint that we are using. There is no validation call that can be made to verify the payment, other than a call to payment/result that can be made to Adyen, but is not used by us. Instead, there is a notification added in the Adyen administration page. Authn

This notification must be set up to allow information about the completed payment to reach Storm Message, that in turn trigger the CompletePayment step. This notification call MUST always be responded with a 200 ok response. Failing in doing this may result in Adyen blacklisting the endpoint, and not sending any more notifications until the previous messages are recieved correctly.

Upgrading to Adyen v67

The new version of the Adyen adapter, called AdyenV67, is set up to work in exactly the same way as the old v37, with all the changes made “under the hood“. It will use the same paymentmethod, which means that both versions can't be made available at the same time.

First, prepare the database by adding the paymentservice as available for the application. This is done by adding PaymentMethod 162, using PaymentService 27 to the vApplicationPaymentMethod view. If the application already is using Adyen, use the following call:

update vApplicationPaymentMethod set PaymentServiceId = 27 where ApplicationId = xx and PaymentMethodId = 162

Next, information need to be added to vApplicationPaymentAttribute, and this is the information that is added in Storm Admin. I do not understand why adding and saving the information there doesn’t add the lines here. Adding this functionality is a recommended fix for the future. Changing this information is not allowed using direct query, instead a stored procedure is used: Gaea.dbo.coApplicationPaymentAttribute_Insert.

Lastly, there are 3 URL's that differ from the old Adyen setup:

• PspEndpointUrl(83) = https://checkout-test.adyen.com/v67/
• StormCompleteUrl(27) = https://message.lab.storm.io/1.0/Adyen/Complete.ashx?ApplicationId=160&v=V67 ← observe the query. V67 is important to allow Message to differentiate the calls.
• Script(81) = https://checkoutshopper-test.adyen.com/checkoutshopper/assets/js/sdk/checkoutSDK.1.9.7.min.js

The script should also be updated at the frontend site. Inform the partner about this.

Testing Adyen

Adyen uses CORS to validate that the caller is the same as the origin page. This makes testing locally a challenge, as there must be a consistent public address that can be validated against together with the call. Using a test page that can make the calls is a solution to please this check, and customers like RoyalDesign has helped us with this in the past. Contact Andreas Therner for access to their system. It would be better if Storm had a functioning test page that would allow this too, as it is possible that more PSP's could start using CORS.