Improvement to the create password endpoint#

The credentialType and identityType fields are no longer required to create a password. The user for whom you are creating the password will be identified by the userId path parameter. Affected endpoint:

• POST /multi/passwords/{user_id}/create

Improvement to the managed account and managed cards webhooks#

The card or account holder represented by the owner field has been added to the following webhook endpoints:

• POST /managed_accounts/deposits/watch
• POST /managed_cards/authorisations/watch
• POST /managed_cards/settlements/watch
• POST /managed_cards/adjustments/watch

Introducing the new Weavr Multi v3 API#

Over the last few months, we have been working hard to improve the Weavr Multi API. Your feedback has been instrumental in this, and we are excited to launch the new version - the Weavr Multi API v3. This new version is not only simpler, but will also better cater to your growing needs.

You can have a look at the new API docs and accompanying guides here.

Defining the API using RESTful guidelines#

V3 embraces the OpenAPI specification and uses different HTTP methods to represent CRUD (Create, Read, Update, Delete) operations. You can use publicly available code generators to reduce repetitive work.

Decoupling IBANs from Accounts#

Managed accounts may, or may not, have IBANs - you and your customers choose what works best. Managed accounts represent pots of funds and can be used to segregate money based on your customers’ needs.

This will help your customers have more control over their funds, and help improve reconciliation. An IBAN can be optionally assigned to a managed account via the API whenever required.

Consumer identities now support multiple users#

We have generalised the concept of authorised users, which was previously only supported for Corporate identities. Now, Consumer identities can also invite users to their account.

This new feature unlocks a whole new range of models, as Consumers can now share their account with another user or family member. One example of this in practice, is a parent/ child linked account. In this instance, a parent can extend a card or account to their child while keeping control of how and where it is being used.

Get Started#

You can start using the new Weavr Multi v3 API, today. Your Sandbox API Keys will work with both versions of the API.

We will continue to support the current version of the API, so you can rest assured that there will be no disruption to service. However, we do encourage you to have a look at the new version, along with the features we have launched, and will be launching in the coming months.

Eventually, the Weavr Multi v2 API will be phased out. However, we will give you plenty of advance notice before this happens, and will be on hand to support you along the way. We will communicate the process and deprecation dates, in future updates.

New occupation types for consumer identities#

When creating an identity, you need to specify the occupation of the root user who owns the consumer identity. We added 2 new occupations to the list, PR_MARKETING and MANUFACTURING. API endpoints affected:

• POST /consumers/_/create
• POST /consumers/{id}/get
• POST /consumers/{id}/update

New error code when verifying an already verified mobile number#

As part of the due diligence process, root users are required to verify their mobile number.

The API endpoint POST /corporates/{id}/users/mobile/send_verification_code will return a 409 - Conflict error with code ALREADY_VERIFIED if you trigger the send verification code on an already verified mobile number.

New error code when initiating a send or transfer transaction#

The destinationAmount.amount should always be a positive number. If a negative number is provided, a 409 - Conflict error with code INVALID_AMOUNT. API endpoints affected:

• POST /transfers/_/execute
• POST /send/_/execute

Due Diligence limits are now deprecated#

This is part of a larger initiative in which we are upgrading our risk management systems to cater for the growing number of transactions flowing through Weavr. The allowedLimits and remainingLimits have been deprecated and will be removed in future releases. API endpoints affected:

• POST /consumers/{id}/kyc/get
• POST /corporates/{id}/kyb/get

Instead of monitoring your customers’ restrictions via limits, you will be able to access this information in the transaction details whenever a transaction or an identity is flagged for investigation. More details on how this will work will be provided later on.

Personalisation of physical card PINs#

As a result of customer reports encountering declined purchases when a card PIN is updated after being dispatched, we have decided to deprecate the set PIN feature. Instead the card PIN can only be personalised when upgrading a virtual card to a physical card.

A new optional field named pin has been added to the /managed_cards/{id}/physical/upgrade POST API endpoint which can be used to specify a personalised PIN. If this field is not included in the request, a random PIN will be assigned to the card.

The /managed_cards/{id}/physical/pin/set POST API endpoint is now deprecated and will be removed in an upcoming release.

More descriptive purchase decline reasons#

We have updated the authorisations webhook /managed_cards/authorisations/watch to include a comprehensive list of decline reasons.

