20 posts tagged with "Multi API"

Mobile phone numbers entered into the Multi API must follow international standards​

Mobile phone numbers entered into the Multi API must now follow the international standard with a maximum combined length of 15 characters. This includes:

• The country code
• The mobile number
• The “+” symbol (if used in the country code)

API details​

mobile object (used in the following endpoints):

• POST and PATCH /corporates
• POST and PATCH /consumers
• POST and PATCH /users

Before:

• countryCode: required, string [1 .. 6], regex: ^\+[0-9]+$
• number: required, string [1 .. 15], regex: ^[0-9]{1,15}$
  

After:

• countryCode: required, string [1 .. 4], regex: ^\+[0-9]+$
• number: required, string [1 .. 12], regex: ^[0-9]{1,12}$ Additional validation: total length of countryCode + number must not exceed 15 characters.
  
  

cardholderMobileNumber (deprecated field in POST and PATCH /managed_cards):

• Before: [5 .. 20] characters, regex: ^\+[0-9]+$
• After: [5 .. 15] characters, regex: ^\+[0-9]+$

Card billing city and delivery city field-length increased to 50 characters​

When issuing a physical card, the maximum length for the city field has been increased to 50 characters for both the billingAddress.city and deliveryAddress.city. These fields represent the city in the billing address and delivery address, respectively.

API details​

• PATCH /multi/managed_cards/{id}

Enhancements within data insights physical cards dashboard​

We have rolled out enhancements to the Physical Cards Data Insights dashboard, aimed at improving visibility into card stock levels and delivery operations. Within the Analysis tab, you can now find:

A new Stock Availability chart, providing a clear view of current inventory levels, including the consumed percentage of available cards to give you an immediate insight into stock usage trends; A new Physical Card Orders chart, displaying all physical card orders placed over the last 12 months, along with the associated delivery addresses and tracking numbers, offering a detailed look at distribution patterns and fulfilment activity These updates are part of our ongoing commitment to delivering sharper, actionable insights and streamlining operational management within the platform.

Bulk Processes in embedder portal​

It is now possible to view current and historic Bulk Processes in the embedder portal.

Currently you can track the progress of the operations in a Bulk Process via the multi API, and via webhooks. We have now added full visibility in the embedder portal.

Here you can view all Bulk Processes, their status', and the underlying operation that was performed. You can see a summary of the underlying operations, for example whether all operations were executed successfully, via the side-panel.

You can click on a Bulk Process to see the full API details of each underlying operation; helpful for investigating or troubleshooting any issues.

Marking virtual cards as compromised​

We have introduced a new feature that allows you to mark a virtual card as compromised directly from the embedder portal. With just a click, you’ll have the option to:

Mark the card as compromised and issue a replacement–Automatically destroys the affected card and generates a new one.

Mark the card as compromised and transfer funds–Move the remaining balance to another instrument linked to the same identity.

Mark the card as compromised without replacement–Destroys the affected card without issuing a new one or transferring funds.

This enhancement provides more control and flexibility when managing compromised virtual cards.

Handle more MCCs and MIDs in spend rules​

When creating or updating spend rules in our Embedder Portal and Multi, you can now add up to 200 allowed or disallowed MIDs and MCCs.

API details​

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

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

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

Biometrics and UI components, mobile SDK releases​

The Weavr mobile SDK for iOS, Android, and React Native platforms allows you to embed financial services into your own app, providing a seamless experience for your customers.

Recent improvements introduced in the Biometrics and UI components include:

• The Biometric Authentication component now supports the initial authentication, and fallback authentication, of the end user via password, rather than only passcode.
• The React Native SDK has been updated to support React Native's new architecture, and leverages the Expo-modules API to simplify maintenance.

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.

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.

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.