21 posts tagged with "Multi API"

Simulating card expiration scenarios on the embedder portalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each.​

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 sendSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. 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 portalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each.:

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 cardPhysical Card A payment card that is printed or embedded in wearables and sent to customers directly. Physical cards are created by first creating a virtual card and then upgrading it to a physical card. They are sent in an inactive state and must be activated by the card assignee before first use. to 60 days from the current date and a virtual cardVirtual Card A payment card that is created instantly and can be used for e-commerce and online purchases. Virtual cards are issued through the Mastercard network and are automatically enrolled in the 3D Secure program for increased security and limited fraud risk. They can be created in prepaid or debit mode. 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 CardsVirtual Card A payment card that is created instantly and can be used for e-commerce and online purchases. Virtual cards are issued through the Mastercard network and are automatically enrolled in the 3D Secure program for increased security and limited fraud risk. They can be created in prepaid or debit mode.: The expiration date will be set to the last day of the month that is 30 days from today.

Physical CardsPhysical Card A payment card that is printed or embedded in wearables and sent to customers directly. Physical cards are created by first creating a virtual card and then upgrading it to a physical card. They are sent in an inactive state and must be activated by the card assignee before first use.: 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 ProcessBulk Process A task created when initiating a group of bulk operations. The Bulk Process has a consistent lifecycle (statuses) and management method, regardless of the type of operation being performed. It can be in states such as SUBMITTED, RUNNING, PAUSED, CANCELLED, or completed states. Improvements​

We've enhanced our Bulk ProcessBulk Process A task created when initiating a group of bulk operations. The Bulk Process has a consistent lifecycle (statuses) and management method, regardless of the type of operation being performed. It can be in states such as SUBMITTED, RUNNING, PAUSED, CANCELLED, or completed states. 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 processBulk Process A task created when initiating a group of bulk operations. The Bulk Process has a consistent lifecycle (statuses) and management method, regardless of the type of operation being performed. It can be in states such as SUBMITTED, RUNNING, PAUSED, CANCELLED, or completed states.'s start and finish timestamps, and the execution mode.

To keep you updated, you can now request webhook notifications on the bulk processBulk Process A task created when initiating a group of bulk operations. The Bulk Process has a consistent lifecycle (statuses) and management method, regardless of the type of operation being performed. It can be in states such as SUBMITTED, RUNNING, PAUSED, CANCELLED, or completed states.'s progress, with a frequency of up to four updates per bulk processBulk Process A task created when initiating a group of bulk operations. The Bulk Process has a consistent lifecycle (statuses) and management method, regardless of the type of operation being performed. It can be in states such as SUBMITTED, RUNNING, PAUSED, CANCELLED, or completed states..

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 TransferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. transactions in bulk​

We have enhanced the TransferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. Transaction process to save you time and effort. You can now instruct multiple transfersTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. in a single API call using our new /bulks/transfers endpoint. Previously, you could only trigger a single TransferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. transaction as one API call which was found to be cumbersome when executing multiple TransferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. transactions simultaneously.

This improvement is especially beneficial for embeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. who need to execute multiple transferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. 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 TransfersTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. are available on MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. and Back-Office APIs.
• The source and destination instruments for each transferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. must be owned by the same identity.
• TransfersTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. can be made between Managed AccountsManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. and Managed CardsManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User., and across these two types of Instruments.
• The request requires the source and destination Instrument IDs, and the amount for each transferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations..

Key API details:​

• Endpoint: POST/bulks/transfers
• Key parameters for each TransferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. 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 CardsManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User. 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 3DS3DS 3-D Secure - an additional security layer for online credit and debit card transactions. It adds an authentication step where the cardholder verifies their identity with the card issuer during the purchase, reducing fraud and providing liability protection for merchants. 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 portalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each.:

• 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, EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. staff can now find out more details to support the End Customer, within the Data Insights area of the Embedder PortalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each..

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 assigneeCard Assignee The person that a card is assigned to and who will use the card. For consumers, the card owner and card assignee are the same person. For corporates, the card assignee and card owner are different entities - the corporate is the card owner and the person using the card is the card assignee. Card assignees must be created as Authorised Users. 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)

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.

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 assigneesCard Assignee The person that a card is assigned to and who will use the card. For consumers, the card owner and card assignee are the same person. For corporates, the card assignee and card owner are different entities - the corporate is the card owner and the person using the card is the card assignee. Card assignees must be created as Authorised Users. 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 sendSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. a new SMS OTP for confirming a transaction​

When performing Strong Customer Authentication (SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).) on Account-to-account payments (OWTsOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication. and SendsSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary.) 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 OWTOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication. webhook​

In the Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. update webhook we are now providing an additional owner field to show which End Customer the Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. belongs to. This may help by removing the need to perform an API call to determine this information.