StoredPaymentMethodDetails doesn't have support for the "subtype" field used by the native TWINT drop-in

[elitalon]

Describe the bug
Deserialisation of a POST /payments request done against a proxy backend ignores the subtype field from the paymentMethod object in the JSON body.

This results in the drop-in integration of TWINT for iOS using a web-based UI instead of the native one.

How to reproduce
Make a POST /payments request with the following JSON body:

{
    "channel": "iOS",
    "amount": {
        "currency": "CHF",
        "value": 0
    },
    "browserInfo": {
        "userAgent": "<redacted>"
    },
    "merchantAccount": "<redacted>",
    "returnUrl": "<redacted>",
    "storePaymentMethod": true,
    "countryCode": "CH",
    "paymentMethod": {
        "type": "twint",
        "subtype": "sdk"
    },
    "shopperLocale": "en_US",
    "shopperReference": "<redacted>",
    "reference": "<redacted>",
    "recurringProcessingModel": "<redacted>",
    "shopperInteraction": "Ecommerce"
}

Expected behavior
The resulting StoredPaymentMethodDetails object stores the value of the subtype JSON field.

Screenshots
Not applicable

Desktop (please complete the following information):

• Java Version: Java 21
• Library Version: 28.2.0

Additional context
This problem was discovered as part of Adyen/adyen-ios#1783.

[jillingk]

Hi @elitalon,

Thanks for reaching out here, we have a fix on the way!

Best, Jilling
Adyen

[elitalon]

Hi @jillingk.

Are there any news on this? I've seen a few releases of the library in the past weeks, but none of them seem to mention this issue.

Thanks!

[DjoykeAbyah]

Hi @elitalon!

We've merged the fix from this PR (#1380): src/main/java/com/adyen/model/checkout/TwintDetails.java.

Would you be willing to check the fix and confirm that it addresses the issue before we proceed with the release?

We appreciate your help!

Best regards,
Djoyke
Adyen

[elitalon]

@DjoykeAbyah Thanks for the heads up 👍🏼 I will give it a try.

[elitalon]

@DjoykeAbyah Speaking of testing, how do you intend us to reach that change without a new version?

Specifically, how can we point to the current state of the main branch in the pom.xml of our project?

[gcatanese]

Hey @elitalon thanks for helping out. We are not able to deploy a snapshot yet (we are looking at the options and we hope to do so in the near future) so it is indeed difficult to test.
The only option at the moment would be to build the library from source (main branch).

If that's not doable I understand, if you can please check the changes introduced by the PR #1380 and let us know if they look what you'd expect, that would be tremendously helpful. We are planning the new release shortly.

[elitalon]

@gcatanese I'll try building from source. If that doesn't work, then I'll take a look at the pull request. Cheers!

[elitalon]

Hi @gcatanese, I was able to build from source and test the integration agains our backend. I also took a look at #1380.

I think we should be good to go, as far as this issue is concerned.

It could be that we find something else when trying an end-to-end registration together with the iOS SDK. But in that case we will open a separate issue.

Thanks a lot!

[gcatanese]

That's great, thank you so much @elitalon for your help.

[DjoykeAbyah]

Hi @elitalon,

I wanted to quickly mention the Java library has just been released with the changes from #1380!

Kind Regards,

Djoyke
Adyen

[elitalon]

Thanks a lot, @DjoykeAbyah!