8 posts tagged with "Embedder Portal"

Enhancements within data insights physical cards dashboard​

We have rolled out enhancements to the Physical Cards Data Insights dashboard, aimed at improving visibility into card stock levels and delivery operations. Within the Analysis tab, you can now find:

A new Stock Availability chart, providing a clear view of current inventory levels, including the consumed percentage of available cards to give you an immediate insight into stock usage trends; A new Physical Card Orders chart, displaying all physical card orders placed over the last 12 months, along with the associated delivery addresses and tracking numbers, offering a detailed look at distribution patterns and fulfilment activity These updates are part of our ongoing commitment to delivering sharper, actionable insights and streamlining operational management within the platform.

Bulk Processes in embedder portal​

It is now possible to view current and historic Bulk Processes in the embedder portal.

Currently you can track the progress of the operations in a Bulk Process via the multi API, and via webhooks. We have now added full visibility in the embedder portal.

Here you can view all Bulk Processes, their status', and the underlying operation that was performed. You can see a summary of the underlying operations, for example whether all operations were executed successfully, via the side-panel.

You can click on a Bulk Process to see the full API details of each underlying operation; helpful for investigating or troubleshooting any issues.

Marking virtual cards as compromised​

We have introduced a new feature that allows you to mark a virtual card as compromised directly from the embedder portal. With just a click, you’ll have the option to:

Mark the card as compromised and issue a replacement–Automatically destroys the affected card and generates a new one.

Mark the card as compromised and transfer funds–Move the remaining balance to another instrument linked to the same identity.

Mark the card as compromised without replacement–Destroys the affected card without issuing a new one or transferring funds.

This enhancement provides more control and flexibility when managing compromised virtual cards.

Handle more MCCs and MIDs in spend rules​

When creating or updating spend rules in our Embedder Portal and Multi, you can now add up to 200 allowed or disallowed MIDs and MCCs.

API details​

• POST /multi/managed_cards/{id}/spend_rules

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

• PATCH /multi/managed_cards/{id}/spend_rules

Biometrics and UI components, mobile SDK releases​

The Weavr mobile SDK for iOS, Android, and React Native platforms allows you to embed financial services into your own app, providing a seamless experience for your customers.

Recent improvements introduced in the Biometrics and UI components include:

• The Biometric Authentication component now supports the initial authentication, and fallback authentication, of the end user via password, rather than only passcode.
• The React Native SDK has been updated to support React Native's new architecture, and leverages the Expo-modules API to simplify maintenance.

Manage spend limits on debit-mode cards in the user's own currency​

Weavr is enhancing its debit card offering by introducing the ability to configure spend limits in a secondary currency—different from the card's assigned currency, known as the userCurrency.

Cardholders will be able to view their card balance and set spend limits in their designated userCurrency, providing greater flexibility and transparency in managing expenses.

Please note that once a card is created, its assigned userCurrency cannot be changed.

Key points​

• Feature is optional

• You need to contact your account manager or Weavr support team to enable this feature

• For each card profile you can choose to enable all supported user currencies or a subset

JPY, BGN, CZK, DKK, HUF, PLN, RON, SEK, CHF, ISK, NOK, TRY, AUD, BRL, CAD, CNY, HKD, IDR, ILS, INR, KRW, MXN, MYR, NZD, PHP, SGD, THB, ZAR

Consider a UK-based company with employees located in Sweden. If the company enables SEK (Swedish Krona) as a userCurrency, it can assign this secondary currency when issuing cards to Swedish employees. It’s important to note that specifying a userCurrency does not alter the underlying card’s issuing currency with our banking partners. The card’s primary currency remains unchanged, and all card statements will continue to be reported in the original issuing currency.

API details​

• POST /managed_cards

• GET /managed_cards/{id}

• GET /managed_cards

• POST /managed_cards/{id}/spend_rules

• PATCH /managed_cards/{id}/spend_rules

• GET /managed_cards/{id}statement

Further details are available in our product documentation here

Webhook details​

• /managed_cards/authorisations/watch

• /managed_cards/settlements/watch

Enhanced physical-card tracking information​

via API​

We have added a new field, detailsDeliveryTrackingUrl, to the multi and back-office Get Card API endpoints. When available, this field provides a direct link to the courier's tracking information page for the physical card delivery, allowing you to monitor the delivery status of a physical card in real time.

