Manage spend limits on debit-mode cards in the user's own currency​

Weavr is enhancing its debit card offering by introducing the ability to configure spend limits in a secondary currency—different from the card's assigned currency, known as the userCurrency.

Cardholders will be able to view their card balance and set spend limits in their designated userCurrency, providing greater flexibility and transparency in managing expenses.

Please note that once a card is created, its assigned userCurrency cannot be changed.

Key points​

• Feature is optional

• You need to contact your account manager or Weavr support team to enable this feature

• For each card profile you can choose to enable all supported user currencies or a subset

JPY, BGN, CZK, DKK, HUF, PLN, RON, SEK, CHF, ISK, NOK, TRY, AUD, BRL, CAD, CNY, HKD, IDR, ILS, INR, KRW, MXN, MYR, NZD, PHP, SGD, THB, ZAR

Consider a UK-based company with employees located in Sweden. If the company enables SEK (Swedish Krona) as a userCurrency, it can assign this secondary currency when issuing cards to Swedish employees. It’s important to note that specifying a userCurrency does not alter the underlying card’s issuing currency with our banking partners. The card’s primary currency remains unchanged, and all card statements will continue to be reported in the original issuing currency.

API details​

• POST /managed_cards

• GET /managed_cards/{id}

• GET /managed_cards

• POST /managed_cards/{id}/spend_rules

• PATCH /managed_cards/{id}/spend_rules

• GET /managed_cards/{id}statement

Further details are available in our product documentation here

Webhook details​

• /managed_cards/authorisations/watch

• /managed_cards/settlements/watch

Enhanced physical-card tracking information​

via API​

We have added a new field, detailsDeliveryTrackingUrl, to the multi and back-office Get Card API endpoints. When available, this field provides a direct link to the courier's tracking information page for the physical card delivery, allowing you to monitor the delivery status of a physical card in real time.

• GET multi/managed_cards/{id}

• GET multi/backoffice/managed_cards/{id}

via Embedder portal​

Where possible, the same detail has been added to the embedder portal, making it easier to access the courier's tracking information with a single click, that takes you directly to the courier’s tracking page, making it easier to monitor delivery status and updates in real time.

Functionality to set custom start date for a spend limit interval​

We’ve enhanced our spend rule creation capabilities to give you more flexibility when setting spending limits for physical and virtual debit mode cards.

Card owners (corporate root or authorised users) can now customise the start date for spend limits based on the selected interval—whether it's weekly, monthly, quarterly, or yearly.

For example, you can now set a yearly spend limit that starts on May 1 2025 and ends on May 1 2026.

This gives you more control in aligning spend limits with your financial planning cycles.

This update is on multi and back-office.

API details​

• POST /multi/managed_cards/{id}/spend_rules

• PATCH /multi/managed_cards/{id}/spend_rules

• PATCH /multi/bulks/managed_cards/_id_/spend_rules

• POST multi/backoffice/managed_cards/{id}/spend_rules

• PATCH /multi/backoffice/managed_cards/{id}/spend_rules

• PATCH /multi/backoffice/bulks/managed_cards/_id_/spend_rules

AuthorisationCategory field in APIs and Authorisation Webhooks​

We’ve introduced a new field called AuthorisationCategory in our card statement APIs and authorisation webhooks. This field helps you distinguish whether a card authorisation is a pre-authorisation or a final authorisation. AuthorisationCategory will support

• PRE_AUTH Indicates a pre-authorisation, commonly used for reserving funds (e.g., hotels, rentals).

• FINAL_AUTH Indicates a final authorisation, typically representing the actual transaction amount.

This new field allows for better control and visibility over transaction flows. You can:

• Accurately track the lifecycle of a payment

• Differentiate between temporary holds and completed payments

• Improve reconciliation and customer communication

API details​

• GET /multi/managed_cards/{id}/statement

• GET /multi/backoffice/managed_cards/{id}/statement

Webhooks​

• /managed_cards_authorisations_watch

More efficient statement retrieval​

We have made improvements to our statement retrieval process (for cards and accounts). Previously, due to API limitations, statement data was provided in pages of 100 items, sometimes requiring multiple requests for complete information.

We have now increased the maximum number of items per page to 500. This enhancement will streamline the process of retrieving your statement data.

To benefit from the increased limits, specify your desired limit in the limit parameter when making a GET request to the statement API. Or contact your account manager to configure an appropriate default limit.

Key Points​

If no specific limit is requested, the system will default to 100 items or a limit that has been agreed with your account manager (maximum of 500) .

If the statements request includes a period before April 1, 2025 , the maximum limit of 100 will still apply.

If the limit specified in the API request is higher than the configured limit , the limit will internally fall back to the configured limit.

API Details​

• GET /multi/managed_accounts/{id}/statement

• GET/multi/managed_cards/{id}/statement

We believe these updates will significantly improve your experience in accessing and managing your card and account statements.

Simulating card expiration scenarios on the embedder portal​

We are pleased to announce new tools to help you understand and test the card renewal process in our sandbox environment.

To keep you informed about important card lifecycle events, Weavr will send Card Notifications regarding upcoming card renewals and expired cards, allowing you and your users to take timely action. You can find more details about card renewals here

To streamline your testing and integration, we've introduced two new simulators in our sandbox embedder portal:

Card expired: This simulator instantly triggers the expiry of a selected card.

Card about to expire: This simulator initiates the card renewal process by setting the expiration date of a physical card to 60 days from the current date and a virtual card to 30 days from the current date.

Additionally, we've implemented automatic updates to card expiration dates specifically within these simulator paths, making testing even easier.

How the Simulators Work:​

/cards/{card_id}/about_to_expire

Virtual Cards: The expiration date will be set to the last day of the month that is 30 days from today.

