6 posts tagged with "Multi API"

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.