• GET multi/managed_cards/{id}

• GET multi/backoffice/managed_cards/{id}

via Embedder portal​

Where possible, the same detail has been added to the embedder portal, making it easier to access the courier's tracking information with a single click, that takes you directly to the courier’s tracking page, making it easier to monitor delivery status and updates in real time.

Functionality to set custom start date for a spend limit interval​

We’ve enhanced our spend rule creation capabilities to give you more flexibility when setting spending limits for physical and virtual debit mode cards.

Card owners (corporate root or authorised users) can now customise the start date for spend limits based on the selected interval—whether it's weekly, monthly, quarterly, or yearly.

For example, you can now set a yearly spend limit that starts on May 1 2025 and ends on May 1 2026.

This gives you more control in aligning spend limits with your financial planning cycles.

This update is on multi and back-office.

API details​

• POST /multi/managed_cards/{id}/spend_rules

• PATCH /multi/managed_cards/{id}/spend_rules

• PATCH /multi/bulks/managed_cards/_id_/spend_rules

• POST multi/backoffice/managed_cards/{id}/spend_rules

• PATCH /multi/backoffice/managed_cards/{id}/spend_rules

• PATCH /multi/backoffice/bulks/managed_cards/_id_/spend_rules

AuthorisationCategory field in APIs and Authorisation Webhooks​

We’ve introduced a new field called AuthorisationCategory in our card statement APIs and authorisation webhooks. This field helps you distinguish whether a card authorisation is a pre-authorisation or a final authorisation. AuthorisationCategory will support

• PRE_AUTH Indicates a pre-authorisation, commonly used for reserving funds (e.g., hotels, rentals).

• FINAL_AUTH Indicates a final authorisation, typically representing the actual transaction amount.

This new field allows for better control and visibility over transaction flows. You can:

• Accurately track the lifecycle of a payment

• Differentiate between temporary holds and completed payments

• Improve reconciliation and customer communication

API details​

• GET /multi/managed_cards/{id}/statement

• GET /multi/backoffice/managed_cards/{id}/statement

Webhooks​

• /managed_cards_authorisations_watch

More efficient statement retrieval​

We have made improvements to our statement retrieval process (for cards and accounts). Previously, due to API limitations, statement data was provided in pages of 100 items, sometimes requiring multiple requests for complete information.

We have now increased the maximum number of items per page to 500. This enhancement will streamline the process of retrieving your statement data.

To benefit from the increased limits, specify your desired limit in the limit parameter when making a GET request to the statement API. Or contact your account manager to configure an appropriate default limit.

Key Points​

If no specific limit is requested, the system will default to 100 items or a limit that has been agreed with your account manager (maximum of 500) .

If the statements request includes a period before April 1, 2025 , the maximum limit of 100 will still apply.

If the limit specified in the API request is higher than the configured limit , the limit will internally fall back to the configured limit.

API Details​

• GET /multi/managed_accounts/{id}/statement

• GET/multi/managed_cards/{id}/statement

We believe these updates will significantly improve your experience in accessing and managing your card and account statements.

Linked Accounts - further details for End Customer support​

Embedder staff can find a list of all of a (Corporate) End Customer’s Linked Accounts in the Embedder Portal. In this interface we have added to the information panel to include the sort code and account number of the external account, to be used by Embedder staff for supporting End Customers with any queries.

We have also added a new data dashboard in the Embedder Portal to support the review and analysis of Linked Accounts. This shows Embedder staff key metrics to help with proactive troubleshooting of End Customer Linked Account setup processes:

The Linked Accounts data dashboard also features a funnel chart that visualises the Linked Account setup journey, showing the various steps which have to be completed.

Additionally, we have updated the SCA Events dashboard to include Linked Account IDs within the Details table for more comprehensive tracking.

You can find out more about Linked Accounts in our documentation here.

Data insights on Micro-enterprises​

Programmes onboarding and servicing UK Corporates are required to track whether the End Customer business is a Micro-enterprise. We have added a new filter and charts to the Corporates data insights dashboard in the Embedder Portal to help Embedder staff manage Micro-enterprises in their programme, if applicable.

Filter Managed Cards by renewal type​