Physical Cards: The expiration date will be set to the last day of the month that is 60 days from today.

/cards/{card_id}/expire

The card's expiration date will be set to the last day of the previous month relative to the current date.

These new simulators provide a convenient and efficient way to test your integration with our card renewal notifications. We encourage you to explore these features in the sandbox environment.

Bulk Process Improvements​

We've enhanced our Bulk Process functionality, providing you with greater visibility into its execution and the operations within.

The GET /bulks/{bulk_id} endpoint response now includes an operationStatusCounts field, detailing the number of operations in each status (SUBMITTED, RUNNING, COMPLETED, FAILED, CANCELLED). You'll also find the bulk process's start and finish timestamps, and the execution mode.

To keep you updated, you can now request webhook notifications on the bulk process's progress, with a frequency of up to four updates per bulk process.

Please note that in a future update, the bulk_process_end webhook will be renamed to bulk_process_progress to better reflect its function and will include the operationStatusCounts mentioned above.

API details​

GET /bulks/{bulkId}

POST /bulks/{bulkId}/execute

Webhook details​

bulk_process_end/watch

For more information, refer to the Bulk Process

Confirm passcode UI component​

We’ve added a confirm passcode component to our UI library. When used in conjunction with the passcode component, it will validate that both passcodes that are entered, match.

Statement Filtering on transactions​

We’ve made it easier for you to get the information you need! You can now filter transactions when calling the statement endpoint, so you’ll only receive the ones you're interested in, rather than all transaction types. This means fewer API calls to get the statement view you're looking for, saving you time and effort when building your statements.

Key points​

When calling the statement endpoints, the desired transaction types can be specified in the new filter parameter transactionType.

Key API details​

• /multi/managed_cards/{id}/statement
• /multi/managed_accounts/{id}/statement

Custom fees: error handling​

We've improved the error response for custom fees that are incorrectly configured.

A custom fee is triggered by you, via API POST /multi/corporates/fees/charge, according to a pre-set and approved configuration.

Key points​

Previously, if a custom fee was triggered on an instrument in a currency where a value had not been configured, a 200 response was returned. This has been changed to a 409 “FEE_AMOUNT_NOT_SET” response, which more accurately indicates that the fee was not charged.

API details​

• /multi/corporates/fees/charge

Support for Transfer transactions in bulk​

We have enhanced the Transfer Transaction process to save you time and effort. You can now instruct multiple transfers in a single API call using our new /bulks/transfers endpoint. Previously, you could only trigger a single Transfer transaction as one API call which was found to be cumbersome when executing multiple Transfer transactions simultaneously.

This improvement is especially beneficial for embedders who need to execute multiple transfer transactions for an identity at the same time, such as when loading or topping up several Pre-Paid Mode cards.

Key points about how it works:​

• Bulk Transfers are available on Multi and Back-Office APIs.
• The source and destination instruments for each transfer must be owned by the same identity.
• Transfers can be made between Managed Accounts and Managed Cards, and across these two types of Instruments.
• The request requires the source and destination Instrument IDs, and the amount for each transfer.

Key API details:​

• Endpoint: POST/bulks/transfers
• Key parameters for each Transfer in the request:
• Source and destination instrument Ids (managed_accounts or managed_cards)
• Amount

Cards can be created without requiring the cardholder mobile number registered​

We've simplified the process of creating Managed Cards for users. Previously, you could only create and assign cards to users who had already registered their mobile phone number. Now, you can create and assign cards to users even if they haven't yet registered their mobile phone number. This enhancement addresses scenarios such as when your Corporate customer is onboarding a new employee and they’d like to have their card ready for their start date.

While a mobile number is no longer required during card creation, it remains necessary for certain card actions, such as 3DS authentication during e-commerce transactions and manual provisioning a card to a digital wallet.

Key points about how it works:​

• Endpoint: POST/managed_cards
• Removal of 409 error USER_MOBILE_NUMBER_DOES_NOT_EXIST
• Mobile number of the user must be updated if the card is required to be used for e-commerce transactions, or manually provisioned to a digital wallet.

As part of this update, we deprecated the threeDSecureAuthConfig.linkedUserId parameter in favour of userId.

Extended list of MCCs available on the simulator​

We are extending the list of the MCCs that will be recognised in the following simulators we offer on our embedder portal:

• card purchase using card id
• card purchase providing card details
• card merchant refund

If an MCC is used in the simulator that is not part of this list, the action will still complete successfully, but the transaction will show with a default generic code MC - 5399 “Miscellaneous General Merchandise Stores”

More information is available here.

Additional detail in cards data insights​

If a card transaction has been declined, Embedder staff can now find out more details to support the End Customer, within the Data Insights area of the Embedder Portal.

In the "Details" view of the "Authorisations" dashboard, a new "Transaction Code" column shows what kind of transaction was attempted e.g. goods and services, or ATM withdrawal. This view already includes "Decline Type".

Note: Authorisations, including declines, are already reported in real-time via the card authorisations webhook. The webhook includes the authorisation type, whether it failed due to spend controls and the reason why, and the decline reason. This new field in Data Insights can help you analyse the success rate more generally for different types of card actions.

Longer Authorised User names permitted​

We have increased the character limit for both name and surname fields within the Authorised User creation endpoint, to 50 characters each (from a previous limit of 20). This enhancement accommodates users with longer names.

Affected APIS:

• Create an Authorised User POST/users
• Update an Authorised User PATCH/users/{user_id}

Note: a card assignee name limit remains unchanged as there is a limit to the number of characters that can be printed on the card. If the user's real name is longer than the space available to print on a card, the first name(s) should be truncated to aim to keep the surname complete. (For name on card requirements see POST/managed_cards)