Skip to main content

· One min read

New feature to reset the contactless limit of wearable physical cards

From time to time, customers using wearable physical cards, are required to input their PIN to confirm point of sale transactions. To eliminate the need to have to input their PIN, they can reset the contactless limit associated with their wearable device.

You can enable your customers to reset their contactless limit for their wearable physical cards via a new API.

Affected APIs:

  • POST /multi/managed_cards/{id}/physical/contactless_limit/reset

· One min read

New optional date of birth field for users

We added a new optional dateOfBirth field to authorised users and corporate root users. This field is only required if you are onboarding teenagers onto your product.

Affected endpoints are:

  • POST /multi/users
  • PATCH /multi/users/{id}
  • GET /multi/users
  • GET /multi/users/{id}
  • POST /multi/corporates
  • PATCH /multi/corporates/{id}
  • GET /multi/corporates
  • GET /multi/corporates{id}

· One min read

Updated the validation for the source instrument of an outgoing wire transfer

The sourceInstrument.id and sourceInstrument.type properties are new both required when submitting an outgoing wire transfer

Affected APIs:

  • GET /multi/outgoing_wire_transfers
  • GET /multi/outgoing_wire_transfers/{id}
  • POST /multi/outgoing_wire_transfers

New error code when submitting an outgoing wire transfer with a destroyed source instrument

The source instrument of an outgoing wire transfer must be active to execute the transaction. If the instrument is destroyed the API will return a 409 - Conflict error with error code SOURCE_INSTRUMENT_DESTROYED.

Affected APIs:

  • POST /multi/outgoing_wire_transfers

· 2 min read

New manufacturing status details for physical cards

A new manufacturingState field has been added to the managedCard.physicalCardDetails object to improve traceability of the fulfillment of physical cards.

The following are the supported manufacturing statuses:

  • REQUESTED: The physical card has been requested.
  • SENT_FOR_FULFILLMENT: The card has been sent for printing.
  • DISPATCHED: The card has been manufactured and dispatched.
  • DELIVERED: The card has been received and activated by the recipient.

The following endpoints return the 'ManagedCard' in their response, and will now start including this optional detail in case of physical cards:

  • GET /multi/managed_cards post
  • GET /multi/managed_cards/{id}
  • PATCH /multi/managed_cards/{id}
  • POST /multi/managed_cards/assign
  • POST /multi/managed_cards/{id}/physical
  • POST /multi/managed_cards/{id}/physical/activate
  • POST /multi/managed_cards/{id}/physical/replace_lost_stolen

You can also view the manufacturing state of a physical card in the Multi Portal by accessing the card’s detail screen.

Card spend limits can now be applied to a time interval

You can now set spend limits for different time intervals to better control the usage of debit mode cards.

In addition to the ALWAYS interval, we have added the following intervals:

  • DAILY: starting from 00:00:00 UTC of current day to 23:59:59 UTC of current day
  • WEEKLY: 00:00:00 UTC Monday of current week to following Sunday 23:59:59 UTC
  • MONTHLY: 1st of current calendar month to end of current calendar month
  • QUARTERLY: starting from beginning of current quarter where quarters are defined as follows
    • 1 January 00:00:00 UTC to 31 March 23:59:59 UTC
    • 1 April 00:00:00 UTC to 30 Jun 23:59:59 UTC
    • 1 July 00:00:00 UTC to 30 September 23:59:59 UTC
    • 1 October 00:00:00 UTC to 31 December 23:59:59 UTC
  • YEARLY: 1 January 00:00:00 UTC of current calendar year to 31 December 23:59:59 UTC of current calendar year

Affected APIs:

  • PUT /multi/managed_cards/{id}/spend_rules
  • GET /multi/managed_cards/{id}/spend_rules

· One min read

New required fields when creating a Consumer Identity

When creating a consumer you will need to start providing the consumer’s date of birth and the main source of funds type for funds that will be deposited by the consumer via the parameters rootUser.dateOfBirth and sourceOfFunds.

This information is required to complete KYC for the customer and the API endpoint POST /consumers/_/create will return a 400 - Invalid Request error if either of the parameters is not provided.

Affected APIs:

  • POST /multi/consumers

· One min read

New errors codes when consuming a user invite

Authorised users can be onboarded using an invitation process. To accept an invite, the user needs to set a valid password that will be used to login. If the provided password is invalid, the API will return a 409 - Conflict with error codes:

  • PASSWORD_ALREADY_USED
  • PASSWORD_TOO_SHORT
  • PASSWORD_TOO_LONG
  • PASSWORD_TOO_SIMPLE
  • PASSWORD_KEY_ALREADY_IN_USE
  • PASSWORD_ALREADY_CREATED

Affected APIs:

  • POST /multi/users/{user_id}/invite/consume

New error code when transferring or sending funds

The transfers and sends API will return a 409 - Conflict error with error code SOURCE_AND_DESTINATION_MUST_BE_DIFFERENT if the specified source and destination instruments are the same.

Affected APIs:

  • POST /multi/transfers
  • POST /multi/sends

· One min read

New error codes when sending funds to other identities

To send funds, both the source instrument as well as the destination instrument must be active. If one of the instruments is not active the sends API will return a 409 - Conflict error with error codes SOURCE_INSTRUMENT_DESTROYED or DESTINATION_INSTRUMENT_DESTROYED.

Affected APIs:

  • POST /multi/sends

· One min read

New error code when deleting a managed account

Managed accounts which have debit mode cards linked to them, cannot be deleted. The API will return a 409 - Conflict error with error code INSTRUMENT_HAS_LINKED_CARDS if the managed account being deleted has cards linked to it.

Affected APIs:

  • POST /multi/managed_accounts/{id}/remove

New error codes when transferring funds

To transfer funds, both the source instrument as well as the destination instrument must be active. If one of the instruments is not active the transfers API will return a 409 - Conflict error with error codes SOURCE_INSTRUMENT_DESTROYED or DESTINATION_INSTRUMENT_DESTROYED.

Affected APIs:

  • POST /multi/transfers

· One min read

Root user mobile number parameters changed to an object

The mobileCountryCode and mobileNumber fields within the rootUser object are now grouped into a new object named mobile.

Affected APIs:

  • GET /multi/corporates
  • POST /multi/corporates
  • PATCH /multi/corporates
  • GET /multi/consumers
  • POST /multi/consumers
  • PATCH /multi/consumers

New error code when providing an invalid mobile number

A new error code has been added to in case the provided mobile number is not valid. In this case, the API will return a 409 - Conflict error with error code MOBILE_OR_COUNTRY_CODE_INVALID.

Affected APIs:

  • POST /multi/corporates
  • PATCH /multi/corporates
  • POST /multi/consumers
  • PATCH /multi/consumers

· 2 min read

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.