Option to deduct excess authorisation amounts from next card virtual budget cycle​

We have added a feature to cover edge cases in card spend controls where a card’s availableToSpend has gone into the negative, and this negative amount can be optionally applied to (deducted from) the spend limit in the next interval.

This feature can be configured by setting rolloverPolicy.rolloverNegative to TRUE when creating or updating a card’s spend rules:

POST /managed_cards/{id}/spend_rules PATCH /managed_cards/{id}/spend_rules For API documentation as well as general documentation on spend controls.

Please contact Weavr support to get help testing out this new spend controls feature.

Card spend controls now allow zero-value authorisation for Google Wallet​

We've improved how we handle verification requests when end customer card assignees add their card to Google Wallet, which is done by a zero-value authorisation request. Previously, these verification checks could be incorrectly declined by the spend rules.

Now, legitimate account verification requests will process smoothly, making it easier for end users to add their card to Google Wallet while maintaining security for other types of transactions.

Improved matching of incremental authorisations to settlement​

We've improved our system to automatically link payment authorisations to their corresponding settlements with greater accuracy. This enhancement makes it easier for corporate customers to track and reconcile transactions, streamlining the reconciliation process and reducing manual effort.

Ability to send a new SMS OTP for confirming a transaction​

When performing Strong Customer Authentication (SCA) on Account-to-account payments (OWTs and Sends) using POST /challenges/otp/sms , if the end-user does not receive the SMS, our system now allows for a second SMS with a new OTP to be sent (as long as 15 seconds have passed since the first request). This is the same as previously implemented on POST /stepup/challenges/otp/SMS

The end-user already has up to four attempts to input the correct OTP from the SMS (via POST /challenges/{scaChallengeId}/otp/{channel}/verify) before it returns CHALLENGE_LIMIT_EXCEEDED.

Details are available in the documentation here.

End Customer ID included in OWT webhook​

In the Managed Account update webhook we are now providing an additional owner field to show which End Customer the Managed Account belongs to. This may help by removing the need to perform an API call to determine this information.

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.

New bulk operations: Block/unblock/remove Card​

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:

POST /bulks/managed_cards/{id}/block

POST /bulks/managed_cards/{id}/unblock

POST /bulks/managed_cards/{id}/remove

New webhook notification when the state of a card changes​

Card webhook notifications inform you of events that happen in relation to payment cards of End Customers.

We have added a new webhook that is sent whenever one of the following events occurs:

• Activate a physical card
• Remove a managed card
• Report a physical card as lost
• Report a physical card as stolen
• Card has expired
• Block a managed card
• Unblock a managed card The API documentation on the /managed_cards/state_change/watch webhook is found here: https://weavr-webhooks-api.redoc.ly/#tag/Managed-Cards

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.
• Conditional acceptance of IWTs
• Linked Account test funding transaction

Simulate IWT by Account ID​

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.

You can find out more about Linked Accounts in our documentation here.

Data insights on Micro-enterprises​

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.

Filter Managed Cards by renewal type​

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.

Affected webhooks:

• Corporate KYB status update
• Corporate beneficiary status update (NB 'beneficiary' here relates to UBOs in the KYB process)
• Consumer KYC status update

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

Simulate card purchases in multiple currencies in Sandbox + clarified display of currencies​

As a developer experimenting with the Weavr system for the first time, or working within a live programme to prototype and test your application against our API, you’ll want to simulate purchases on fake payment cards you’ve set up. You can do this in the Simulator accessed through the Embedder Portal:

Simulated card purchases are also available through the Simulator API here: https://weavr-simulator-api.redoc.ly/tag/Cards#operation/cards_card_id_purchase

Both methods now allow you to simulate purchases in any currency (using any ISO-4217 symbol). Assuming the currency of a card is in EUR or GBP, and a simulated card purchase is in some other currency, a built-in (approximate) currency conversion will be used.

As part of a path to support a wider range of currencies in card purchases, spend control rules, statements, analytics and so on, we have changed the display of all currencies in the Embedder Portal to be in a 3-letter ISO-4217 style (e.g. GBP, EUR instead of £, €).

Deprecation of Google Play SafetyNet Attestation​

Google announced in 2022 that it is deprecating SafetyNet Attestation and the deadline for adoption of the new alternative, Play Integrity API is 31 January 2025. This affects Embedders using our biometrics solution in their mobile apps, requiring integrating an updated solution. As part of the update, developers on affected programmes will need to obtain an Integrity Checks API server key from Google Cloud and provide to Weavr for use in the Biometrics Authentication SDK.

This is one of several changes we are making in our mobile SDK from this month, and Weavr will reach out to affected programmes to discuss development and testing of updated solutions ahead of the deadline.