clearhaus / clearhaus/3DSv2-api-documentation
Co-branded cards
- Dominant language
- HTML
- Stars
- 5
- Forks
- 3
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 1
Description
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
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.