---

Service Updates​

Physical payment card fulfilment centre in EU​

We are glad to announce the availability of card printing and logistics based in the EU.

This will help reduce delivery times for EU-based cardholders compared to the main fulfilment centre in the UK.

If you have queries about card printing and delivery for your programme, including pricing, please contact your Account Manager, or open a support ticket, and we’ll be glad to assist.

Digital signature in KYB forms​

A reminder to Embedders that digital signatures on PDFs (such as via Docusign or Pandadoc) are acceptable for completion of various forms in the KYB process such as UBO declarations.

If you have any queries about the KYB process and documents/steps, please contact your Account Manager or open a support ticket and we’ll be glad to assist.

---

Product Updates​

KYB: Proof of ID document expiry process changes​

We are making a number of changes in this release to how we handle expiry of proof of ID (PoI) documents in KYC and KYB. Expiry refers to the “valid until” or “expires” date shown on the form of ID (such as a passport or national ID card).

The key points are as follows:

• Any Consumer with an expired PoI document will be restricted from transacting, after a reasonable time to react to support requests, until they return their KYC to good standing by providing a replacement/valid ID document (all else being in good standing).

• Any Corporate’s KYB good standing depends on the individual PoI documents being valid (not expired) for the Root User (/appointee), plus ALL of Ultimate Beneficial Owners (UBOs). All of the Corporate’s accounts/cards will be restricted from transacting if any of the required IDs are deemed to be out of date after attempts to alert the stakeholders, until brought back into good standing.

• In any actual restriction action Weavr will send a webhook and notification email as well as proactive support team engagement.

• The Embedder has the primary responsibility to communicate with End Customers and their representatives/stakeholders in advance of PoI expiry and in the event of documents having expired. Embedders' systems should provide one or more advance warnings to the relevant end customer contacts.

• Weavr will now send webhooks to the Embedder’s endpoint for every soon-to-expire PoI 30 days before expiry, 10 days before, and on the day of expiry. In addition a final warning is sent 10 days after the day of expiry. Embedders should use these webhooks to construct the relevant notifications for End Customer stakeholders.

• In addition to the above webhooks, Weavr will send emails directly to the affected Root User (or non-director Root User plus director appointing them). The email content is as follows and can be customised by the Embedder for their programme, on request via support ticket:

• The above email will be sent 30/10/0 days before as well as 10 days after the ID document expiry date.

• The 30/10 days before and 10 days after expiry timeframes are configurable per Embedder programme: please contact Weavr if you wish to make changes in this regard.

• Please note that any accounts currently affected by having one or more PoI documents already expired at the go-live date of this release, will already be subject to compliance case management with Embedder support teams. Any soon-to-expire cases after the go-live date will begin receiving reminders immediately.

Please read the full article on Proof of ID expiry to find out more (requires Weavr Support Portal login).

Sends and OWTs as bulk operations​

As announced in the last Release Note, we have introduced a capability to group multiple individual API-based actions into a batch of bulk operations; that are then executed and managed through the Bulk Process. This new feature is available to try out, on request (via support ticket or your account manager).

We have now added the following actions as bulk operations endpoints:

• POST bulks/sends - Create Sends in bulk.

• POST bulks/outgoing_wire_transfers - Create OWTs in bulk.

To complete these operations, a transaction confirmation challenge must also be completed, and so we have updated our Bulk Process documentation to describe this.

The previous endpoints that specifically served bulk Sends and bulk OWTs will be marked as deprecated, since these operations can now be managed as part of the standardised Bulk Process.

Cancel OWTs in state PENDING_CHALLENGE​

Previously, an Outgoing Wire Transfer (OWT) could be cancelled only if it was a scheduled (i.e. future-dated) transaction, at any time before the execution time. This is done by selecting the scheduled OWT transaction ID and cancelling it, optionally adding a cancellation reason.