Weavr offers two options in regards to renewal when a card reaches expiry: RENEW and NO_RENEW. For more information see the Card Renewals section in our documentation.

We have added renewalType as an option on the GET Managed Cards endpoint to allow you to filter the results by cards that are set to either RENEW or NO_RENEW.

Effected endpoint: GET /managed_cards

Webhooks for more granular KYC/KYB status changes​

We have enhanced existing webhook functionality for tracking KYC and KYB process states to include webhooks when additional information is required at a certain step, so that the application cannot proceed until something is added or revised.

Weavr will now send webhooks at all of these stages: initiation, pending review, temporary rejection (indicated by an ‘Initiated’ status), and approval or rejection.

In the details passed with the webhook, we may supply a rejection reason (e.g. CorporateKybFailureReason - see API documentation) and there may be a customer-specific message from the support agent.

Affected webhooks:

• Corporate KYB status update
• Corporate beneficiary status update (NB 'beneficiary' here relates to UBOs in the KYB process)
• Consumer KYC status update

Prevention of duplicate Consumer Identity creation​

We are strengthening controls to ensure that an individual can only be added once per programme, when creating a Consumer Identity.

If an attempt is made by the Embedder to create a new Consumer, and Weavr considers it’s a probable duplicate within that programme, we will reject with a new error code 409 CONSUMER_ALREADY_EXISTS

Two-step login flow for Embedder Portal​

We have updated the login flow for the Weavr Embedder Portal to ask for the user’s email to be submitted first, and then the password in a second step.

Weavr Embedder Portal production first login screen 2024 10 This is part of the rollout of single-sign-on (SSO) for the Embedder Portal: if this is of interest in your programme, please contact your Account Manager or Support.

This applies only to the production instance of the Embedder Portal, not to the Sandbox instance.

Track physical payment card fulfilment status via webhooks​

We are introducing a new webhook event to help Embedder systems track End Customer card orders and thus convey status changes around the fulfilment to the End Customers.

We recommend proactively keeping End Customer users updated, such as an employee due to receive a card, and a manager who placed the order for the employee to receive a card.

Please review the API documentation for this feature here: https://weavr-webhooks-api.redoc.ly/#operation/managed_cards_physical_cards_upgrade_watch

Webhooks are sent for each fulfilment status change (in the API known as the manufacturingState), as follows:

• REQUESTED: Fulfilment of a physical card order has started.
• SENT_FOR_FULFILLMENT: Printing and packaging is in progress.
• DISPATCHED: The card is in the postal or courier system.
• DELIVERED: The card has been activated.

If webhooks are enabled and configured, Embedder operational and support staff can review recent webhook events in the Embedder Portal via the Webhook Logs page:

Payment card expiry details added in Embedder Portal​

