The Cards section explains to the user how to manage card information associated with their accounts. Users can add, update, and remove cards, as well as retrieve details such as card number and expiration date. This section provides essential functionality for handling payment methods within the application. > **Note:** Deposits made to cards must be at least 10 USD to be processed.

Get all the information of a particular virtual card

Required access level: Read-Only Access (Level 1)

Returns all active cards.

Required access level: Read-Only Access (Level 1)

Remove and disable the selected card. After this action the specified card will be permanently disable and the action cannot be undone.

Required access level: Operational Access (Level 2)

Get all top-up wallets of a particular virtual card, this is only available for cards of type TOP_UP

Required access level: Read-Only Access (Level 1)

Get the PAN of the selected card as a link that needs to be embedded. The link generated can be open only once and it's time to live is of 60 seconds once opened.

Required access level: Operational Access (Level 2)

Updates the spending limits of a particular virtual card

Required access level: Operational Access (Level 2)

Required access level: Operational Access (Level 2)

Required access level: Operational Access (Level 2)

Override the virtual balance of a wallet associated with a virtual card. If the card already has a virtual balance, the specified amount will replace the existing balance. Only positive values and zero are allowed; negative values are not permitted.

This only works for virtual cards where the approval method is TOP_UP.

Required access level: Operational Access (Level 2)

This endpoint reverses the BLOCKED status of a card and reactivates it for use. Cards may be blocked because they exceeded the maximum number of attempts for entering incorrect PIN, CVV, or expiry date information.

Required access level: Operational Access (Level 2)

During a transaction authentication, the default option to verify the cardholder’s identity is to send a one-time password (OTP) via SMS. It can opt in for 3DS configuration.

By enabling 3DS Configuration, you can decide the method to receive a one-time password (OTP) via SMS or via Webhook (using the URL provide by the webhook configuration). This one-time password (OTP) is sent and is need it to validate the 3DS Challenge using the 3DS Authentication Respond endpoint.

Required access level: Operational Access (Level 2)

When an online transaction is triggered, the cardholder may or may not need to authenticate their identity as an extra step to ensure this transaction is 3DS certified. Use this endpoint to respond to a notification which we sent you when a 3DS authentication for your card. You need to response using the code with this endpoint within 5 minutes from the transaction timestamp otherwise will be failed.

Required access level: Operational Access (Level 2)

This endpoint allows for the freezing or unfreezing of the card.

Required access level: Admin Access (Level 3)

This endpoint allows to update the PIN for the specific card. The PIN must follow these rules:

• Length: 4–12 digits.

• Non-consecutive identical digits: No more than two identical digits in non-consecutive positions (e.g., 124758).

• Consecutive repeated digits: No more than two repeated digits in a row (e.g., 112441).

Required access level: Admin Access (Level 3)

This endpoint allows you to generate a new number, CVV and expiry date for a given card.

When a card with a givencardID is lost, damaged or suspected of fraudulent use, this endpoint will generate a new number, CVV and expiry date for your card with the same cardID.

If the card was previously tokenized and provisioned to a mobile wallet (e.g. Google Pay), the newly created card should remain linked to the mobile wallet. However, for subscription-based services, the cardholder may need to re-enter the new card details and verify the card again. While the 16-digit Number, CVV, and expiry date will change, the cardIdremains the same as well the balance, movements and other information will remain unchanged.

Required access level: Admin Access (Level 3)

This section comprises all the API endpoints to interact with Virtual Wallet, which is the entry point for the user to make deposits on any available blockchain.

A Holding Wallet is a wallet that is created when the user requests to create their first virtual wallet for a given blockchain. This wallet will be used to centralize all deposits made to all virtual wallets on such blockchain. Whenever a deposit is done on a Virtual Wallet, the tokens get transferred to the Holding Wallet almost immediately.

This module allows users to get a Holding Wallet balance, information (Alias, address and id) and to withdraw tokens from it.

Configuration is a group of endpoints that allows users to manage and query system settings.

This module offers customers the possibility to generate Virtual Wallets on various blockchain networks to send, receive and record balances and movements. It simplifies the management of digital assets and allows to establish automated rules for user flows. All the assets will be stored on a Holding Wallet that will be created when the first Virtual Wallet is created. There is only one Holding Wallet for each blockchain. When a deposit is made to one of the addresses it will accredit it instantly. These Virtual Wallets will have a virtual balance, which represents the amount of tokens that belongs to those addresses. > **Note:** Deposits made to virtual wallets must be at least 1 USD to be processed.

Virtual Wallets:

Virtual wallets are interfaces that allow users to interact with the blockchain in a more accessible and user-friendly way without the need to directly manage the private keys associated with their digital assets. This reduces the technical complexity and risks associated with the loss or mismanagement of these keys, making blockchain technology more accessible to the average user.

Virtual Wallets also have the capability to be deactivated, ensuring that they do not occupy space within the pool of available virtual wallets. This feature allows for better management and allocation of resources, ensuring that only active and necessary wallets consume system resources.

