Skip to main content

Version 3.44

· 2 min read
Dragos Tigoianu

Enhanced API Key management

Embedders now have the flexibility of managing and rotating API keys, ensuring secure usage and storage. These options are conveniently accessible on the API Credentials page, within the Embedder portal.

This enhancement introduces three new options for managing API Keys:

  • Creating additional API Keys: Create multiple API keys to support various use cases and enhance security measures. To create a new key, Embedders should navigate to the API Keys tab and click "Add New API Key".
  • Rotating between keys: Easily switch between different API keys, ensuring secure usage. Embedders can click to reveal and copy the key provided within the API Keys tab.
  • Deactivating an API key: In the event of security concerns or changes in access requirements, Embedders can deactivate API keys as needed. Once deactivated, an API key cannot be reactivated.

WEB

Alternative Step-up via fallback SMS channel

Embedders may use different channels for stepping-up a token: SMS, Twilio Authy or Biometrics. In situations where users encounter difficulties accessing Twilio Authy for authentication, Embedders can now initiate the SMS channel as a fallback. This ensures that users still receive the verification code and can successfully confirm the challenge.

Enhanced User Verification Indicators

To prevent confusion in interpreting user verification statuses, the verification indicators now feature new, distinct, and recognisable colours corresponding to their respective statuses:

  • Upon creating a new user, the email and mobile verification indicators will now appear grey instead of red.
  • When a new user starts verifying the email or mobile, the verification indicators will be displayed yellow, not red.
  • Upon successful verification of the email or mobile, the verification status will continue to be indicated in green.

Enhanced Data Insights Dashboard

To ensure Embedders can closely monitor the progress and operations of their customers, the Data Insights Dashboard has been enriched with the following information:

  1. The details table within the KYC Overview dashboard includes a new Rejection Comment column, showing the reason why a consumer failed a KYC submission.
  2. The Card Settlements and Fees Details dashboards now include new filtering options:
  • a. Managed Card ID, Merchant Name and Merchant Category Code filters, within the Card Settlements dashboard
  • b. Instrument Friendly Name, Card Last 4 Digits, Merchant Category and Merchant Category Code (where applicable), within the Fees Details dashboard.

Version 3.43

· 3 min read
Dragos Tigoianu

Enhanced Webhook Logs Filters and PII Data Masking

We previously released a view of Webhook Logs within the Embedder Portal. While it was possible to search and browse, users also asked to be able to filter the list view.

We have now added filters to the Webhook Logs page so Embedder Portal users can filter the list to view items by date, identity, instrument, event type, and status.

These filters can be combined, offering an easy and powerful way to locate and review webhook event history.

Note we mask sensitive Personally Identifiable Information (PII) in Webhook Logs in the same way we do in API webhook responses. Data masked includes: name, surname, email, and payment beneficiary (except for friendly name on Managed Accounts and merchant name on purchases, which are not considered PII).

WEB

Showing KYC rejection reason for temporarily rejected consumers

We would like to inform you about the upcoming enhancements to our consumer Know Your Customer (KYC) status information within our Embedder Portal.

We are providing you with additional information to understand why the KYC application has been rejected and what additional information the consumer needs to provide in order to continue the KYC process.

With this update, if the consumer KYC status is temporarily rejected the existing KYC state indicator tooltip will show further information.

These enhancements will be automatically presented on the Embedder Portal, and are designed to offer you greater visibility of your customers KYC progress, whilst enabling your teams to better guide and support your consumer customers.

WEB

Mobile Number Invalid Input API Response Refinement

Previously if a mobile phone number sent via API call during user registration/enrolment was invalid according to the API specification, Weavr would only return a 500 (exception) error. This response has been refined to return 409 - Mobile_Number_Invalid.

Note that Embedders are currently responsible for validating user input on telephone country codes (i.e. ITU-T standard international subscriber dialing (ISD) code). We are planning a future change to enforce validation on the Weavr API side. Further information on this future change will be provided in due course.

Affected APIs:

  • POST multi/corporates
  • POST multi/consumers

API Validation:


Version 3.42.1

· 3 min read
Dragos Tigoianu

Changing of Mobile Verification and OTP SMS Sender ID

UK regulatory authorities are taking measures to reduce the number of deceptive text messages that encourage individuals to share personal or financial information, click on malicious links, or download harmful software or applications.

