56 posts tagged with "Multi-v3"

Improved handling for locked user credentials​

User credentials can be temporarily locked due to consecutive failed login attempts. If a user credentials becomes locked, the login API endpoint will now start returning HTTP error code 403 - Locked.

Affected endpoint:

• POST /multi/login_with_password

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

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\}

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

New manufacturing status details for physical cards​

A new manufacturingState field has been added to the managedCard.physicalCardDetails object to improve traceability of the fulfilment 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