In a previous release [https://docs.weavr.io/blog/2024/02/27/v3.48/#new-feature-payment-card-renewals], Weavr added features to facilitate automatic renewal of expiring payment cards.

To help Embedder programme operations teams support End Customers with their payment cards, we’ve added renewal information to the Managed Cards dashboard in the Data Insights section of the Embedder Portal.

The following details are now shown as columns in the report tables:

• Expiry Date - indicating when a Managed Card is set to expire;
• Next Renewal Date - indicating when an automatic renewal process would commence, if it is set to renew.

Cards which are set NO_RENEW will still have a “Next Renewal Date”, which can be understood as the deadline for being able to change its setting to RENEW, and get the card renewal processed before the expiry date. This “Next Renewal Date” will therefore be ignored if the card remains set to NO_RENEW, and not auto-renewing is also the default if renewalType is not specified.

For more information please see the card renewals documentation.

New method of indicating assignment of a payment card​

When a business (Corporate) assigns a payment card to an End User, typically an employee, this assignment is recorded at the time the card is created.

Previously we’ve used the the linkedUserId field within the threeDSecureAuthConfig object when creating a Managed Card [https://weavr-multi-api.redoc.ly/3.55.0/tag/Managed-Cards/#operation/managedCardCreate].

We are planning to deprecate this use of linkedUserId and replace it with a new method of indicating assignment of a payment card as described below.

(Note: within the same threeDSecureAuthConfig object we have already marked the field cardholderMobileNumber as deprecated.)

We now recommend using the new field userId to identify which End User (typically an Authorised User) a card is assigned to at creation.

Going forward this will be the supported way of noting the card assignment for purposes including:

• 3DS checks
• Mobile wallet provisioning

Please start using this method when creating new cards. We will communicate the deadline for deprecation of the previous linkedUserId field, and migration of existing assignments, in future release notes.

List view of registered Linked Accounts​

Last month we introduced new features and policies to ensure all UK-based programmes are ready for the new regulatory regime relating to APP Fraud. [https://docs.weavr.io/blog/2024/09/18/v3.54.0/#changes-relating-to-wire-transfers-functionality-in-uk-programmes]

All End Customers in UK-based programmes can take advantage of the new Linked Accounts feature [https://docs.weavr.io/blog/2024/09/18/v3.54.0/#introducing-linked-accounts], and it is required for End Customers to have at least one Linked Account active within UK Cards-Focused programmes.

Embedder operations and support teams can now view information about Linked Accounts in the Embedder Portal, as a new tab in Corporates page (where this is applicable to the programme):

Please reach out to Weavr for support on any aspects of the Linked Accounts feature, or to support End Customers with getting successfully set up.

Linked Account process API field change​

In UK Cards-Focused programmes, End Customers need to set up at least one Linked Account to be able to fund their Managed Account(s).

One of the setup steps is a declaration of ownership via SCA-style challenge [https://docs.weavr.io/instruments/linked-accounts/linked-accounts-verifications/#declaration-of-ownership-via-sca-challenge].

We have changed an enum in “Get Linked Account verifications” [https://weavr-multi-api.redoc.ly/3.55.0/tag/Linked-Accounts/#operation/linkedAccountVerificationsGet] from "ROOT_USER_DECLARATION_SCA_CHALLENGE" to "USER_DECLARATION_SCA_CHALLENGE"

Please ensure you are referring to the current API documentation when implementing this new feature.

Bulk operations management API fields change​

In previous release notes we announced Bulk API processing capabilities available on a Beta basis [https://docs.weavr.io/blog/2024/07/01/v3.51.0/#new-bulk-processing-capabilities-in-the-multi-api].

If you are working with the ‘GET all operations in a bulk’ endpoint please note we have made changes to the names and descriptions of fields in the operations array. Please review the documentation here: https://weavr-multi-api.redoc.ly/3.55.0/tag/Manage#operation/bulkIdOperations

merchantData object in card authorisations and settlements​

In January 2024, we updated the webhook events for Card Authorisations and Settlements to include the merchantCountryCode. With this release, we are further improving these webhook events by adding the merchantData object, which is already included in the Authorisation Forwarding webhook event:

The addition of the merchantData object will result in some fields being duplicated in the webhook payload. As a result, the original fields now included in the merchantData object have been marked for deprecation and will eventually be permanently removed:

We will inform you well in advance before the above deprecated fields are permanently removed and will form part of a breaking change release.

Cut-off times for physical payment card orders​

Physical payment card orders are put through for fulfilment twice a week on Monday and Thursday. From a cut-off time previously 0800 GMT/BST this is now updated to 0445 GMT/BST to ensure new card orders are not put through too late for work to begin on that day.

For any details of card ordering and fulfilment on your programme, please speak to your Customer Support contact.

Self-service Embedder Portal user management​

Primary administrators of Embedder product/operations teams can now add, temporarily deactivate and reactivate, and remove additional users for the Embedder Portal via a “Manage Users” screen. Please login to the Portal to test. This feature is available via the Portal UI only, not via API.

Please note “delete” does not actually delete a user, it just permanently deactivates that user credential.

Form for manually requesting change of Corporate details​

When a Corporate changes any of its business details we require the Root User to confirm the changes in a form submitted via a support ticket. This ensures any changes are authorised as well as ensuring that the Corporate’s KYB information is kept up to date with Paynetics.

Examples of changes include:

• Business name
• Business registered address
• Main phone number
• Main contact details
• Domain name used in email / allow-listed domains

If any of these details change at any time, a form submission is required.

If the Corporate wishes to change the Root User’s details or switch the Root User role to a different director/appointee then the same form should be used.

Some supporting documents are required along with the form in each case.

The End Customer should initiate a request to change Corporate details via the Embedder’s application UI or simply via front-line customer support. To request the form and get help filling it in, please open a support ticket on behalf of the End Customer.