Co-branded cards

[kse-clearhaus]

We are adding the Danish national card schemes Dankort and Forbrugsforeningen to our EMVCo 3DS offering at 3dsecure.io. These involve Visa/Dankort co-branded cards. To support co-branded cards, we need to modify our public API. My initial requirements are:

a. Avoid breaking existing implementations as much as possible b. Avoid forcing integrators to make decisions about cobranded cards unless they need them c. Make it as elegant as possible

Supporting Dankort/Brugsforeningen cards boils down to two things:

1. Delivering the correct CRD to the requestor
2. Sending the received AReq to the correct Directory server

Options for preauth

These are the possible scenarios I can envision for preauth: A reasonable assumption here is that the integrator knows which card scheme they want to do authentication with.

1. Modify to return a list of CRD responses
   • Would break existing integrations
2. Add a separate endpoint using either URL, accept headers or something else, that will lead to a list being returned
   • Does not look elegant
3. Require a scheme input to /preauth to determine which CRD the integrator is interested in
   • We could have an initial period where no scheme input was required
   • Forces all integrators to actively consider what scheme they are using
4. Partially require a scheme input to /preauth, but only for co-branded cards. If no scheme input is present with a Visa/Dankort, the prefer the Visa part
   • This preference would avoid breaking current integrations and avoid integrators not supporting dankort to consider this
   • This could make e.g. NETS feel like they're being ranked behind Visa. This is of course not a matter of preference, but of keeping backwards compatibility

Options for auth

These are the possible scenarios I can envision for auth:

1. Require a scheme element in the AReq
   • Rather simple
2. Carry over scheme from preauth
   • This would cause problems for 3RI/APP, where preauth is not a requirement
3. Either carry over scheme from preauth or use the passed scheme parameter.
   • A bit more complex, since preauth isn't mandatory with 3RI or APP device channels
   • Would likely only be optional for BRW device channel

[ct-clearhaus]

Regarding preauth: With versioning, (1) would be just fine. Introduce a new version that returns a list, deprecate the old version, leave some time, remove the old version and 🥳. I think this is quite elegant and simple. Practicing this procedure early isn't bad at all; the client should likely get used to updates nonetheless — because that'll surely come over the coming months/years.

Regarding auth: Again, I vote for the simplest option, namely (1).

[dvaeversted]

From our perspective, we would prefer:

preauth option 4, we always know if it is the Dankort side of a cobranded card we are going to use prior to running the 3DS.

auth either option 2 or 3, would make it much simpler in our integration not having to provide this value twice.

[kse-clearhaus]

I am currently leaning towards

preauth: 4,3,2,1

auth: 3,1,2

WRT CT:

Regarding preauth: With versioning, (1) would be just fine. Introduce a new version that returns a list, deprecate the old version, leave some time, remove the old version and . I think this is quite elegant and simple.

I'm not convinced that this is elegant and simple.

1. The process is going to be quite involved and enforcing it is going to take a while. Force everyone to move to a temporary API while deprecating the old Replacing the old API with the new one Remove the temporary API Also: It forces changes
2. The return value would have to be a list, the question is then where the threeDSServerTransID should go.
3. It does not allow us to cache the selected Directory Server from the preauth call, so we don't have to do the same lookup in the auth call. Based on the fact that we want to verify that a acctNumber reaches a valid DS.

Practicing this procedure early isn't bad at all; the client should likely get used to updates nonetheless — because that'll surely come over the coming months/years.

Yeah. I'm hoping we can avoid as many breaking changes as possible :) Though I agree that we are early on and creating a breaking change is better now than later.

Regarding auth: Again, I vote for the simplest option, namely (1).

l agree that it's simple. Though if we adopt preauth: 4, 3, then we can reuse the cache lookup saved Directory Server. It would also be nice that we wouldn't have to force integrators to adapt. Skipping an enforcement period.