clearhaus / clearhaus/3DSv2-api-documentation

Co-branded cards

Open
#15 3 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.