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