Consequently, they are implementing restrictions on SMS Sender IDs (the sender's name displayed in the SMS) used within the United Kingdom (UK) containing specific characters. Sender IDs with common, generic names, such as AUTHCODE and AUTHSMS, will no longer be supported, and this change will come into effect by the end of this month.

In response to this regulation change, from Monday, 30th October 2023, we will update the SMS Sender ID of Mobile Verification and One Time Passcode (OTP) messages to reflect your programme’s name. We will contact you within the next few days to confirm the new Sender IDs. If you choose not to use your programme name, the default Sender ID will be WEAVR.

It is important to note that the current 3-D Secure (3DS) SMS Sender ID is WEAVR and we are actively working to align this SMS with those used for Mobile Verification and OTP purposes.

There is no required action for you to take in connection with this change; however, we do recommend sharing this information on the different SMS Sender ID with your customers ahead of the change taking place.

Webhook Logs Page Improvements

We have recently significantly improved our Webhook Logs page in the Embedder Portal to enhance your user experience and provide you with more valuable insights regarding your webhooks.

You will notice that we included an additional column in the Webhook Logs table and refined the column headings. We improved the page by refining the structure in which the logs are presented. We included a new Event Type column that categorises different Operations, making it easier to identify and understand your logs.

These changes lay the groundwork for upcoming enhancements to our search capabilities. Soon, you will have the ability to filter logs by Event Type and more, making it effortless to find the exact information you need.

WEB

These enhancements are designed to streamline your experience, and you will automatically see these changes in the Embedder Portal.

Password Complexity Information

We have made notable improvements to the Weavr Authentication page found within the Settings menu in the Embedder Portal.

If your application utilises our Password component, we have now added concise details regarding the configured password complexity level required for authentication. The Password Complexity information on this page offers specific guidelines on the complexity level.

WEB

This information dynamically adjusts based on your configured password complexity level and you will find it automatically visible in the Embedder Portal.

Data Insights Dashboards Enhancements

We are continuously working on improving the functionality within Data Insights to allow you to analyse and understand your data better. As part of this release, we have worked on enhancing our dashboards by introducing the following details:

  1. We have enhanced the Fees Details dashboard by introducing the Owner ID field within the details table. This field helps in outlining the owner to which the fee was charged. Additionally, it is also now possible to filter on the Owner ID via the filters accessible from this dashboard.

  2. We have also updated the details table within the Managed Account Incoming Transfers dashboard by including a new IBAN(s) column, allowing you to view IBANs related to the pertaining managed account.


Version 3.42.0

· 2 min read
Dragos Tigoianu

Improvement in identifying Beneficiaries

We have implemented a fresh approach to identifying beneficiaries. You now have the flexibility to allocate your custom reference to a beneficiary, which can be later used to access beneficiary details, including the identifier, beneficiaryId, necessary for initiating payment instructions.

You can now access your custom reference, externalRefs in the following methods:

  • POST multi/beneficiaries
  • GET multi/beneficiaries
  • GET /multi/beneficiaries/\{{beneficiary_id\}\}

Improvement to email address validation during Corporate onboarding

In the past, Corporate Root Users who attempted to sign up for an account but didn't complete the process because their email address wasn't validated, would encounter an error if they tried again later. This error indicated that the email address was already in use, leaving the user with the option to either use a different email or abandon the sign up process altogether.

To enhance ease of use, we are now enabling users to proceed with a new registration even if their email address was previously awaiting validation from a prior attempt.

Recall that the Weavr Multi API will return error number 409 with the message:

  • ROOT_EMAIL_NOT_UNIQUE, if the email the corporate root user attempted has already been validated or is waiting to be validated within the last 60 minutes
  • VERIFICATION_CODE_INVALID, if the corporate root user attempts to validate the email address more than 60 minutes after it was sent

Physical Cards Overview Dashboard Enhancement

As mentioned in our latest communication, physical cards can now be delivered in bulk either for yourself or your customers.

We have enhanced the details panel within the Data Insights section of the Physical Cards Overview dashboard to facilitate the display of bulk-delivered cards. This enhancement is designed to provide you with a more comprehensive view of all physically delivered cards that were dispatched in bulk.


Version 3.41.0

· 3 min read
Dragos Tigoianu

Accepting apostrophes/single quotes in Email Addresses

You can now start using apostrophes (‘) and single quotes (‘) when registering new email addresses. This enhancement guarantees a more accurate representation of your customer's email addresses during registration.

The affected Multi Product APIs are:

  • POST/users
  • PATCH/users
  • POST/passwords/lost_password
  • POST/login_with_password

Improvements to the downloadable PDF Statement for Accounts and Card transactions

We have updated the downloadable PDF Statements to show the filtered date range, along with the starting and closing balances corresponding to that specific period. This enhancement ensures that the PDF statements are comprehensive and suitable for internal reconciliation, audits, and various other purposes.

Beyond Account transactions, you can now also download PDF statements for your card transactions.

Delivery of Cards in Bulk

We are now offering the convenience of bulk card delivery, allowing you to receive up to 200 cards in a single package, either for yourself or your customers.

To initiate a bulk delivery request, simply set the bulkDelivery parameter to True and include the contactNumber field in your call. The deliveryAddress parameter must be exactly the same for all the cards marked for bulk delivery.

The delivery methods that support bulk delivery are COURIER with a maximum of 200 cards delivered at once, and REGISTERED_MAIL with a maximum of 90 cards delivered at once.

Physical Cards are dispatched from our supplier twice weekly at 08:00 GMT on Monday and Thursday mornings. Requests received in between these cut-offs (and marked as bulkDelivery) will be packaged into a single bulk delivery.

The affected Multi Product APIs are:

  • POST/managed_cards
  • PATCH/managed_cards/\{id\}
  • POST/managed_cards/\{id\}/physical
  • GET/managed_cards
  • GET/managed_cards/\{id\}
  • POST/managed_cards/\{id\}/physical/replace_damaged
  • POST/managed_cards/\{id\}/physical/replace_lost_stolen

Processing deposits improvements

To avoid confusion, and misunderstandings regarding the availability of funds for a deposit that is being processed, or held for review, we are simplifying the way that we notify you.

Currently, in the case where a deposit is received but held for further checks, or action is required from the end-customer in the form of a Source of Funds (SOF) declaration, we add the amount to the actualBalance of the account and show the transaction as PENDING in the activity statement on the portal. These two events will no longer occur. We will however continue to reach out to you if a SOF declaration is required, via the existing channels. Once any review has been completed successfully, the funds will show in the availableBalance on the account and in the activity statement (as happens today).

Deposits that are being processed, but held for review, can be seen in the deposits dashboard of Data Insights, with state UNDER_REVIEW.