[PW-5919] Implement new database to store and adjust dataflow for additionalData

[tnaber]

Description In response to #1139, we decided to persist the additional data in a different way. Additionally, the additional data will be saved for dataflows (previously not done for hpp flow) to resolve #1233. This includes the additional data fetch by the paymentDetails call.

The PaymentResponseHandler Helper has been expanded to be used in every payment flow. This class implement the 'saveAdyenResponseData' function which saves a response corresponding the a payment to the adyen_payment_response table. Among other places, this function is called in the handlePaymentResponse function. This function was previously used to update the data in the sales_order_payment table, now it also updates or creates entries in the adyen_payment_response. The aim of this class is to create a more centralised class for processing the additionalData that is passed in every response by adyen.

As indicated in a GH issue, the additionalData passed by Adyen should not overflow one of Magento's default tables. This is why the 'additionalInformation' and 'paymentId' column have been added to the adyen_payment_response table. Subsequently, the additionalData is not saved in the sales_order_payment table anymore. As a response can be saved without an order going through, a response does not necessarily have to be linked to a saved order. Thus, not always having a unique payment id assigned. As a workaround the combination of the merchant_reference and the store_id can be used a unique identifier.

Known weaknesses and strengths have been added in the comments.

Tested scenarios

• 3DS2
• 3DS1
• CC
• Alternative PMs

Fixed issue: #1233 #1139

[tnaber]

Known weaknesses:

• Additional data also in raw response
• Raw response and result_code overwritten on new response for payment
• No payment_id update for standard cc method
• No official foreign key on (store_id, merchant_reference)
• No unique key on payment id
• Payment id defaults to 0 (instead of null, is this a bug?)
• Did not find a place where the additionalData is actually requested in our own code, so if it is ever asked for I overlooked it :(

Strong point:

• Additional information column implemented in such a way that it can easily replace the additional_information column from Magento's sales_order_payment

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

No Coverage information
0.0% Duplication

[Morerice]

Due to a change of direction in order to avoid saving unnecessary data to the database, this PR will be closed.

Thanks, Jean Adyen