[v5.3.0] DSL settings for the card do not apply to the view

[wrozwad]

Describe the bug Have you considered implementing a bug bounty program? 😄 After updating the SDK to 5.3.0, I decided to switch the configuration to a much more user-friendly DSL version. Unfortunately, the card configuration is not being passed down to the view. The previous classic implementation using DropInConfiguration.Builder() works as expected.

To Reproduce

1. I defined the configuration as CheckoutConfiguration()

   CheckoutConfiguration(
   environment = environment,
   clientKey = clientKey,
   shopperLocale = shopperLocale,
   amount = amount,
   ) {
   dropIn {
       setSkipListWhenSinglePaymentMethod(true)
   }
   
   card {
       setHolderNameRequired(true)
       // setShowStorePaymentField(false) // unnecessary with session usage
   }
   }

2. I initialized DropIn with a session containing only one available payment method scheme
3. I received a form that did not display the input for the holder name

Expected behavior The DSL configuration should affect the forms in DropIn.

SDK Version 5.3.0

Additional context While debugging your library, I noticed that when using CheckoutConfiguration.addConfiguration("scheme", config), we are operating on a different instance of CheckoutConfiguration than when using during CheckoutConfiguration.getConfiguration("scheme"). As a result, the availableConfigurations map does not contain the correct configuration entry for the credit card form view.

[jreij]

a much more user-friendly DSL version

Hi @wrozwad thanks for the feedback, glad to hear you already started using it 🙂

I could not reproduce this issue on my side. Can you share the code where you call DropIn.startPayment?

[jreij]

On a side note, setShowStorePaymentField(false) does not have any effect with the sessions flow (I think we spoke about this before here anyway).

[wrozwad]

@jreij Yes, I know that setShowStorePaymentField(false) won't have any effect here - I added it just to show roughly my current configuration. But thanks for pointing it out.

My current implementation looks like this:

1. From the Compose level, I'm storing the contract for "on activity result". I pass it a ViewModel that implements SessionDropInCallback.

   val sessionContract = rememberLauncherForDropInResult(viewModel)

2. Upon clicking the CTA, I pass this contract to the ViewModel, which takes further steps. It retrieves the current session from the repository and triggers createOrderAndPayNow() function.

   private fun createOrderAndPayNow(
   contract: ActivityResultLauncher<SessionDropInResultContractParams>,
   session: PaymentSession,
   ) {
   DropIn.startPayment(
       context = context,
       dropInLauncher = contract,
       checkoutSession = session.adyenSession,
       dropInConfiguration = session.configurationProvider.get().getDropInConfiguration()!!,
       serviceClass = CheckoutSessionDropInService::class.java,
   )
   }

   Here, PaymentSession already contains information about adyenSession: CheckoutSession and configurationProvider, which is a functional interface where get() precisely returns the CheckoutConfiguration that I provided at the top. By the way, it's a pity that there's no option for null-safe retrieval of DropInConfiguration here.

[jreij]

@wrozwad thanks for sharing the details. Can you pass the checkoutConfiguration as it is to DropIn.startPayment as mentioned in the "Start Drop-in" code sample in the docs?

it's a pity that there's no option for null-safe retrieval of DropInConfiguration here.

You almost found the answer yourself 🙂 These methods are not documented or developer friendly because they are not supposed to be used for launching drop-in or creating components. We already added a warning against using them in the 5.3.0 release notes and we'll make them internal in the next release.

[wrozwad]

@jreij Okay, this is not a 1:1 replacement - and perhaps it's better. Actually, just swapping out that piece of code:

dropInConfiguration = session.configurationProvider.get().getDropInConfiguration()!!

to that one:

checkoutConfiguration = session.configurationProvider.get()

was enough. Thanks for the hint.

By the way, is it possible to move the holder name above the card number input?

[araratthehero]

Hi @wrozwad, I am happy to hear that you were able to solve the issue regarding getting the CheckoutConfiguration.

Regarding the rearrangement of the card view, currently, we do not support repositioning views in our card component.