Migration

The SCA migration process is continuous. As Users are migrated to an SCA capable ecosystem, you will have to:

• Use and enforce the SCA features to migrated Users.
• Allow your non-migrated Users to still use your services (for a maximum duration defined jointly with Treezor).

The process below details a possible migration path.

Assumed starting point

Let's assume that your existing userbase consists of 4 Users who have been onboarded before the release of the SCA feature.

These users are missing the following:

• Updated app – The version of your app don't implement the SCA SDK.
• SCA Wallets – They don't have an SCA Wallet yet.
• Enrolled Cards – Their payment cards are not enrolled for SCA use yet.

You Users database could look something like this:

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	0	0	0	0
2	0	0	0	0
3	0	0	0	0
4	0	0	0	0

This table is deliberately simplified for the example purposes. Your implementation should be more refined as to track dates, individually enrolled Cards, multiple SCA Wallets (multiple devices), etc.

Release an SCA-capable version of your App

The first step is to update your App to embed and implement the SDK or the abstraction layer.

When a user downloads the new version of your App which implements the SCA SDK, your App should contact your back end and tag the User accordingly.

Let's consider that User 1 has updated their app. Your app has contacted your back end and updated the User.

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	1	0	0	0
2	0	0	0	0
3	0	0	0	0
4	0	0	0	0

Periodically revive Users who haven't updated their App

Using your back end database (has_sca_capable_app = 0), you are able to periodically revive Users who still have not downloaded and updated their mobile App.

Let's consider that User 2 has updated their App following one of your mailings or push notifications.

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	1	0	0	0
2	1	0	0	0
3	0	0	0	0
4	0	0	0	0

Create SCA Wallets for capable Users

As soon as Users have an SCA capable App (has_sca_capable_app = 1) and no SCA Wallet (has_sca_wallet = 0), you should create their SCA Wallet.

Let's consider that you have done so for Users 1 and 2.

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	1	1	0	0
2	1	1	0	0
3	0	0	0	0
4	0	0	0	0

Track new Users and SCA Wallet creation

Keep in mind that new Users (created after the activation of the SCA feature in your Production environment) will have SCA Wallets automatically created.

You should watch the scawallet.create webhook to keep track of SCA Wallet creations.

Let's consider that during your user-base migration, one new User (5) has registered and has had their SCA Wallet automatically created.

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	1	1	0	0
2	1	1	0	0
3	0	0	0	0
4	0	0	0	0
5	1	1	0	0

Provision SCA Wallets

As soon as Users have SCA Wallets created (either automatically or manually), you should follow the provisioning procedure to enable their SCA Wallet.

Let's consider that you have completed the provisioning for Users 1, 2 and 5.

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	1	1	1	0
2	1	1	1	0
3	0	0	0	0
4	0	0	0	0
5	1	1	1	0

Note – Requests are made in the name of the User

• Users 1, 2, 5 are authenticated using a dedicated JWT for each User, obtained using an SCA Proof.
• Users 3 and 4 still use the usual authentication procedure, with a single shared JWT.

Enroll User's Cards

As soon as Users have a provisioned SCA Wallet (has_provisioned_sca_wallet = 1), you should enroll their Cards.

Let's consider that you have enrolled Cards for Users 1, 2 and 5.

user_id	has_sca_capable_app	has_sca_wallet	has_provisioned_sca_wallet	has_sca_enrolled_cards
1	1	1	1	1
2	1	1	1	1
3	0	0	0	0
4	0	0	0	0
5	1	1	1	1

At this stage, Card transactions for Users:

• 1, 2, 5 will require the completion of an SCA.
• 3 and 4 will still be subject to the usual OTP (One Time Password).

Finished migration

You should regularly revive Users who have not yet updated their App until they can reach the stage where they have:

• An SCA-capable App
• An SCA Wallet
• Activated the SCA Wallet
• Enrolled their Cards

Ideally you should have migrated your entire userbase before the allowed timeframe imposes that all requests to the Treezor API to use SCA features.