3 posts tagged with "Embedder Portal Simulator"

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.

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.

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.