With the updated POST /outgoing_wire_transfers/bulk/cancel endpoint, an OWT can be cancelled while it is still in the state PENDING_CHALLENGE, i.e. before the completion of the SCA challenge.

A single OWT or batch of OWTs can be cancelled in this way.

Therefore, Embedders can now add functionality to their OWT UX flow to offer account holders the ability to cancel an OWT at this stage, e.g. to go back, change details of the OWT, and start again.

Shared fees for Send transactions​

Currently, it is possible to configure and test various transaction fees in the Embedder Portal within the Sandbox environment. These fees are subject to checks and approval before they are applied in a live programme.

With this release we are adding a new fee mechanism for Sends (i.e. e-money payments between two different Identities' Managed Accounts under the same programme). Instead of a fee for a Send only being charged to the sender (the source account), some or all of the fee can now be shifted to the recipient (destination account).

New configuration is available in the Sandbox Portal to set up this kind of split/shared fees on Sends:

• Charge full fee to the source account,
• Charge full fee to the destination account, or
• Split fee between the source and the destination account: with the split being 50/50, or any percentage weighting you chose.

Fees that have been charged to End Customers in this way will be shown in their statements and transaction history - now, for both source and destination accounts.

Fees on Send transactions are specified on a Send Profile. The Send Profile is specified in the API call to initiate the transaction: therefore it is possible to have different Send Profiles for different fee approaches, and select the right one at the time of a transaction.

Embedders wishing to apply fee changes to a live programme should raise a change request via a support ticket.

Updating card spend rules as a bulk operation​

As announced in the last Release Note, one of the bulk operations to be included in the launch of the Bulk Process was the ability to bulk update spend rules across Managed Cards.

The Bulk Process, and specifically the ability to bulk update spend rules across Managed Cards, is now also available in the Back Office API.

The endpoint introduced is POST bulks/managed_cards/_id_/spend_rules.

Please contact Weavr support for guidance in testing out the new bulk operations features during this Beta phase.

Creation and delivery details for physical cards in Embedder Portal​

We have improved the Managed Cards detailed view in the Embedder Portal for programme administrators and support teams. This update provides more details about physical payment cards, which are set up by first creating a virtual card and then upgrading to physical:

• A timestamp indicating when the Managed Card was upgraded to a physical card,
• The manufacturing state of the card, and
• Delivery tracking details, if available.

The manufacturing states of a Card can be:

• REQUESTED: The upgrade of the card to physical has been requested.
• SENT_FOR_FULFILLMENT: The card has been sent for printing.
• DISPATCHED: The card has been manufactured and dispatched.
• DELIVERED: The card has been received and activated by the recipient.

Delivery tracking details are added when the manufacturing state is either DISPATCHED or DELIVERED.

Reminder: A Managed Card can be upgraded to a physical card by calling the Multi API endpoint POST /managed_cards/{id}/physical. For more information on setting up physical cards, please refer to our API guides.

Indication of which API key is used for webhook signing​

In previous release notes we noted how we are strengthening the mechanism of signing webhooks. Webhooks are signed using the Primary API Key of a programme. This key is now highlighted in the API Credentials list in the Embedder Portal:

The key marked as Primary is the one that has been active for longest. This applies to both Sandbox and live applications.

We recommend all Embedders move over to the new webhook signing / validation mechanism as soon as convenient.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of endpoints in the Multi API which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following Multi API endpoints can (optionally) be called idempotently:

• POST/corporates to create a Corporate Identity

• POST /consumers to create an Consumer Identity

• POST /multi/users/invite to send a user invite

• POST users/{user_id}/invite/consume to consume an invitation previously sent to the user

• PATCH /users/{user_id} to update details of a User

• POST users/verification/email/send to send an email verification code to an Authorised User

Further information on idempotency is provided in our API Docs here.

SSO for Embedder Portal​

We are now offering Single Sign-On (SSO) for the Embedder Portal on a Beta basis. Users will be able to log in to the portal using their company-provided authentication e.g. Google Workspace or Microsoft account.

This provides enhanced security and convenience for controlling access and adding/removing users from your organisation to work with the portal.

If you would like to participate in this Beta, please contact Weavr (via support ticket or your account manager).

---

Partner Notice​

Security reminder from Twilio Authy​

Please note that Twilio has recently announced an important update for Authy.

If your programme uses Authy for SCA or other 2FA please help communicate this to your end users with a reminder to update their app as soon as possible.

New Bulk processing capabilities in the Multi API​

This new feature is available to try out, on request (via support ticket or your account manager).

End-customer businesses (i.e. Corporates) often have to perform certain actions in bulk or batches. For example when an employer enrols their employees into their benefits programme. In such cases, the Embedder’s application can call a Multi endpoint for each individual end user action, as many times as necessary. We are now providing built-in bulk processing capabilities to make this type of repetitive/batch action easier to run and monitor.

Bulk operations refers to the capability of grouping multiple individual API-based actions into a batch. Over time we will make available an increasing range of common actions as bulk operations.

Running a bulk operation creates a Bulk Process, which is a parent task representing the workload, with a lifecycle (statuses) and management method. We aim to make this manageable in a consistent way regardless of the type of operation being performed in different or concurrent processes.

The first bulk operations we’re making available are:

• POST bulks/users Bulk create Corporate Authorised Users

• POST bulks/user/_user_id_/invite Bulk invite Corporate Authorised Users

• POST bulks/managed_cards/_id_/spend_rules Bulk update spend rules across Managed Cards

See our documentation for full details of the underlying Multi API calls.

Owner details added to the manual transaction Webhook event​

Previously for Embedder programme developers or technical administrators that enabled Weavr Webhook API, the manual transaction webhook event provided information relating to the transaction and the financial Instrument, but the Instrument owner's details were not included.

We’re now including the Instrument owner's details in the manual transaction event webhook. The owner details will include the type (whether corporate or consumer) and the owner ID.

This means that the additional data (the owner ID) can be used to reconcile all manual transactions impacting a single customer. This update will be made available automatically upon release and visible once a manual transaction webhook event is received.

Additional measure to avoid shared mobile device for biometrics​

Currently, for a device that has been enrolled for biometrics, it is possible to fully log-out, and then a different user use the same device to log-in. It is already not possible to enrol the same device for two users, and so a secondary user in that scenario would be able to log in, but then not be permitted to access functions requiring a Stepped-Up token.

We are closing this edge case to strengthen the security of our biometrics SDK: once the device is enrolled, it can only be used for logins by the unique end user who set up biometrics. For anyone else to use that device for their own logins to the Embedder's application, it would need to be unenrolled by the first end user (thus freeing it up to be enrolled into biometrics by a different user).

Updated word separator in Embedder Portal URLs​

In the process of standardising URL structure in the Embedder Portal we have replaced underscores (_) with hyphens (-) in paths of: /programmes/:programmeId/console/

Example:

• managed_accounts -> managed-accounts
• managed_cards -> managed-cards

All navigation paths should work as usual, and old URLs the Embedder's team have bookmarked should redirect to the new URLs. Please contact us if you spot anything that's not working as expected in the Embedder Portal interfaces.

FATCA reporting for US citizens and residents​

Please note that we are required to report details of any USA citizen/resident account holders under Foreign Account Tax Compliance Act (FATCA) regulations. This applies to Directors or Beneficial Owners of Corporates as well as to Consumers. We will contact you if this affects your live programme.

If you are planning to expand the addressable market of end customers onboarding to your application, whether for US-based customers or other geographic expansion, please discuss with your Weavr account manager (or open a support ticket) to confirm possibilities and any additional processes required.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of endpoints in the Multi API which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following Multi API endpoints can (optionally) be called idempotently:

• POST /managed_cards/{id}/block to block a Managed Card

• POST /managed_cards/{id}/unblock to unblock a Managed Card

• POST /managed_accounts/{id}/block to block a Managed Account

• POST /managed_accounts/{id}/unblock to unblock a Managed Account

Further information on idempotency is provided in our API Docs here.

New method for signing webhooks​

We are making webhook signatures more robust with the new method optional to adopt at present. For now, both the previous method and the new method are supported. The new method described below will become the only supported method on a timeline confirmed in a future breaking change release. In the meantime please test this out with your programme so you are ready to migrate at a later date or as soon as you wish.

Webhook signatures allow Embedder's applications to verify that a message received originates from Weavr. We require that all Embedders implement such security mechanisms. The previous (still live) method is described in the Webhooks documentation here.

In the new method we are using HMACSHA256 to create a signature from a hash of the entire message (call-ref + payload + published-timestamp) instead of just the timestamp. This provides proof of integrity of the message (i.e. it has not been tampered with).

This new signature value is being passed as a new parameter in the header denoted by signature-v2; the signature parameter in the header will continue to be present for now, having a value based on the hashed published-timestamp.

At present, the webhook signing key is the oldest active API key of the Embedder's application.

Options to use biometrics in different SCA scenarios​

We are continuing the rollout of new biometric authentication features in the context of more SCA scenarios as below.

In general, the following scenarios require Strong Customer Authentication to be completed by the End Customer:

• Step-Up login to access sensitive account and payment card information
• Non-card payment approval (i.e. to execute a Send or OWT)
• Card payment approval i.e. 3-D Secure

At the stage of prototyping and testing in the Sandbox, developers can now experiment with use of biometrics to perform some or all of these flows (instead of, say, SMS OTP).

Embedder Portal screens make the following options editable while in Sandbox (non-production) mode.

Option to use biometrics as the primary/default Step Up login with a fallback to SMS OTP.

Option to use biometrics as well as - or instead of - SMS OTP when confirming outgoing (non-card) payments.

Option to use biometrics as well as - or instead of - SMS OTP when confirming outgoing (non-card) payments.

These SCA options can be configured independently from each other while testing different user journey approaches. Live programme SCA configurations are subject to checks and approval before launch and whenever making any changes that affect End Customer experience.

Data Insights - new Currency Analysis tab​

As part of our continuous improvements to Data Insights, we are introducing a new Currency Analysis tab within the Settlements dashboard.

Managed Cards have an Instrument Currency and the API and Embedder Portal show reports in the currency of the instrument.

However, for Data Insights, each programme has a configurable Base Currency to allow for aggregation of financial data.

This means that in Data Insights dashboards it was previously not possible to view card transactions using the original (instrument) currency, or aggregate statistics in those alternative currencies. The new Currency Analysis tab enables Embedder operational and support staff to review card purchase settlement data using the Instrument Currency instead of the Base Currency.

Managed Cards can be created with an Instrument Currency of GBP, EUR, or USD.

The new Data Insights tab in the card Settlements dashboard allows Embedder Portal staff users to review End Customer financial activity in the currency of the card or account instrument.

Internal e-money Transfers show source and destination accounts​

We are improving the transaction details displayed for Transfer transactions. A Transfer is a transaction moving money between two Managed Accounts of the same Identity (in the same currency) - i.e. an internal e-money movement not an external wire transfer or third-party payment. Transfers are also used when a Managed Account holder tops up one of their prepaid Managed Cards.

Previously, for Transfer transactions, the transaction activity pages in the Embedder Portal for both the Managed Account and Managed Card did not display information about the source and destination of the transaction being viewed. Additionally, the description field optionally used in a Transfer was not possible to review.

The detailed view for a Transfer transaction will now provide all of this additional information. When the transaction is being viewed from the source instrument transaction activity page, the transaction details will include information about the destination instrument. Whilst, when the transaction details are viewed from the destination instrument, the details of the source instrument are provided.

This enhancement to the Embedder Portal does not impact the statement generation endpoints provided in the Multi API or in the BackOffice API since they already include this information in the additionalFields field.

This enhancement will be made available automatically in the Sandbox. The information displayed will mimic the same structure provided in the screenshot below when viewed from the destination instrument.

Embedder Portal staff users can review individual Send transactions with additional details displayed about the source and destination accounts.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of endpoints in the Multi API which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following Multi API endpoints can (optionally) be called idempotently:

• POST /managed_cards/{id}/physical/report_stolen to report a physical Card as stolen

• POST /managed_cards/{id}/physical/report_lost to report a physical Card as lost

• PATCH /corporates to update the details of the logged-in corporate identity

Further information on idempotency is provided in our API Docs here.

Rollback: Step-Up expiry extended for Managed Cards​

The extended Stepped-Up session validity (180 days) on the GET Managed Card endpoints that was announced as a Sandbox feature in the last release notes email, has now been postponed to a future release. For now, the endpoint will continue to require a Stepped-Up token as previously documented.

Streamlined API call for incrementing a card spend limit​

In embedded finance use cases delivering employee-spendable benefits / rewards / allowances, a common approach is for employers to set an allowance per employee (/card) on a periodic basis (e.g. monthly, weekly). In some cases, the employer may want to allow the employee to carry over any ‘unused’ budget from the previous period into a new period.

This can be achieved via the Weavr APIs by establishing an “ALWAYS interval” and a “limit”, and then setting a new, higher limit when reaching the end of the period. Until now this required two calls, GET all spend rules for a Managed Card (to determine the current limit), then after calculating the new limit, a second call to PATCH update the spend rules on that Managed Card.

Weavr now offers a streamlined way of doing this, as follows:

We have introduced a new parameter in the spendLimit array - updateMethod with the following enums:

• OVERWRITE : (default option if left null). Overwrites the previous values for the spendLimit object i.e. sets new limits

• INCREMENT : This will increase the existing value of the spend limit by the amount input the value field.

If INCREMENT is used in conjunction with an ALWAYS interval (as in the example given), it can negate the need for the first GET (of the limit) and the calculation of the new limit. Simply call the PATCH with updateMethod set to INCREMENT, interval to ALWAYS and the value you want the limit to increase by.

INCREMENT can be used on all intervals, not just ALWAYS. You cannot decrease a limit using INCREMENT.

APIs affected:

PATCH /managed_cards/{id}/spend_rules

Data Insights - new SCA Events dashboard​

PSD2 defines that Strong Customer Authentication (SCA) via multifactor authentication needs to be used when End Customers access their sensitive payment account information and make payments.

To help Embedder programme operations and support teams track and troubleshoot SCA actions of End Customers through their programme, we are introducing a new Data Insights dashboard in the Embedder Portal: SCA Events.

Embedder staff can now gain an overview of SCA-type auth events, including the ability to filter by country and authentication channel.

SCA events covered include:

• Device enrolment

• Session Step-Up

• Transaction confirmation

• 3DS initiation

• Beneficiary management

Embedder Portal users can deep-dive into each segment by using the drill-down functionality available across various charts.

Within this dashboard, you can also access a dedicated SMS Analysis tab which you can use to track the journey of SMSs and understand how long SMSs take in each state. This can be helpful for troubleshooting any SMS deliverability issues that are emerging in support cases for particular customers or regions, often due to local telecoms reasons.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of endpoints in the Multi API which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following Multi API endpoints can (optionally) be called idempotently:

• POST /managed_accounts to create a Managed Account

• POST /managed_cards to create a Managed Card

• PATCH /managed_cards/{id} to update a Managed Card

• DELETE /managed_cards/{id}/spend_rules to delete all spend rules for a Managed Card

Further information on idempotency is provided in our API Docs here.