Holding Wallet:

At the core of the Virtual Wallet infrastructure is the Holding Wallet. This is a unique wallet designated for each blockchain, where all users’ digital assets are stored. The Holding Wallet is responsible for managing the actual funds and executing transactions on behalf of the Virtual Wallets. This centralized approach allows for greater security and efficiency in the management of digital assets.

Virtual Balance:

Virtual Wallets display to users a virtual balance that reflects the amount of tokens allocated to their specific addresses. However, these real assets are centrally stored in the Holding Wallet. This virtual representation allows for more agile and secure management, eliminating the need for users to interact directly with the blockchain for each operation.

Instant Transactions:

One of the key benefits of Virtual Wallets is the ability to perform instant transactions from the user’s perspective. When a deposit is made to a Virtual Wallet address, the balance is updated immediately in the user interface, providing a seamless and delay-free experience. Meanwhile, the underlying transaction on the blockchain is processed in the background and may take a bit longer to confirm, depending on network congestion and conditions.

User Flow Automation:

Virtual Wallets also offer advanced automation capabilities, allowing users to set customized rules for managing user flows. This can include setting up automatic transfers, alerts, and notifications, among other features that significantly enhance the user experience. Automation reduces the need for manual intervention, making digital asset management more efficient and secure.

Financial Management:

The Holding Wallet plays a critical role in financial management. It allows for partial withdrawal of the balance, keeping a reserve ratio against the Virtual Wallets, which facilitates the handling of user funds to generate additional benefits. It is essential to maintain a guarantee fund within the Holding Wallet to ensure that customer withdrawals are always covered. Failing to do so would result in insufficient funds errors when attempting withdrawals.

Moreover, if assets are transferred from the Holding Wallet to a Virtual Wallet, the balance of the latter will be updated even if the Holding Wallet does not have sufficient funds to cover that amount. This mechanism can create leverage by effectively using capital beyond the immediate balance of the Holding Wallet.

The treasury module offers you a seamless way to integrate the functionalities of a decentralized wallet, along with the capability to send and receive your crypto assets. This module covers everything from setting up a single wallet to managing multiple ones, all without delving into the complexities of web3.0 terminology. This ensures a smoother integration and user experience overall. > **Note:** Deposits made to treasury wallets must be at least 1 USD to be processed.

The Management API is your all-in-one powerhouse for steering the ship of account management. It functions as a sophisticated toolkit, empowering users to seamlessly create, tweak, or bid farewell to clients, accounts, users, and access levels. Acting as a refined interface, it grants users granular control over the organizational account landscape, facilitating tasks such as spinning up new clients or tweaking existing configurations on the fly. Need to sculpt user accounts to fit the evolving needs of your operation? You got it. It doesn’t stop there – the API lets you fine-tune access levels, ensuring a secure and compliant environment. And when it’s time for some digital spring cleaning, the API’s deletion functionalities let you tidy up by retiring entities that have overstayed their welcome. It’s like having a backstage pass to the techy side of account management without the fuss.

For using this API you need to use your API key that have MANAGEMENT permission.

The Management API is your all-in-one powerhouse for steering the ship of account management. It functions as a sophisticated toolkit, empowering users to seamlessly create, tweak, or bid farewell to clients, accounts, users, and access levels. Acting as a refined interface, it grants users granular control over the organizational account landscape, facilitating tasks such as spinning up new clients or tweaking existing configurations on the fly. Need to sculpt user accounts to fit the evolving needs of your operation? You got it. It doesn’t stop there – the API lets you fine-tune access levels, ensuring a secure and compliant environment. And when it’s time for some digital spring cleaning, the API’s deletion functionalities let you tidy up by retiring entities that have overstayed their welcome. It’s like having a backstage pass to the techy side of account management without the fuss.

For using this API you need to use your API key that have MANAGEMENT permission.

The Simulate section allows users to test and replicate transaction events within the API Layer using the account’s configured mechanisms. By simulating transactions, users can ensure that the API functions correctly and accurately reflects real-world scenarios. This section is essential for developers to validate the behavior of their applications and ensure seamless integration with the API Layer.

Webhooks provide real-time notifications for API events, enabling your platform to receive timely updates about specific activities. Our system sends these notifications to a designated endpoint within your hosted environment, which is configured to adeptly receive and process them.

Leverage webhooks to promptly obtain information about critical API events. These events include occurrences external to your system, such as a new deposit in an MPC wallet or a card transaction at a point-of-sale (POS) terminal.To seamlessly receive and process webhook-enabled events, you need to establish and configure a webhook endpoint within your environment.

Each webhook request consists of a common part and a custom payload specific to the event being communicated. The common part includes standard information such as the event type, sub-type, status and a unique Id of of the notification, while the custom payload contains detailed data relevant to the specific event.

General payload example:

{
"operation": "TREASURY",
"sub_operation": "DEPOSIT",
"operation_id": "ca0c57d2-b1c9-4bcd-9d5d-8d361cad6fddds1c",
"status": "FINISHED",
"data": { }
}