[Bug]: v11 broken payments services (checkout vs classic)

[ollym]

Description

There's a bug in checkout/payments_api vs payment/payments_api

Steps to reproduce

https://github.com/Adyen/adyen-ruby-api-library/blob/main/lib/adyen/services/checkout/payments_api.rb
https://github.com/Adyen/adyen-ruby-api-library/blob/main/lib/adyen/services/payment/payments_api.rb

These two files contradict each other and depending on the order they are loaded produce different results.

If we load classic payments before checkout payments, then service is going to be "Checkout" for all, and if we load checkout payments before classic payments, then service is going to be "Payment" for all

Actual behavior

No response

Expected behavior

If we load classic payments api then the service is always "Payment"
If we load checkout payments api then the service is always "Checkout"

Code snippet or screenshots (if applicable)

No response

Adyen Ruby API Library version

11.0.0

Ruby language version

All

Operating System

macOS

Additional context

No response

[ollym]

And the way this manifested in our application is requests were going to:

https:/xxx.adyenpayments.com/pal/servlet/Payment/v71/sessions

Which is obviously the classic payments api url path not the checkout payments path, and so this was failing with error:

701 Version 71 is not supported, latest version: 68

Because v71 is only for checkout payments sdk, and the latest version for classic payments sdk is 68

[ollym]

We've since dropped this library and written our own, so less critical than before, but i'd leave this issue open to help anyone else still affected.

[gcatanese]

Thank you @ollym for reporting this. Can you share a code snippet so I can understand/replicate the issue?
Do you use the PaymentsApi facade to access the Classic Payments API handlers?

[pplant]

@gcatanese it seems that services/payment/payments_api.rb and services/checkout/payments_api.rb are clashing because they are not scoped and have basically the same classname and namespace:

services/payment/payments_api.rb

module Adyen

  # NOTE: This class is auto generated by OpenAPI Generator
  # Ref: https://openapi-generator.tech
  #
  # Do not edit the class manually.
  class PaymentsApi < Service

services/checkout/payments_api.rb

module Adyen

  # NOTE: This class is auto generated by OpenAPI Generator
  # Ref: https://openapi-generator.tech
  #
  # Do not edit the class manually.
  class PaymentsApi < Service

This causes that all requests try to go through the Payment service instead of the Checkout service. Causing the version issue described above. Since they seem to be auto generated its not possible to properly scope them

[pplant]

@gcatanese yesterday I tried to properly fix this issue by working on the .mustache files by namespacing the services. However I run into an issue with the Recurring and DataProtection services which seem to have changed from a small to big api service which seems not to be the case on the Open API definition. Hence the recurring_api function etc was not generated inside the single service. Furthermore I got a bit discouraged by the wide impact this would have since all big apis would be namespaced with:

Adyen::Services::[ServiceName]::[ClassName]

e.g. Adyen::Services::Checkout::PaymentsApi

p.s. The additional Services namespace is needed otherwise the Checkout module would collide with the Checkout single service class

[gcatanese]

Thank you @pplant for the clarifications and trying to solve it. It is indeed an issue, given the Ruby global module hierarchy.

We are going to look deeper and find a solution.

[gcatanese]

As a tmp workaround I think you can use the fully qualified explicit service paths like:

client.checkout.payments_api.payment_methods(request)

[ollym]

As a tmp workaround I think you can use the fully qualified explicit service paths like:

client.checkout.payments_api.payment_methods(request)

No, it just depends on the load order of the classes.

client.checkout.payments_api.payment_methods(request) # this works
client.payment.payments_api.payment_methods(request) # this will fail

And same true in reverse:

client.payment.payments_api.payment_methods(request) # this works
client.checkout.payments_api.payment_methods(request) # this will fail

There is no workaround here, the classes are conflicting.

[pplant]

I'm fearing there is no workaround for this other than namespacing the two services in question. I'm happy to share my fixing attempt in an PR. However there is this issue with the recurring and data protection api.