8 posts tagged with "Multi API"

Two-step login flow for Embedder Portal​

We have updated the login flow for the Weavr Embedder Portal to ask for the user’s email to be submitted first, and then the password in a second step.

Weavr Embedder Portal production first login screen 2024 10 This is part of the rollout of single-sign-on (SSO) for the Embedder Portal: if this is of interest in your programme, please contact your Account Manager or Support.

This applies only to the production instance of the Embedder Portal, not to the Sandbox instance.

Track physical payment card fulfilment status via webhooks​

We are introducing a new webhook event to help Embedder systems track End Customer card orders and thus convey status changes around the fulfilment to the End Customers.

We recommend proactively keeping End Customer users updated, such as an employee due to receive a card, and a manager who placed the order for the employee to receive a card.

Please review the API documentation for this feature here: https://weavr-webhooks-api.redoc.ly/#operation/managed_cards_physical_cards_upgrade_watch

Webhooks are sent for each fulfilment status change (in the API known as the manufacturingState), as follows:

• REQUESTED: Fulfilment of a physical card order has started.
• SENT_FOR_FULFILLMENT: Printing and packaging is in progress.
• DISPATCHED: The card is in the postal or courier system.
• DELIVERED: The card has been activated.

If webhooks are enabled and configured, Embedder operational and support staff can review recent webhook events in the Embedder Portal via the Webhook Logs page:

Payment card expiry details added in Embedder Portal​

