Skip to main content

Version 3.50.2

· One min read
Kristina Gauci

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.

WEB

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.


Version 3.50.1

· 6 min read
Kristina Gauci

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.

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

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

WEB 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.

WEB 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.

WEB 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.

WEB

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.


Version 3.50.0

· 3 min read
Dragos Tigoianu

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. WEB

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

WEB

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.

WEB

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.


Version 3.49.1

· 2 min read
Dragos Tigoianu

Email to End User for new device biometrics enrolment

Embedders have the option of enabling mobile device biometrics (facial recognition or fingerprints depending on hardware and Android vs iOS) as a multifactor authentication method, provided their application offers End Users a mobile app.

When an End User successfully enrols their first device or a new device for biometrics, Weavr will now send an email directly to them. As well as confirming a successful enrolment, this is also a security feature to alert them in case the device enrolment was not done by them. (In addition to this email, Weavr continues to send a webhook to the Embedder on the status change of the biometrics enrolment flow.)

The following is the default template for this email, where the example text “PasscodeApp” would change to the Embedder’s application name:

WEB

As with other transactional emails sent by Weavr directly to End Users, as the Embedder you have the option to apply your own brand design and potentially wording changes to this email template, subject to approval.

To create or change customised email templates, please open a support ticket.

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.

WEB

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

  • PATCH /managed_accounts/{id} to update a Managed Account details

  • POST /managed_cards/{id}/physical/activate to activate a physical card

  • POST /managed_cards/{id}/physical/replace_damaged to replace a damaged physical card

  • POST /managed_cards/{id}/physical/replace_lost_stolen to replace a lost or stolen physical card

  • POST /managed_cards/{id}/physical/contactless_limit/reset to reset the contactless limit for a physical card

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

Card Settlement Reversal indicated in Embedder Portal

We have made changes to the way a payment card Settlement Reversal is presented on the Embedder Portal in the Managed Cards transaction activity view. Previously, only the transaction type was shown, without a merchant name.

In order to help Embedder support staff to reconcile a reversal with the relevant settlement, this view now displays the merchant name.

WEB

The changes made to the Embedder Portal statement user interface will not affect the endpoints provided in the Multi API or Multi Back-office API for the generation of Managed Cards statements.


Version 3.49

· 3 min read
Dragos Tigoianu

Enrolling new biometrics auth factor now has additional security requirement

When enrolling a mobile device for the biometrics authentication factor, an additional step is now required to corroborate the link between the legitimate user and the device. The user will need to have a successfully registered mobile number to use for SMS OTP prior to starting the biometrics enrolment.

As part of the biometrics enrolment flow, the user will need to pass an SMS OTP challenge.

When the end user requests to enrol their device, we check if there is a mobile number associated to that user:

  • If there is a verified number, Weavr will send an OTP over SMS to the user’s registered mobile number, which they can input in the request screen (provided in our biometrics SDK). If this OTP is valid, enrolment is successful.

  • if there is a number available, but not verified, Weavr will send an OTP over SMS to the user’s registered mobile number, which they can input in the request screen (provided in our biometrics SDK). If this OTP is valid, enrolment is successful and mobile number is automatically verified.

  • If the user does not have a mobile number or would like to change with another mobile number, the Embedder needs to call

PATCH/corporates PATCH/consumers

before triggering the SMS challenge for biometrics enrolment flow.

When a user tries to enrol his device for biometrics without having a mobile number, we are returning 409 - Mobile_Number_Not_Available

Other scenarios when PATCH should be called are:

  • user has an invalid format of the mobile number - 409 Mobile_Number_Invalid
  • user has a mobile number with a country code not supported - 409 Mobile_Country_Not_Supported

All these changes will be part of our future mobile SDKs releases.

Default complexity level for passwords is now set to 4

As part of a wider series of changes to enhance security for End Customers, we are increasing the default complexity level of the passwords to level 4. This means, that the password must be:

  • between 8 and 30 characters
  • include a lowercase character
  • include an uppercase character
  • include a digit and a special character
  • different from any of the 5 last such passwords used

If your users are having a Level 1 complexity password, they will be allowed to continue using Level 1 password until:

  • password expires - Level 4 complexity will be required for the new password
  • user triggers Forgot password flow - Level 4 complexity will be required for the new password
  • user changes the current password - Level 4 complexity will be required for the new password