Skip to main content

2 posts tagged with "Authorised User"

View All Tags

Version 3.59.0

· 3 min read

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.

Version 3.57.2

· 2 min read

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)