In a previous release [https://docs.weavr.io/blog/2024/02/27/v3.48/#new-feature-payment-card-renewals], Weavr added features to facilitate automatic renewal of expiring payment cards.

To help Embedder programme operations teams support End Customers with their payment cards, we’ve added renewal information to the Managed Cards dashboard in the Data Insights section of the Embedder Portal.

The following details are now shown as columns in the report tables:

• Expiry Date - indicating when a Managed Card is set to expire;
• Next Renewal Date - indicating when an automatic renewal process would commence, if it is set to renew.

Cards which are set NO_RENEW will still have a “Next Renewal Date”, which can be understood as the deadline for being able to change its setting to RENEW, and get the card renewal processed before the expiry date. This “Next Renewal Date” will therefore be ignored if the card remains set to NO_RENEW, and not auto-renewing is also the default if renewalType is not specified.

For more information please see the card renewals documentation.

New method of indicating assignment of a payment card​

When a business (Corporate) assigns a payment card to an End User, typically an employee, this assignment is recorded at the time the card is created.

Previously we’ve used the the linkedUserId field within the threeDSecureAuthConfig object when creating a Managed Card [https://weavr-multi-api.redoc.ly/3.55.0/tag/Managed-Cards/#operation/managedCardCreate].

We are planning to deprecate this use of linkedUserId and replace it with a new method of indicating assignment of a payment card as described below.

(Note: within the same threeDSecureAuthConfig object we have already marked the field cardholderMobileNumber as deprecated.)

We now recommend using the new field userId to identify which End User (typically an Authorised User) a card is assigned to at creation.

Going forward this will be the supported way of noting the card assignment for purposes including:

• 3DS checks
• Mobile wallet provisioning

Please start using this method when creating new cards. We will communicate the deadline for deprecation of the previous linkedUserId field, and migration of existing assignments, in future release notes.

List view of registered Linked Accounts​

Last month we introduced new features and policies to ensure all UK-based programmes are ready for the new regulatory regime relating to APP Fraud. [https://docs.weavr.io/blog/2024/09/18/v3.54.0/#changes-relating-to-wire-transfers-functionality-in-uk-programmes]

All End Customers in UK-based programmes can take advantage of the new Linked Accounts feature [https://docs.weavr.io/blog/2024/09/18/v3.54.0/#introducing-linked-accounts], and it is required for End Customers to have at least one Linked Account active within UK Cards-Focused programmes.

Embedder operations and support teams can now view information about Linked Accounts in the Embedder Portal, as a new tab in Corporates page (where this is applicable to the programme):

Please reach out to Weavr for support on any aspects of the Linked Accounts feature, or to support End Customers with getting successfully set up.

Linked Account process API field change​

In UK Cards-Focused programmes, End Customers need to set up at least one Linked Account to be able to fund their Managed Account(s).

One of the setup steps is a declaration of ownership via SCA-style challenge [https://docs.weavr.io/instruments/linked-accounts/linked-accounts-verifications/#declaration-of-ownership-via-sca-challenge].

We have changed an enum in “Get Linked Account verifications” [https://weavr-multi-api.redoc.ly/3.55.0/tag/Linked-Accounts/#operation/linkedAccountVerificationsGet] from "ROOT_USER_DECLARATION_SCA_CHALLENGE" to "USER_DECLARATION_SCA_CHALLENGE"

Please ensure you are referring to the current API documentation when implementing this new feature.

Bulk operations management API fields change​

In previous release notes we announced Bulk API processing capabilities available on a Beta basis [https://docs.weavr.io/blog/2024/07/01/v3.51.0/#new-bulk-processing-capabilities-in-the-multi-api].

If you are working with the ‘GET all operations in a bulk’ endpoint please note we have made changes to the names and descriptions of fields in the operations array. Please review the documentation here: https://weavr-multi-api.redoc.ly/3.55.0/tag/Manage#operation/bulkIdOperations

---

Changes in End Customer onboarding​

New FI T&Cs agreement onboarding screen​

Onboarding flows for all new end customers will change to require an updated method of recording agreement to financial institution terms and conditions (FI T&Cs).

All Consumers and all Root Users of Corporates will now be shown the following screen when onboarding:

This enables us to record the agreement of the End Customer to the FI T&Cs directly, as well as automatically update the version of T&Cs if they are revised in future. T&Cs updates will be communicated in advance in each case.

This FI T&Cs agreement screen is implemented automatically in the standard embedded onboarding flows, prior to the Customer Due Diligence steps (e.g. identity verification and proof of address) in the rest of the process.

Live programmes will need to ensure that they remove any older T&Cs agreement steps from their own sign up flows (i.e. to remove duplication of a step) as soon as feasible. Embedders should still ensure the correct versions of the T&Cs documents are available to the End Customer to find easily via their application, support docs etc.

Documentation links:

• KYC onboarding
• KYB onboarding

Existing End Customers on live programmes will not be affected (since they already agreed to terms and conditions when they signed up, and were sent any subsequent changes).

Updated/moved Micro-enterprise declaration in KYB onboarding​

As well as the above new T&Cs step for all onboarding flows, we will now require a clearer Micro-enterprise declaration, which we are adding into the KYB onboarding:

As shown, the Root User of the Corporate needs to answer the two questions and then agree to the declaration about whether the Corporate is or is not considered a Micro-enterprise.

This replaces the previous question in the KYB questionnaire, and these changes take place automatically.

Documentation links:

• KYB onboarding
• Definition of “Micro-enterprises”

Existing End Customers on live programmes will not have to take any action directly. If our records show that a Corporate’s profile is unclear about their Micro-enterprise status, we will follow up with the Embedder’s team about how to refresh KYB profiles in this respect.

---

Changes relating to wire transfers functionality in UK programmes​

From 7 Oct 2024, new regulations come into force in the UK regarding the fraud compensation rights of retail customers using Faster Payment System payments, known in the industry as “push payments”, and hence the regulations relate to “authorised push payment fraud” or APP Fraud.

Embedders with UK programmes should familiarise with the following background information: APP Fraud overview. Pay UK provides a timeline of regulatory changes here.

All UK programmes now choose a general payment model that takes into account changes to risk from APP Fraud regulations, and as part of these changes we are also implementing new features to be able to exclude “self-to-self” payments from the scope of future fraud claims.

These APP Fraud related changes do not affect EU/EEA programmes.

UK programme choices under new APP Fraud compensation regime​

UK programmes will now be classified into three distinct approaches in terms of how APP Fraud risks are mitigated.

1. Cards-Focused programmes

   End Customers will not be able to send or receive Faster Payment System wire transfers except “self-to-self” to/from Linked Accounts, i.e. for the purpose of funding accounts for cards usage, and withdrawing any surplus balance.

2. Cards and Wire Transfers programmes

   End Customers will continue to take advantage of GBP OWTs to third parties and IWTs from third parties via the Faster Payment System, but within new boundaries and features designed to control risk.

3. Wire Transfers Focused programmes

   The Embedded Payment Run solution operates without cards and requires mitigations of APP Fraud risk: details for relevant programmes are available in separate release notes.

For (1) Cards-Focused programmes, changes must be made to implement Linked Accounts (see below) and remove any previous functionality and UI/UX material relating to third party OWTs and IWTs.

For (2) Cards and Wire Transfers programmes, changes include implementing new steps in OWT flows, optionally making use of Linked Accounts features, and establishing a working position with regard to real-time screening of IWTs.

All live UK programmes will receive more detailed guidance to assist with change management.

Introducing Linked Accounts​

Linked Accounts are a new feature available initially for UK programmes only.

Linked Accounts are a representation of an End Customer’s own external accounts (such as a Corporate’s business bank account) which they register and verify in our systems. This means we can treat Incoming Wire Transfers from the external account as a “self-to-self” funding transaction, and any Outgoing Wire Transfer back out to that account as a “self-to-self” withdrawal.

These transactions are then not in scope of APP Fraud claims, ensuring that a [UK] Cards-Focused programme can operate without exposure to risk from general third-party wire transfer flows. In the case of [UK] Cards and Wire Transfer programmes, Linked Accounts can optionally be used to reduce risk by differentiating clearly between “self-to-self” flows and other third-party payments.

In summary:

• Both Consumer and Corporate End Customers on UK programmes can use Linked Accounts
• Using Linked Accounts is mandatory on UK Cards-Focused programmes
• Using Linked Accounts is optional on UK Cards & Wire Transfers programmes
• Linked Accounts are not yet available for EU/EUR/SEPA programmes

Existing End Customers on live UK Cards-Focused programmes will need to set up at least one Linked Account to be able to continue funding their payments (and withdrawing surplus funds if they desire). Weavr will assist live Embedders with this setup process for existing customers.

Documentation links:

• UK Linked Accounts: how to add and verify
• UX flow for registering and verifying a new Linked Account: flow diagram

Conditional acceptance of IWTs​

We are offering the following new feature initially only for UK Cards and Wire Transfers programmes. In these programmes Embedders have opted to continue offering features that allow End Customers to receive Faster Payment System [GBP] IWTs from third parties. Therefore, both the End Customer and the Embedder are exposed to risk due to the possibility of external payers being retail customers who create a claim against a transaction with their (third-party / external) payer’s PSP.

On a beta basis we are working with affected programmes to put in place a real-time decisioning system so that the Embedder’s business can selectively decide on a per-transaction basis whether to allow an End Customer to accept a [GBP FPS] IWT.

This is described in our documentation as “IWT Forwarding Event” here.

We will discuss implementation details on a programme basis.

This feature is not available for Embedders on UK Cards-Focused programmes, although we use our own real-time decisioning in a similar way to reject IWTs which are not from external sources previously verified as Linked Accounts.

The feature does not currently apply to EU/EEA programmes and [EUR] SEPA payments.

Changed requirements for UK FPS OWT creation to include Confirmation of Payee​

We are offering the following new mandatory change for UK Cards and Wire Transfers programmes, i.e. where End Customers are offered workflows to create [GBP FPS] OWTs to third-party payees.

Affected programmes will need to make changes to the UX and logic of their OWT workflow to incorporate a Confirmation of Payee check, and ensure the results are displayed intelligibly to the End Customer, so they can decide whether to proceed with the payment (or amend or cancel it).

This new OWT flow splits the API calls so that the Weavr system can provide the CoP check result and await a confirmation from the end customer’s decision to proceed, which is followed by the SCA challenge.

This implementation of Confirmation of Payee must be ready for End Customers to use (as the only OWT flow available for GBP FPS) by 31 October 2024.

We will support Embedders making changes in live programmes to ensure the implementation is compliant and well-designed for end users to understand.

Documentation links:

• Overview of Confirmation of Payee (applies to GBP FPS OWTs)
• Please contact us for further documentation on the API and UX flow logic of OWT flows when implementing these changes
• Table of CoP responses and what to display to End Customers

Please note Confirmation of Payee does not apply to EU/EEA programmes and [EUR] SEPA payments, but a similar solution (Verification of Payee) will come into force in the second half of 2025.

Recommended implementation of withdrawal OWTs to Linked Accounts​

As noted above, UK Cards-Focused programmes will not be able to offer OWTs to End Customers except as “self-to-self” withdrawals to external accounts registered and verified as Linked Accounts. Applications in these programmes should not offer End Customers information or UX flows related to making OWTs to third parties.

Live UK programmes which previously offered OWT functionality and are now deprecating it should offer a revised UX flow for an End Customer creating a withdrawal transaction. The End Customer should be able to select one of their Linked Accounts as the payee, without being asked to edit the payee details.

Please contact us for specific documentation on the API and UX flow logic of withdrawal OWTs to Linked Accounts.

SCA verification endpoint now supports idempotency​

The following API endpoint can now (optionally) be called idempotently:

• POST /challenges/{scaChallengeId}/otp/{channel}/verify to verify a list of resources using a one-time password.

Further information on idempotency is provided in our API Docs here.

---

Upcoming Releases​

Breaking changes ahead of Sept/Oct 2024​

Our next breaking change release is planned to be released to Sandbox on Tuesday 24 September 2024. The release will remain on Sandbox for 3 weeks, and then we will release it to the Production environment on Tuesday 15 October 2024.

We will send out advance release notes in August to allow your team more time to prepare. If you have colleagues or partners who need to be in the know about Weavr release notes, please ask them to subscribe to emails here.

---

Product Updates​

Corporate email verification endpoint now supports idempotency​

The following API endpoint can now (optionally) be called idempotently:

• POST /corporates/verification/email/send to send an email verification code to the corporate root user

In this case, if the API receives a duplicate request (with the same idempotency-ref), the system will not send out the email multiple times.

Further information on idempotency is provided in our API Docs here.

Bulk processing capabilities - spend rules PATCH​

In the initial beta release of the Bulk Process, the ability to Update spend rules for a managed card was included as an operation that can be grouped together in a bulk. This endpoint was originally created as:

POST /bulks/managed_cards/_id_/spend_rules

but has now been updated to:

PATCH /bulks/managed_cards/_id_/spend_rules

to maintain consistency with the corresponding endpoint for an individual operation.

---

Service Updates​

Physical payment card fulfilment centre in EU​

We are glad to announce the availability of card printing and logistics based in the EU.

This will help reduce delivery times for EU-based cardholders compared to the main fulfilment centre in the UK.

If you have queries about card printing and delivery for your programme, including pricing, please contact your Account Manager, or open a support ticket, and we’ll be glad to assist.

Digital signature in KYB forms​

A reminder to Embedders that digital signatures on PDFs (such as via Docusign or Pandadoc) are acceptable for completion of various forms in the KYB process such as UBO declarations.

If you have any queries about the KYB process and documents/steps, please contact your Account Manager or open a support ticket and we’ll be glad to assist.

---

Product Updates​

KYB: Proof of ID document expiry process changes​

We are making a number of changes in this release to how we handle expiry of proof of ID (PoI) documents in KYC and KYB. Expiry refers to the “valid until” or “expires” date shown on the form of ID (such as a passport or national ID card).

The key points are as follows:

• Any Consumer with an expired PoI document will be restricted from transacting, after a reasonable time to react to support requests, until they return their KYC to good standing by providing a replacement/valid ID document (all else being in good standing).

• Any Corporate’s KYB good standing depends on the individual PoI documents being valid (not expired) for the Root User (/appointee), plus ALL of Ultimate Beneficial Owners (UBOs). All of the Corporate’s accounts/cards will be restricted from transacting if any of the required IDs are deemed to be out of date after attempts to alert the stakeholders, until brought back into good standing.

• In any actual restriction action Weavr will send a webhook and notification email as well as proactive support team engagement.

• The Embedder has the primary responsibility to communicate with End Customers and their representatives/stakeholders in advance of PoI expiry and in the event of documents having expired. Embedders' systems should provide one or more advance warnings to the relevant end customer contacts.

• Weavr will now send webhooks to the Embedder’s endpoint for every soon-to-expire PoI 30 days before expiry, 10 days before, and on the day of expiry. In addition a final warning is sent 10 days after the day of expiry. Embedders should use these webhooks to construct the relevant notifications for End Customer stakeholders.

• In addition to the above webhooks, Weavr will send emails directly to the affected Root User (or non-director Root User plus director appointing them). The email content is as follows and can be customised by the Embedder for their programme, on request via support ticket:

• The above email will be sent 30/10/0 days before as well as 10 days after the ID document expiry date.

• The 30/10 days before and 10 days after expiry timeframes are configurable per Embedder programme: please contact Weavr if you wish to make changes in this regard.

• Please note that any accounts currently affected by having one or more PoI documents already expired at the go-live date of this release, will already be subject to compliance case management with Embedder support teams. Any soon-to-expire cases after the go-live date will begin receiving reminders immediately.

Please read the full article on Proof of ID expiry to find out more (requires Weavr Support Portal login).

Sends and OWTs as bulk operations​

As announced in the last Release Note, we have introduced a capability to group multiple individual API-based actions into a batch of bulk operations; that are then executed and managed through the Bulk Process. This new feature is available to try out, on request (via support ticket or your account manager).

We have now added the following actions as bulk operations endpoints:

• POST bulks/sends - Create Sends in bulk.

• POST bulks/outgoing_wire_transfers - Create OWTs in bulk.

To complete these operations, a transaction confirmation challenge must also be completed, and so we have updated our Bulk Process documentation to describe this.

The previous endpoints that specifically served bulk Sends and bulk OWTs will be marked as deprecated, since these operations can now be managed as part of the standardised Bulk Process.

Cancel OWTs in state PENDING_CHALLENGE​

Previously, an Outgoing Wire Transfer (OWT) could be cancelled only if it was a scheduled (i.e. future-dated) transaction, at any time before the execution time. This is done by selecting the scheduled OWT transaction ID and cancelling it, optionally adding a cancellation reason.

With the updated POST /outgoing_wire_transfers/bulk/cancel endpoint, an OWT can be cancelled while it is still in the state PENDING_CHALLENGE, i.e. before the completion of the SCA challenge.

A single OWT or batch of OWTs can be cancelled in this way.

Therefore, Embedders can now add functionality to their OWT UX flow to offer account holders the ability to cancel an OWT at this stage, e.g. to go back, change details of the OWT, and start again.

Shared fees for Send transactions​

Currently, it is possible to configure and test various transaction fees in the Embedder Portal within the Sandbox environment. These fees are subject to checks and approval before they are applied in a live programme.

With this release we are adding a new fee mechanism for Sends (i.e. e-money payments between two different Identities' Managed Accounts under the same programme). Instead of a fee for a Send only being charged to the sender (the source account), some or all of the fee can now be shifted to the recipient (destination account).

New configuration is available in the Sandbox Portal to set up this kind of split/shared fees on Sends:

• Charge full fee to the source account,
• Charge full fee to the destination account, or
• Split fee between the source and the destination account: with the split being 50/50, or any percentage weighting you chose.

Fees that have been charged to End Customers in this way will be shown in their statements and transaction history - now, for both source and destination accounts.

Fees on Send transactions are specified on a Send Profile. The Send Profile is specified in the API call to initiate the transaction: therefore it is possible to have different Send Profiles for different fee approaches, and select the right one at the time of a transaction.

Embedders wishing to apply fee changes to a live programme should raise a change request via a support ticket.

Updating card spend rules as a bulk operation​

As announced in the last Release Note, one of the bulk operations to be included in the launch of the Bulk Process was the ability to bulk update spend rules across Managed Cards.

The Bulk Process, and specifically the ability to bulk update spend rules across Managed Cards, is now also available in the Back Office API.

The endpoint introduced is POST bulks/managed_cards/_id_/spend_rules.

Please contact Weavr support for guidance in testing out the new bulk operations features during this Beta phase.

Creation and delivery details for physical cards in Embedder Portal​

We have improved the Managed Cards detailed view in the Embedder Portal for programme administrators and support teams. This update provides more details about physical payment cards, which are set up by first creating a virtual card and then upgrading to physical:

• A timestamp indicating when the Managed Card was upgraded to a physical card,
• The manufacturing state of the card, and
• Delivery tracking details, if available.

The manufacturing states of a Card can be:

• REQUESTED: The upgrade of the card to physical has been requested.
• SENT_FOR_FULFILLMENT: The card has been sent for printing.
• DISPATCHED: The card has been manufactured and dispatched.
• DELIVERED: The card has been received and activated by the recipient.

Delivery tracking details are added when the manufacturing state is either DISPATCHED or DELIVERED.

Reminder: A Managed Card can be upgraded to a physical card by calling the Multi API endpoint POST /managed_cards/{id}/physical. For more information on setting up physical cards, please refer to our API guides.

Indication of which API key is used for webhook signing​

In previous release notes we noted how we are strengthening the mechanism of signing webhooks. Webhooks are signed using the Primary API Key of a programme. This key is now highlighted in the API Credentials list in the Embedder Portal:

The key marked as Primary is the one that has been active for longest. This applies to both Sandbox and live applications.

We recommend all Embedders move over to the new webhook signing / validation mechanism as soon as convenient.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of endpoints in the Multi API which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following Multi API endpoints can (optionally) be called idempotently:

• POST/corporates to create a Corporate Identity

• POST /consumers to create an Consumer Identity

• POST /multi/users/invite to send a user invite

• POST users/{user_id}/invite/consume to consume an invitation previously sent to the user

• PATCH /users/{user_id} to update details of a User

• POST users/verification/email/send to send an email verification code to an Authorised User

Further information on idempotency is provided in our API Docs here.

SSO for Embedder Portal​

We are now offering Single Sign-On (SSO) for the Embedder Portal on a Beta basis. Users will be able to log in to the portal using their company-provided authentication e.g. Google Workspace or Microsoft account.

This provides enhanced security and convenience for controlling access and adding/removing users from your organisation to work with the portal.

If you would like to participate in this Beta, please contact Weavr (via support ticket or your account manager).

---

Partner Notice​

Security reminder from Twilio Authy​

Please note that Twilio has recently announced an important update for Authy.

If your programme uses Authy for SCA or other 2FA please help communicate this to your end users with a reminder to update their app as soon as possible.