Skip to main content

Onboard an Authorized User

Authorized usersAuthorized User An individual that has been invited by the root user to manage an identity's instruments and transactions. They are not the legal owner of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorized Users. US-English variant of _Authorised User_. are users who have been granted access to a buyerBuyer A business entity in the Payment Run solution that can be provided with financial services to perform embedded payment runs. Buyers are onboarded through a KYB process and can create payment runs to pay their suppliers. They have roles such as Admin, Controller, and Creator. 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 respective buyerBuyer A business entity in the Payment Run solution that can be provided with financial services to perform embedded payment runs. Buyers are onboarded through a KYB process and can create payment runs to pay their suppliers. They have roles such as Admin, Controller, and Creator..

For a buyerBuyer A business entity in the Payment Run solution that can be provided with financial services to perform embedded payment runs. Buyers are onboarded through a KYB process and can create payment runs to pay their suppliers. They have roles such as Admin, Controller, and Creator. persona, an authorized userAuthorized User An individual that has been invited by the root user to manage an identity's instruments and transactions. They are not the legal owner of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorized Users. US-English variant of _Authorised User_. can represent a company role from the payables department, a financial controller, a procurement officer, a treasury role or an external accountant.

Depending on how your application can be utilized, the assigned authorized usersAuthorized User An individual that has been invited by the root user to manage an identity's instruments and transactions. They are not the legal owner of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorized Users. US-English variant of _Authorised User_. can be users of the application that are intersecting with the financial service component to perform payments using the selected payment methods or to perform payment receipt reconciliation.

pre-requisites

Before you can add authorized usersAuthorized User An individual that has been invited by the root user to manage an identity's instruments and transactions. They are not the legal owner of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorized Users. US-English variant of _Authorised User_. to a BuyerBuyer A business entity in the Payment Run solution that can be provided with financial services to perform embedded payment runs. Buyers are onboarded through a KYB process and can create payment runs to pay their suppliers. They have roles such as Admin, Controller, and Creator., you must have:

This guide demonstrates how you can enable your customers to add users with roles to their identity in the following steps:

  1. Create a new user
  2. Set the user's password
  3. Enroll the user's device

1. Create a new user​​

Use the create user API to create a new user associated with the buyerBuyer A business entity in the Payment Run solution that can be provided with financial services to perform embedded payment runs. Buyers are onboarded through a KYB process and can create payment runs to pay their suppliers. They have roles such as Admin, Controller, and Creator. that the logged-in user initiating the request belongs to.

note

Learn more about roles and permissions here.

POST/usersTry it

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}/Try it
NON-PCI COMPLIANT INNOVATORS

If you are not PCI compliant, you cannot handle your customers’ plain-text passwords. Instead, you must tokenizeTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. 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.

Via the user invitation process​​

If you still need to onboard the user onto your product, you can use the invitation process to start this process. The invitation process is a 2 step process:

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

2.1. Send an invitation email to the user​

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

POST/users/{user_id}/inviteTry it
EMAIL BRANDING

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

The invitation email contains a verification code and a URL that redirects to your application. Once the user clicks this URL, they are redirected to a page on your application where they can input the verification code they received.

info

The invitation expires after 30 days.

2.2. User accepts invitation and provides their password​

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}/consumeTry it

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 one additional authentication factor to perform 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

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