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
and4
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
and4
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.