Scheduled Transactions for OWTs and Sends
Weavr Outgoing Wire Transfers (OWTs), sent via UK Faster Payments or EU SEPA, are immediately executed at the time of authorisation by the account holder. However, for business users, particularly finance professionals in B2B accounts payable scenarios, there's demand for being able to approve an OWT to be executed at a defined future date and time.
Using the new Scheduled Transaction feature, OWTs and Sends authorised by account holders can have an optional forward-dated execution time set, and our system will attempt to execute the OWT only at that time (to within 5 minutes).
OWTs and Sends for immediate execution (i.e. how these payments have normally worked up to now) will continue to work as usual if no Scheduled Transaction date/time is set, i.e. this is not a breaking change and if not adopting the Scheduled Transactions features, Embedders do not need to take any action.
When enabling this feature for end users, care should be taken by Embedders to make the behaviour of an instant payment distinct from a future-dated payment. Where the choice is offered, we recommend showing users "Send money now", selected as default, which the user can un-select to reveal a date and time picker. The Scheduled Transaction date and time should then be clearly displayed in the authorisation and confirmation UI as well.
Inline explainers or tooltips should be displayed to the end user to clarify how a Scheduled Transaction works. For example, the Embedder should make it clear it is a single payment not a recurring payment. Furthermore, the end user can cancel scheduled OWTs or Sends any time up to the execution time: the Embedder must provide information about how to do this, and clear navigation to do so in new UI where end users can review pending OWTs.
An important difference between Scheduled Transactions and ordinary immediate OWTs and Sends is that in a Scheduled Transaction, the balance on the account does not need to be sufficient at the time of the authorisation. This allows the account holder to arrange to fund the required balance any time between the authorisation and the execution time. If the balance in the account is not sufficient at the time of execution, the payment will not execute and Weavr will send the appropriate error message via webhook. In this case, the Embedder should deliver this message to the end user e.g. via notifications and link the user back to view the transaction in question. An OWT that failed for this reason cannot be retried but the Embedder is encouraged to design UX that makes it easy to populate a new OWT instruction that copies the details of the original request.
SCA confirmation will be taken from the account holder at the time of authorisation (i.e. this authorisation remains valid until the future scheduled execution, with no separate SCA check before execution).
This feature will be generally available to all embedders and programmes at no additional charge, including both Corporate and Consumer payment contexts. We're adding documentation and portal reporting interfaces as this is rolled out. Please enquire if this is a priority feature for you to integrate into your Embedded Finance Programme.
Webhook Logs in Embedder Portal
The Weavr system provides Embedders with a range of webhooks that were sent through your application. Until now, any queries about the historical data of webhooks, including troubleshooting, were only available to Platform Operators, meaning that Embedders had to enquire via Weavr Support.
To accommodate this new developer tool, we are reorganising the main menu to easily locate the Webhook Logs:
Webhook Logs menu item added to the Embedder Portal
Embedders can now access and review a log of webhooks in the Embedder Portal. The webooks are available through a new menu “Webhook Logs” in the main administration portal. Through this new screen, developers can:
-
Observe a detailed log of sent webhooks;
-
Employ filtering to easily locate webhooks; and
-
Manually replay selected webhooks
Portal users can browse a list of webhooks and manually resend webhooks
The Webhook Logs interface will be available to all Embedder programmes at no extra charge, including the Webhook Resend feature. This new feature will be made available automatically to all Embedders upon release to Sandbox. This is one of the first initiatives to help you work better with webhooks, as we continue to further enhance this feature.
Request and use new SMS OTP in session if first SMS was not delivered
In a current end user login flow with multifactor authentication using SMS OTP, if the user has not received the SMS for any reason, to retry they would have to exit the login flow and start again.
We are updating this flow so that the user can now request one retry, where we send a new SMS OTP (15 seconds or more after the first request), and the user can submit this in the same session - without having to logout and restart the flow.
If the end user receives both the first SMS and the second one at the same time (e.g. a delay in telecom delivering the messages), only the more recent OTP will work.
We recommend adding wording to end user UI to wait at least one minute for delivery of a first SMS OTP before offering a “retry”.
Additional KYB questions when Onboarding a Corporate
The onboarding process for a Corporate identity (i.e. a company or similar organisation) includes a number of questions related to business details, operations, as well as projected usage.
We are adding two new questions to this questionnaire.
The first asks the respondent whether their business is considered to be a “micro-enterprise”
The second (separate) question asks for their business Taxpayer Identification Number (TIN).
The TIN is the primary reference provided to the business by the taxation authority in the Corporate’s main country of business, so for example for UK businesses this is the HMRC unique taxpayer reference (UTR).
These questions are mandatory for all Corporates in all countries.
Both of these pieces of information help improve the accuracy of risk assessment and other Customer Due Diligence checks such as anti-money-laundering.