Introduction
Reference and guides for the Sovera card-issuing platform: users, wallets, cards, transactions, credit and webhooks.
Welcome to Sovera's API documentation, a comprehensive and flexible platform designed to enable businesses and developers to easily integrate banking and financial services into their applications and systems.
Our API is built as a REST interface. The main benefit is that it accepts form-encoded request bodies and returns JSON-encoded responses, using standard HTTP response codes which should make our API familiar to anyone with previous experience using APIs.
Response format
Every endpoint returns a consistent envelope (success / data / meta) and a standard error format. Read Responses & Errors first — the per-endpoint pages document only their data payload.
Use this documentation as a guide to execute tasks such as:
- Creating natural and legal type users. (Check Users)
- Creating wallets for each user you create. This option will be useful if you are going to integrate pre-funded credit type cards or if you want to manage more than one wallet per user. (Check Wallets)
- Managing balances of wallets created through PayIns, PayOuts, and Transfers between wallets. (Check PayIns, PayOuts and Transfers)
- Creating cards linked to the created wallets. (Check Cards)
- Managing created cards. (Check Card Lifecycle and PIN)
- Registering a Callback URLs for event notifications (Check Notifications Enlist)
- Retrieving transactional data. (Check Transaction Data Retrieval)
Card creation is done through different endpoints for debit, credit, and prepaid cards.
In the initial product exploration, our commercial team will gather the specifications of the card product to be issued. Our integration team will provide a related
clientCodefor each card product required, this is a unique code for your assigned card profile that should be included in the card creation calls.
Sandbox Access and Authentication
To start an integration process, you must first request integration API Keys by contacting [email protected]. After initial scoping and onboarding processes, sandbox API keys will be delivered via email to the technical responsible party.
Handling the keys is of great importance and it is the responsibility of the key recipient to keep them safe. Secret keys must not be shared on any publicly accessible site such as GitHub, client-side code, etc.
Authentication to the API should be performed via X-API Key. It is necessary to provide the API Key as the basic user value, without the need to provide a password.
All calls must be made via HTTPS; any call made via HTTP or without authentication will fail.
With the integration credentials, you will be able to make calls to Sovera API testing environment directly.
Entity Structure
Sovera API has 3 fundamental entities with which you will interact each time you consume an endpoint to complete the various available flows. These entities identify the end users of the card issuance service, the wallets or virtual containers for money, and the cards associated with them.
-
UserID: Uniquely identifies an EndUserIntegrated or MerchantUserIntegrated interchangeably. The UserID is the primary entity of the Sovera API. The process of creating an EndUserIntegrated or MerchantUserIntegrated always results in the creation of a UserID and, in turn, an associated WalletID.
-
WalletID: The WalletID is the identifier of the electronic money container to which funds are credited and debited through PayIns, PayOuts, and/or transactions of the card(s) associated with it. A UserID will always be associated with at least one WalletID; however, it may contain multiple WalletIDs if required by the client's solution.
-
CardID: These are the unique identifiers of the card that also serve as an abstraction of the PAN of the issued cards, avoiding the need for storing sensitive card information.