56 posts tagged with "Multi-v3"

New Data Insights​

We provide Embedders with data reports and dashboards in the Embedder Portal, collectively referred to as Data Insights. With this release we’re launching a significant wave of improvements and additions across Data Insights.

Key changes include:

• dashboards have a fresh new look, with charts split across focused tabs; tabs have different purposes, including an overview, analytical tabs and more detailed tabs with transactional information

• all charts within Data Insights (except for KPIs and tables) now offer an interactive drill-down functionality, allowing Embedder staff a way to see a detailed view of a particular bar/segment

• an informational tooltip has been introduced within each chart, providing definitions and granularity details pertaining to that chart

• filters have been enhanced to offer a drop-down menu, making it easier to find what you are searching for

• improvements to performance

Detailed documentation around Data Insights is now available within the knowledge base section of the Weavr support portal here. This is also linked via the Help button within the Embedder Portal.

We’d like to hear your feedback about Data Insights. Speak with your Weavr contacts to share your ideas.

Data Insights enhancement - reporting on Authorisations in mobile wallets​

We have introduced a new Authorisation Details tab within the XPay Enabled Cards dashboard (formerly known as the Apple Pay/Google Pay Overview dashboard).

This new tab will help Embedder programme operations and support staff identify whether a card payment Authorisation has been done with a card that is provisioned in Apple Pay or Google Pay mobile wallets. The detailed view includes various details such as merchant details, device details, and instrument amounts.

New error message if new Step-Up is retried too fast after initial attempt​

We are always looking to improve the error messages returned by the Weavr APIs. Within the Step-Up flow, if the Embedder’s application attempts to start a new Step-Up for a user before the first one has been completed or timed out, we have replaced the error “400 Invalid_request” with the more specific “409 Retry_in_15sec”.

The flow works like this:

• Embedder’s application calls Weavr API to start Step-Up flow
• Weavr awaits a response showing the user has not completed the challenge
• Before any response it received, the Embedder’s application begins a new Step-Up attempt within 15 seconds of the first
• This results in the error “409 Retry_in_15sec”

If a new Step-Up is started after 15 seconds from the first attempt, then the first attempt will be invalidated and the user will need to respond to the new challenge.

In general, Embedders must provide reasonable times for users to complete multifactor authentication challenges and not make repeat requests on the API for Step-Up in a short space of time.

New error message for a step-up called twice​

We have improved the response for the scenario when the Step-up verify endpoint was called twice. If by mistake, you were calling twice the Verify endpoint for the same token that has been already stepped-up, we returned error State_invalid. In order to become more clear on the situation, for the above scenario we are changing the error from State_invalid to Already_verified. More details on step-up authentication is available here.

Ensuring emails are unique in your programme​

In some programmes, Embedders have encountered problems when legacy sign up flows allowed the same email to be used for a Consumer Identity at the same time as a Corporate Identity. In these types of programme we are now enforcing that the email address of a user has to be unique at the programme level.

Custom tags for Authorised Users​

Authorised Users can multiply in programmes with lots of cardholders. As an Embedder you’ll want to manage interactions and data around Authorised Users, so we’ve introduced an optional tag field which allows you to store custom information against those records.

The Authorised User Tag can be included in API calls as follows:

• POST/users
• GET/users
• PATCH/users{user_id}

The tag is available when filtering Authorised Users in the Embedder Portal:

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.

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.

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