[Feature] Support Adyen Actions without clientKey for custom UI

[eder-trainline]

Context

For scenarios where customers have built their own UI and all communication with the Adyen server is handled by their own servers, the clientKey is not necessary in the Adyen SDK of the app because it will not be used. In these cases, we want to ensure that the AdyenAction uses only the ThreeDS2ClassicActionHandler internally and never the ThreeDS2CompactActionHandler. Additionally, when instantiating the AdyenActionComponent in these cases, it should not be mandatory to provide an ApiContext, or at least there should be an option to use an ApiContext that does not include a client_key in its attributes.

Feature Request

I am requesting the addition of a feature that allows the use of Adyen Actions without the need to pass a clientKey. This would benefit developers who have implemented their own UI and do not require the standard clientKey authentication mechanism in the APP because it is already done by their servers.

Proposed Solution

• Implement a way to handle Adyen Actions independently of the clientKey requirement.

Benefits

• Increased flexibility for developers using custom UI.
• Simplified integration for specific use cases where the clientKey is not necessary.

Thank you for considering this feature request.

[erenbesel]

Hello @eder-trainline

Thank you for this post! As I understand from your post, you are using the old 3DS2 flow. Starting with API version v67 and above, we support a new, better 3ds2 flow (you can see some details here)

The new flow requires only 1 /payment/details whereas the old flow requires 2 (a new action object in the /payments response with a type threeDS2, not threeDS2Fingerprint/threeDS2Challenge). If backend API version is not an issue, we definitely recommend the use of the newer/easier approach.

As making changes in support of an older flow may not be the best approach at the moment, have you considered moving to the newer flow by any chance?

[eder-trainline]

@erenbesel

As far as I understand, the threeDS2 has a characteristic that I am not interested in; it uses the ThreeDS2CompactActionHandler, which makes the app communicate directly with Adyen servers. I want to ensure all communication is done from my server to the Adyen server. This led me to choose threeDS2Fingerprint/threeDS2Challenge, which uses the ThreeDS2ClassicActionHandler, ensuring that all communications from the app are done primarily with my backend.

This is why I don't want to have the clientKey in my app.

It makes sense, right?