Indication if a card is currently blocked in upcoming expiry webhook
Weavr sends Card notification webhooks to inform you of events related to the upcoming renewal and expiry of a card, so that you can ensure that the desired action takes place upon renewal or expiry: Card expiry and renewal
This includes for cards that are blocked, since the customer may still wish the card to be unblocked and renewed.
The webhook that provides advance reminders of expiring cards now includes detail of the card’s current blocked status.
If a card that is currently blocked is expiring, the End Customer cardholder, via the Embedder, can choose to let the blocked card expire without renewal, or can choose to renew the card and keep it in blocked state until any future action to unblock it. The only exception to this is where the reason a card is blocked is because it is “Lost”, in which case it cannot be renewed: instead, a new card would have been created at the time it was reported lost.
Additional webhook update when tracking is added to dispatched card
Weavr sends a Card notification webhook to inform you of events related to the upgrade of a virtual card to a physical card, including when a card has been dispatched: Card upgrade to physical details
Now, if a tracking code is received from our fulfilment centre after the original dispatched webhook, Weavr will send you an additional “Card upgrade to physical details” message with the manufacturingState still in DISPATCHED and containing the deliveryTrackingCode.
End-customer businesses (i.e. Corporates) often have to perform certain actions in bulk or batches. Weavr has inbuilt support for operations in bulk, currently available in Beta, that can be managed as part of a Bulk Process for (and authorised by) a specific Corporate Identity.
Weavr has added three new operations related to the management of Cards that can be performed in bulk:
Improvements to the Incoming Wire Transfer simulator
Developers and QA engineers in your team can use our simulator features to test various payment actions, including Incoming Wire Transfers (IWTs). In the simulator area of the Embedder Portal (in Sandbox mode) we provide screens to simulate the receipt of an IWT - i.e. a wire transfer payment from an external source to an internal Managed Account.
2024.12.05
We have now enhanced the simulations to reflect more real-world details about how these transactions are processed in Weavr programmes, in particular to construct the details of a simulated IWT in the different available payment rails of SEPA, [UK] Faster Payments, and SWIFT.
As shown above, testers can simulate IWTs with specific sender information. (Which IWT methods are actually available in production depends on the scope of each embedded finance programme.)
Because IWTs are treated differently in UK programmes, we will also provide for simulating the following:
IWTs to Linked Accounts (i.e. self-to-self account funding). The screening of IWTs on Card-Focused programmes where a GBP IWT will be accepted if its from a Linked Account but rejected if it is not from a Linked Account.
It is also possible to simulate an IWT using Account ID. This is a quick and easy way to put funds on a Managed Account, that you may need for testing elsewhere. This method skips some of the steps when processing IWTs.
Note: IWT simulation features are also available via our Simulator API. If your engineering/QA team need support with either the GUI or API-based Simulator, we will be happy to support you via the normal channels.
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.
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.
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.
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
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.
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
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.
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.
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.
Onboarding flows for all new end customers will change to require an updated method of recording agreement to financial institution terms and conditions (FI T&Cs).
All Consumers and all Root Users of Corporates will now be shown the following screen when onboarding:
FI T&Cs agreement screen: web UI component version
FI T&Cs agreement screen: mobile version
This enables us to record the agreement of the End Customer to the FI T&Cs directly, as well as automatically update the version of T&Cs if they are revised in future. T&Cs updates will be communicated in advance in each case.
This FI T&Cs agreement screen is implemented automatically in the standard embedded onboarding flows, prior to the Customer Due Diligence steps (e.g. identity verification and proof of address) in the rest of the process.
Live programmes will need to ensure that they remove any older T&Cs agreement steps from their own sign up flows (i.e. to remove duplication of a step) as soon as feasible. Embedders should still ensure the correct versions of the T&Cs documents are available to the End Customer to find easily via their application, support docs etc.
Existing End Customers on live programmes will not be affected (since they already agreed to terms and conditions when they signed up, and were sent any subsequent changes).
Updated/moved Micro-enterprise declaration in KYB onboarding
As well as the above new T&Cs step for all onboarding flows, we will now require a clearer Micro-enterprise declaration, which we are adding into the KYB onboarding:
Micro-enterprise declaration in KYB onboarding steps
As shown, the Root User of the Corporate needs to answer the two questions and then agree to the declaration about whether the Corporate is or is not considered a Micro-enterprise.
This replaces the previous question in the KYB questionnaire, and these changes take place automatically.
Existing End Customers on live programmes will not have to take any action directly. If our records show that a Corporate’s profile is unclear about their Micro-enterprise status, we will follow up with the Embedder’s team about how to refresh KYB profiles in this respect.
Changes relating to wire transfers functionality in UK programmes
From 7 Oct 2024, new regulations come into force in the UK regarding the fraud compensation rights of retail customers using Faster Payment System payments, known in the industry as “push payments”, and hence the regulations relate to “authorised push payment fraud” or APP Fraud.
All UK programmes now choose a general payment model that takes into account changes to risk from APP Fraud regulations, and as part of these changes we are also implementing new features to be able to exclude “self-to-self” payments from the scope of future fraud claims.
These APP Fraud related changes do not affect EU/EEA programmes.
UK programme choices under new APP Fraud compensation regime
UK programmes will now be classified into three distinct approaches in terms of how APP Fraud risks are mitigated.
Cards-Focused programmes
End Customers will not be able to send or receive Faster Payment System wire transfers except “self-to-self” to/from Linked Accounts, i.e. for the purpose of funding accounts for cards usage, and withdrawing any surplus balance.
Cards and Wire Transfers programmes
End Customers will continue to take advantage of GBP OWTs to third parties and IWTs from third parties via the Faster Payment System, but within new boundaries and features designed to control risk.
Wire Transfers Focused programmes
The Embedded Payment Run solution operates without cards and requires mitigations of APP Fraud risk: details for relevant programmes are available in separate release notes.
For (1) Cards-Focused programmes, changes must be made to implement Linked Accounts (see below) and remove any previous functionality and UI/UX material relating to third party OWTs and IWTs.
For (2) Cards and Wire Transfers programmes, changes include implementing new steps in OWT flows, optionally making use of Linked Accounts features, and establishing a working position with regard to real-time screening of IWTs.
All live UK programmes will receive more detailed guidance to assist with change management.
Linked Accounts are a new feature available initially for UK programmes only.
Linked Accounts are a representation of an End Customer’s own external accounts (such as a Corporate’s business bank account) which they register and verify in our systems. This means we can treat Incoming Wire Transfers from the external account as a “self-to-self” funding transaction, and any Outgoing Wire Transfer back out to that account as a “self-to-self” withdrawal.
These transactions are then not in scope of APP Fraud claims, ensuring that a [UK] Cards-Focused programme can operate without exposure to risk from general third-party wire transfer flows. In the case of [UK] Cards and Wire Transfer programmes, Linked Accounts can optionally be used to reduce risk by differentiating clearly between “self-to-self” flows and other third-party payments.
In summary:
Both Consumer and Corporate End Customers on UK programmes can use Linked Accounts
Using Linked Accounts is mandatory on UK Cards-Focused programmes
Using Linked Accounts is optional on UK Cards & Wire Transfers programmes
Linked Accounts are not yet available for EU/EUR/SEPA programmes
Existing End Customers on live UK Cards-Focused programmes will need to set up at least one Linked Account to be able to continue funding their payments (and withdrawing surplus funds if they desire). Weavr will assist live Embedders with this setup process for existing customers.
We are offering the following new feature initially only for UK Cards and Wire Transfers programmes. In these programmes Embedders have opted to continue offering features that allow End Customers to receive Faster Payment System [GBP] IWTs from third parties. Therefore, both the End Customer and the Embedder are exposed to risk due to the possibility of external payers being retail customers who create a claim against a transaction with their (third-party / external) payer’s PSP.
On a beta basis we are working with affected programmes to put in place a real-time decisioning system so that the Embedder’s business can selectively decide on a per-transaction basis whether to allow an End Customer to accept a [GBP FPS] IWT.
We will discuss implementation details on a programme basis.
This feature is not available for Embedders on UK Cards-Focused programmes, although we use our own real-time decisioning in a similar way to reject IWTs which are not from external sources previously verified as Linked Accounts.
The feature does not currently apply to EU/EEA programmes and [EUR] SEPA payments.
Changed requirements for UK FPS OWT creation to include Confirmation of Payee
We are offering the following new mandatory change for UK Cards and Wire Transfers programmes, i.e. where End Customers are offered workflows to create [GBP FPS] OWTs to third-party payees.
Affected programmes will need to make changes to the UX and logic of their OWT workflow to incorporate a Confirmation of Payee check, and ensure the results are displayed intelligibly to the End Customer, so they can decide whether to proceed with the payment (or amend or cancel it).
This new OWT flow splits the API calls so that the Weavr system can provide the CoP check result and await a confirmation from the end customer’s decision to proceed, which is followed by the SCA challenge.
This implementation of Confirmation of Payee must be ready for End Customers to use (as the only OWT flow available for GBP FPS) by 31 October 2024.
We will support Embedders making changes in live programmes to ensure the implementation is compliant and well-designed for end users to understand.
Please note Confirmation of Payee does not apply to EU/EEA programmes and [EUR] SEPA payments, but a similar solution (Verification of Payee) will come into force in the second half of 2025.
Recommended implementation of withdrawal OWTs to Linked Accounts
As noted above, UK Cards-Focused programmes will not be able to offer OWTs to End Customers except as “self-to-self” withdrawals to external accounts registered and verified as Linked Accounts. Applications in these programmes should not offer End Customers information or UX flows related to making OWTs to third parties.
Live UK programmes which previously offered OWT functionality and are now deprecating it should offer a revised UX flow for an End Customer creating a withdrawal transaction. The End Customer should be able to select one of their Linked Accounts as the payee, without being asked to edit the payee details.
Please contact us for specific documentation on the API and UX flow logic of withdrawal OWTs to Linked Accounts.
