Merchant country code data in card authorisations and settlements​

Following your valuable feedback, we are continuously enhancing our webhooks to provide Embedder programme managers and administrators with additional webhook data.

As part of our continuous efforts to refine our webhook events, we have included the merchant country code in two specific webhook operations relating to card purchases. The two operations are:

• /managed_cards/authorisations/watch
• /managed_cards/settlements/watch

We are currently providing you with the merchant details that include the category code (merchantCategoryCode), merchant name (merchantName) and ID (merchantId). With this release you will start receiving the merchant country code (merchantCountryCode) for the two specific webhook events.

With this additional information you can gain more insights into understanding in which countries transactions are being performed, whether domestic or international.

Webhook logs default to recent first​

We understand the importance of accessibility and efficiency when it comes to monitoring your webhook events and for this reason, we have restructured the Webhook Logs page within our Embedder Portal to provide you as the Embedder programme manager or administrator with a better user experience.

We restructured the list of webhook events to be presented in descending order, with the latest created event displayed first. Webhook events will be automatically displayed in descending order, presenting the latest created event first.

Webhook when an IWT is rejected​

If an incoming wire transfer is rejected, an Managed Accounts / Account Deposit webhook will be sent with state : REJECTED.

IWTs can be rejected for various reasons: account closed, account blocked, risk-based limits, SOF declaration not provided or inadequate.

Automatic webhook retries for extra error scenarios​

Webhooks are sent via POST to the Embedder's application’s webhook endpoint URL specified in the Embedder Portal (under the Application Details section).

If the Embedder's server responds to a webhook POST with a 5xx error, signifying that there was an issue with receiving the event, the webhooks are retried automatically.

This feature is being expanded to include automatic webhook retries for 408, 409, and 425 status codes.

The webhook is retried 5 times starting with an initial delay of 10 seconds, and incrementing with a delay factor of 6, signifying:

• Failure on the first attempt will be retried after 10 seconds
• Failure on the second attempt will be retried after 60 seconds
• Failure on third attempt will be retried after 360 seconds
• Retrying up to 5 times

This improvement increases the likelihood for Embedders to successfully receive all webhook events, even when errors occur, thereby enhancing reconciliation and ensuring data integrity.

Optional Activation Code during the physical card activation process​

Previously, when upgrading a virtual card to a physical card, it was mandatory to provide an activation code to activate the card. This process is now being simplified by removing the activation code requirement and making it optional instead.

The old activation code flow is still supported but Embedders can now take advantage of a simpler method: a cardholder who receives the physical card simply needs to be logged in and then a card activation can be initiated through the Embedder’s application, for example through an activation button.

The endpoints impacted are:

• POST /managed_cards/{id}/physical
• POST /managed_cards/{id}/physical/activate

If an activation code is provided when activating a card, it will still be validated against the activation code set when upgrading the card. Any mismatch will trigger the existing 409 error, specifically ACTIVATION_CODE_INVALID. However, if no code is provided, the card will be activated, and a 200 success generated.

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.

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.

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.

Please 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).

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.

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.

Please 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:

• Corporate
• Consumers

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.

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.

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.