Adyen: Support for application information

[jpgnotgif]

I would like to propose adding support for including application information scoped specifically to direct integrations. See this page for more details.

Given that this project abstracts the direct integration approach, I propose adding support for the applicationInfo.externalPlatform request parameter for now. As a first approach, I propose sending the following JSON payload for externalPlatform:

{
  "externalPlatform": {
    "name": "<PlatformName>",
    "version": "<LibraryVersion>",
    "integrator": "<IntegratorName>"
  }
}

Clients using this library should specify a value for each key name via environment variables. If no such value is provided, we do not send a value to Adyen.

The benefit of addressing this issue allows merchants utilizing this library to identify themselves to Adyen as well as facilitating integration troubleshooting. Furthermore, Adyen uses this information to resolve merchant and integrator referral fees.

I am open to further conversation about this issue and would be delighted to begin implementation if no concerns and/or objections are raised.

[daisy1754]

sounds reasonable to me - I'm guessing you would keep version blank if people specify platform name?

[daisy1754]

cc @nirajjayant @dbook13

[dbook13]

Adyen describes the integrator field as "[the] name of your company." Why would we want to use "BoltApp/sleet" as the integrator? Would it make more sense to let the client define this field with an env variable as well?

[jpgnotgif]

@daisy1754 : After performing a few tests using Adyen's Payments API Explorer, it appears that all the fields under externalPlatform are treated as optional. In theory, a client could specify 0 to 3 of the specified values.

@dbook13 Valid point. I will update the issue description accordingly.

I am curious to hear both of your thoughts (and any contributor to this project) around introducing configuration files. I understand that the design intentions are meant to abstract the inner workings of the supported gateways. However, in situations like the one described in this issue, I do see benefits in allowing clients to configure gateway specific metadata.

If configuration files are not an option at this time, I am happy to rely solely on env variables for this issue 👍🏽

[daisy1754]

I am curious to hear both of your thoughts (and any contributor to this project) around introducing configuration files

Each client (eg AdyenClient) has its own NewClient method with different method signatures, so I think it's totally fine to add argument (maybe as a configuration struct) to pass extra configuration parameter that is specific to gateway. My preference order would be strongly typed config struct (most preferable) > env var (ok) >> config file (not sure)

[nirajjayant]

Each client (eg AdyenClient) has its own NewClient method with different method signatures, so I think it's totally fine to add argument (maybe as a configuration struct) to pass extra configuration parameter that is specific to gateway

@daisy1754 I agree with this - I think we should be very explicit in determining what the client config is going to be. Env vars and config files do seem a little magical to me, doesnt fit the paradigm