Skip to main content

Onboard an authorized user

Authorized Users are users who have been granted access to an identity within Weavr. They are not the legal owners of the identity therefore they do not own the instrumentsInstrument A financial product owned by an Identity. There are two types: Managed Accounts (stored-value accounts that hold balances and can receive wire transfers) and Managed Cards (prepaid cards — virtual or physical — used for purchases). or the funds created for the identity.

Authenticated authorized users can perform operations on the identity and its instrumentsInstrument A financial product owned by an Identity. There are two types: Managed Accounts (stored-value accounts that hold balances and can receive wire transfers) and Managed Cards (prepaid cards — virtual or physical — used for purchases)., via the Weavr API and SDKs. The specific operations available to each user depend on the roles assigned to them.

If you are running a program where corporatesCorporates Business entities that can be onboarded as identities on Weavr. Corporate identities represent companies and require Know Your Business (KYB) verification. They can have multiple authorised users and issue cards to card assignees. issue cards, the card user must be created as an Authorized User and linked to the card before it can be used.

tip

We provide a set of pre-configured roles that can be assigned to users to control their level of access. Read the user roles section to find the most suitable role for each user.

This guide demonstrates how you can enable your customers to add users to their identity.

1. Create a new user​

Use the create user API to create a new user associated with the identity that the logged-in user initiating the request belongs to.

In order to Create an Authorized User, the logged-in user requires a stepped-up token. Before calling the Create User endpoint, you need to step-up (issue and complete a challenge). More details on how to step-up a token can be found here

POST/usersTry it 
{
  "name": "string",
  "surname": "string",
  "email": "user@example.com",
  "mobile": {
    "countryCode": "stri",
    "number": "string"
  },
  "dateOfBirth": {
    "year": 1900,
    "month": 1,
    "day": 1
  },
  "tag": "string"
}

When creating an Authorized User, you must provide some basic personal information about the user since they have access to conduct financial operations. Although fields such as mobile and dateOfBirth are optional when calling the API, if the Authorized User is intended to be assigned a card, this information becomes mandatory before they can use a card.

We return the details of the newly created user, including the id which is used to identify this particular user in subsequent API calls.

2. Set the user's password​

Once a user is created, the next step is for the user to set up his/her password. You can set the user's password in 2 ways:

  • Via the Create Password API, if the user is already using your product
  • Via the User Invitation process, if the user still needs to start using your product

Via the create password API​

If the user is already using your product, you can use this option to quickly enable them to setup their password.

POST/passwords/{user_id}/createTry it 
{
  "password": {
    "value": "pa$$word"
  }
}
Non-PCI compliant innovators

If you are not PCI compliant, you cannot handle your customers’ plain-text passwords. Instead, you must tokenize passwords. Find more information on how to transmit data securely here.

We return a token as part of a successful response. Provide the token as part of APIs which require the user to be logged in.

Authorized users can multiply in programs with lots of card assigneesCard Assignee The person that a card is assigned to and who will use the card. For consumers, the card owner and card assignee are the same person. For corporates, the card assignee and card owner are different entities - the corporate is the card owner and the person using the card is the card assignee. Card assignees must be created as Authorised Users.. As an embedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. you may want to manage interactions and data around authorized users. An optional tag field allows you to store custom information against those records.

The Authorized User Tag can be included in API calls as follows:

  • POST/users
  • GET/users
  • PATCH/user/{user_id}

The Tag is also available when filtering Authorized Users in the Embedder PortalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each..

Via the user invitation process​

If you still need to onboard the user onto your product, you can use the invitation method to start this process. The invitation process has 2 steps:

  1. Send an invitation email to the user.
  2. User accepts invitation and provides their password.

Use the send user invite API to send the invitation to the user on their email address.

POST/users/{user_id}/inviteTry it 
{
  "code": "string",
  "message": "string"
}
Email branding

You can brand and personalize the email content that is sent to your users. Read our guides on corporate email communications and consumer email communications for more information.

The invitation email sent to the user includes a URL that redirects to your application. You must create a page in your application to which this URL points. On this page, you must allow the consumer to input the verification code they received in the email.

info

The invitation expires after 30 days.

Set the user's password by submitting the verification code that the user received in the email together with the user's password.

POST/users/{user_id}/invite/consumeTry it 
{
  "inviteCode": "string",
  "password": {
    "value": "pa$$word"
  }
}

We return a token as part of a successful response. Provide the token as part of APIs which require the user to be logged in.

3. Enroll the user's device​

Users must be enrolled with at least one additional authentication factor to perform step-up authentication for operations that require Strong Customer Authentication (SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).).

3.1 Enroll user using OTP via SMS​

You can start the enrollment process using the API. The user receives a text message (SMS) on the mobile number provided when creating the user.

POST/authentication_factors/otp/{channel}Try it 
{
  "code": "string",
  "message": "string"
}

Verify the user's mobile device​

You must build a page in your application where the user can enter the verification code that they received in the text message together with their password. Then, you need to submit the information using the API.

POST/authentication_factors/otp/{channel}/verifyTry it 
{
  "verificationCode": "string"
}

3.2 Enroll a user for biometric authentication​

If you have a mobile app, we offer an embeddable Biometrics Authentication component as an SDK. The enrolled authentication method is used instead of SMS once enrollment is complete. Enrollment for biometrics is initiated directly from the SDK, see enrolling a device for details.

tip

The enrollment flow includes an SMS OTP that also automatically enrolls SMS as an authentication factor for the user, avoiding having to complete step 3.1 separately.