New KYB temporary failure reasons#

The KYB webhook /corporates/kyb/watch now includes a new details parameter. The new optional parameter contains the reasons why the corporate identity has temporarily failed it’s KYB. Such information can help the corporate solve any problems with the documents or information they provided.

Resend expired end-user invites from the Portal#

We added the ability for you to resend end-user invites from the Portal in case their original invite expired before they completed their registration. The resend invite capability can be found in the end-user details screen.

Re-introducing mandatory corporate details#

When creating a corporate you will be required to specify the following fields:

• companyName
• companyRegistrationNumber
• registrationCountry

API ChangeLog#

## Removing due diligence deprecated fields possibly breaking In previous releases, a number of fields where made deprecated as they where being replaced with other fields which provide additional information on the due diligence of your corporate and consumer customers.

For Corporate KYB the following fields have now been removed: verifications, kyb.allowedLimit and kyb.remainingLimit. The affected APIs are:

• POST /corporates/{id}/get
• POST /corporates/{id}/update
• POST /corporates/_/create
• POST /corporates/{id}/kyb/get

For Consumers KYC the following fields have now been removed kyc.pep, kyc.sanctioned, kyc.enhancedDueDiligence, kyc.allowedLimit, kyc.remainingLimit.The affected APIs are:

• POST /consumers/{id}/get
• POST /consumers/{id}/update
• POST /consumers/_/create
• POST /consumers/{id}/kyc/get

## Deprecating due diligence fields non-breaking We are simplifying further the due diligence information returned to you via the API. This helps you in understanding the status of the KYC or KYB for consumers or corporates respectively.

For Corporates the kyb.enhancedCompanyChecksVerified field has been deprecated. We recommend that you use the kyb.fullCompanyChecksVerified field to get the due diligence status of your corporate.

For Consumers the kyc.fullDueDiligenceAddressMatched field has been deprecated. We recommend that you use the kyc.fullDueDiligence field to get the due diligence status of your consumer.

API ChangeLog#

Additional validation for the call-ref parameter#

When calling any of the APIs offered by Weavr, you can optionally specify a value for the call-ref parameter. If we receive 2 API requests with the same call-ref value, the request will only be executed once. This avoids executing requests multiple times by mistake.

The call-ref parameter has been restricted to a maximum of 255 characters. If a longer call-ref is provided an error 400 - Bad Request will be returned.

API ChangeLog#

Updating the delivery address of a physical card#

We introduced the ability to update the delivery address of a managed card. This feature is particularly useful if the user using a physical card has moved to a different address and you want to make sure that they receive their card at the right address.

You can only update the delivery address for physical cards. If the delivery address is specified when updating a virtual card, the API will return a 409 - Conflict error with error code INSTRUMENT_NOT_PHYSICAL.

New error codes when managing physical cards#

You cannot activate, retrieve or update the pin of a blocked or destroyed physical card. When executing the following APIs on a blocked or destroyed card, the API will return a 409 - Conflict error with error code INSTRUMENT_BLOCKED or INSTRUMENT_DESTROYED:

• POST /managed_cards/{id}/physical/activate/
• POST /managed_cards/{id}/physical/pin/unblock
• POST /managed_cards/{id}/physical/pin/get
• POST /managed_cards/{id}/physical/pin/set

New error code when updating the details of a consumer#

A new error code EMAIL_NOT_UNIQUE has been added to the POST /consumers/{id}/update API. This error code will be returned if the new email address being specified is already being used by another consumer in your community.

API ChangeLog#

Re-branding our build environment#

You may have already noticed changes in the documentation and in our communication, we are renaming our build environment to sandbox. The re-branded sandbox environment will have the same features and capabilities we already offer in the build environment.

Update to the physical card upgrade process#

You can only upgrade virtual cards to physical cards if their state is ACTIVE. If the card being upgraded is currently BLOCKED the POST /managed_cards/{id}/physical/upgrade API call will return a 409 - Conflict error with error code INSTRUMENT_BLOCKED.

More descriptive error codes for the transfer transaction#

We have introduced 2 new error codes SOURCE_INSTRUMENT_BLOCKED and DESTINATION_INSTRUMENT_BLOCKED that replace the current error code ACCOUNT_BLOCKED. With these new error codes you can provide more informative messages to your customers and give better options on how to perform the transfer transaction.

API ChangeLog#