Appearance
SCA Wallet life cycle
Locking
When you suspect that an SCA Wallet or device may have been compromised, you should lock the SCA Wallet and provide a reason for doing so.
Locking is a sensitive action, so users must be strongly authenticated before proceeding.
bash
curl -X PUT {baseUrl}/core-connect/sca/scawallets/{scaWalletId}/lock \
--header 'Authorization: Bearer {accessToken}' \
--header 'Content-Type: application/json' \
-d '{payload}'
1
2
3
4
2
3
4
Here is an example of {payload}
:
json
{
"lockReason":"LOST_DEVICE", // see list below
"lockMessage":"string" // optional, max 256 characters
}
1
2
3
4
2
3
4
Returns a 200
HTTP Status Code and the updated SCA Wallet object.
On the SDK, this triggers the WalletEventListener#onWalletLocked()
event.
Unlocking
If an SCA Wallet has been locked by one of your Support Users and after the legitimacy of the device has been reestablished, you may unlock it using the following request.
This is a sensitive action that can be done by:
- Your Support Users, with two-factor authentication, or
- The end user, if they provide a per-operation SCA proof.
bash
curl -X PUT {baseUrl}/core-connect/sca/scawallets/{scaWalletId}/unlock \
--header 'Authorization: Bearer {accessToken}' \
--header 'Content-Type: application/json'
1
2
3
2
3
Answers with a 200
HTTP Status Code and the updated SCA Wallet object.
Unlocking the SCA Wallet also triggers the WalletEventListener#onWalletUnlocked()
event on the SDK.
Deletion
A user using a single device should have a single SCA Wallet. The SCA Wallets of your users should be monitored as to avoid multiple or inactive SCA Wallets for a unique end user.
SCA Wallets should be deleted when:
- They haven't been used in a long time and probably can't be trusted anymore,
- The user declared their device stolen/lost,
- The user gets a new device that replaces the old one,
- Your commercial relationship with the user ends.
Alert – Automatic deletion
Treezor automatically deletes SCA Wallets that have been inactive for 6 months. An SCA Wallet is considered inactive if the last SCA Proof is older than 6 months.
The following request can be used to delete an SCA Wallet, including by the end user if they provide a per-operation SCA proof.
bash
curl -X DELETE {baseUrl}/core-connect/sca/scawallets/{scaWalletId} \
--header 'Authorization: Bearer {accessToken}' \
1
2
2
Answers with a 200
HTTP Status Code and the updated SCA Wallet object.
Deleting an SCA Wallet triggers the WalletEventListener#onWalletDeleted()
event on the SDK.
Reset PIN (Mobile)
SCA Wallets are protected by PIN codes on end user devices. Resetting PIN codes is only available to you and your support users, this is not an action that can be exposed to your end users.
To reset a PIN code, you can use the following request.
bash
curl -X PUT {baseUrl}/core-connect/sca/scawallets/{scaWalletId}/resetPin \
--header 'Authorization: Bearer {accessToken}' \
--header 'Content-Type: application/json'
1
2
3
2
3
Returns a 200
HTTP Status Code and the updated SCA Wallet object.
On the SDK, this triggers the WalletEventListener#onCustomerCredentialsReset()
event.
The end user is now able to define a new PIN from their device.
Passcode change (Web Native)
This is considered a sensitive action, so users must be strongly authenticated before setting a new passcode. There are two use cases depending on whether the user knows their current passcode:
- With SCA proof – If the user knows their current passcode.
- With 2-factor authentication – If the user doesn't know their current passcode.
Tip – Passcode is shared between devices
Contrary to device-specific SDK passcodes, the passcode used with Web Native is not tied to the device passkeys and technically not used to access the passkeys. Therefore, the passcode is not device-specific; if a User has multiple Web Native devices enrolled, a single and unique passcode is used for all of them.
With SCA proof
If your user already knows their passcodes, use the following request with a delegated_end_user
JWT.
bash
curl -X PUT {baseUrl}/core-connect/sca/setPasscode \
--header 'Authorization: Bearer {accessToken}' \
--header 'Content-Type: application/json' \
-d '{payload}'
1
2
3
4
2
3
4
Here is an example of {payload}
:
json
{
"userId": "123456",
"newPasscode": "",
"confirmPasscode": "",
"sca": "{scaProof}"
}
1
2
3
4
5
6
2
3
4
5
6
Answers with 204 Accepted
HTTP status code.
With 2-factor authentication
If your user don't know their passcodes, use the following request with a client_credentials
JWT while ensuring the user is who they claim to be with relevant information as necessary, such as:
- Their birthdate, email address, mobile phone number
- A one-time-password that you sent to their email address
- A one-time-password that you sent to their mobile phone
If enough conditions are met, you may contact Treezor endpoint for the user to set their new passcode with the following request.
bash
curl -X PUT {baseUrl}/core-connect/sca/setPasscode \
--header 'Authorization: Bearer {accessToken}' \
--header 'Content-Type: application/json' \
-d '{payload}'
1
2
3
4
2
3
4
Here is an example of {payload}
:
json
{
"userId": "123456",
"newPasscode": "",
"confirmPasscode": "",
"authMethod":["OTP SMS", "OTP EMAIL", "ID", "OTHER"], // List methods used to ensure the user's identity
}
1
2
3
4
5
6
2
3
4
5
6
Answers with 204 Accepted
HTTP status code.