API usage agreement
To the General terms and conditions for the Provision of Payment Services
- 2FA - Two Factor Authentication used for advanced account
protection and more secure sign-in.
- Account Agreement - the Electronic Money and Payment Account
Agreement concluded between the Institution and the Client.
- Agreement - this API Usage Agreement.
- API - application programming interface which is used as an
additional functionality to integrate the Client's Account
accessible via the Website, into the Client's system.
- API key - encrypted unique user identifier, which is generated upon
Client's request, to which particular authorizations for the
Client's Account usage are assigned.
- API technical specifications - detailed specifications of the API
functionalities, behavior, expected results, structure and
instructions on how the API should be integrated and used
effectively, which are accessible via
https://bankera.com/api-documentation/ or another
link, if provided by the Institution.
- Client - a legal entity (not a consumer) that has engaged into the
- Client ID - unique code assigned to the Client, provided to the
Client via an encrypted file.
- Client secret - authentication token which is used in addition to
the API key in order to authorize the Client with the authentication
server to avoid Client impersonation, provided to the Client via an
- General T&C - general terms and conditions of payment services,
which, together with all amendments and additions, constitutes an
integral part of the Agreement, shall be applied and interpreted
together with it, taking into account the context.
- IP address - an IP address that is indicated by the Client and
assigned to it as the main IP address which is used to access
Client's Account via API (the Client can select and specify several
- SCA - Strong Client Authentication used for card payments and
confirmation of money transfers.
- Other definitions used in the Agreement correspond to those
specified in the General T&C and the Account Agreement, Law on
Payments of the Republic of Lithuania, the Law on Electronic Money
and Electronic Money Institutions of the Republic of Lithuania
2. Subject matter, the set-up and principle of the functionality of the API
- API functionality is intended for the Client that wants to access
and use its Account opened in the Institution more easily by
integrating it into the software already used by the Client.
- The Client that wants to use API functionality must be verified and
- API integration procedure:
- The Client that wants to use API has to log in to its Account on
the Website and choose section "API" in the Account settings.
- Once the Client receives the message regarding the API, the
Client answers to it by specifying the IP address(-es) which the
Client plans to use for connecting to its Account on the Website
via API. This address may subsequently be edited by the Client
itself by confirming such an action with a 2FA.
- The Client shall implement the API functionality by itself in
accordance with the API Technical Specifications. An Institution
has a right to make changes to API Technical Specifications at
any time and in its own discretion by notifying about them in
the aforementioned reference 2 (two) weeks before they enter
into the force.
- In order to duly integrate the API functionality, the Client
- Know Client ID.
- Know the API key.
- Connect to API using a valid IP address (Article 2.3.2 of
- API functionality is provided in the API Technical Specification,
which may vary from time to time, depending on the functionalities
provided by the Institution. Institution does not take any
responsibility due to changes to the API functionality, which may be
change upon sole discretion of the Institution. Client is
responsible to follow up all the changes to and updates of the API
Technical Specification and adapt its systems and processes
- Institution may at any time terminate the provision of API service,
ability to access the API, with or without due notice.
- The Client is informed and duly understands that all payments
initiated through the API are made without further approval by 2FA
or SCA, therefore, the Client accepts and is duly responsible for
all the risks arising therefrom.
- API functionality is provided to the Client free of charge.
- The Institution shall not be liable for any damages arising from the
access to or use of the API, including but not limited to the
management of the respective Account through the API, following
instructions and / or codes provided in the API Technical
- The Institution takes no responsibility due to any downtime of the
API or any functionality of it, inability to access or use the API
or relevant services via API according to the API Technical
3. Obligations of the parties via use of the API
- The Client's obligations:
- Implement the API in accordance with the instructions presented
in Article 2.3 of the Agreement and continue to use the API
functionality in a fair and orderly manner.
- Use only valid IP address to connect to the API.
- Not to abuse the functionality of the API.
- Ensure the security and integrity of the Account and the
computer or interface accessible through the API.
- Be responsible for all actions performed through API
functionality in the Client's Account, including but not limited
to initiation of the payments, logins, usage of the Account,
processing of information contained in the Account.
- Be responsible for protecting Client's used technical measures,
software, data and other systems against viruses, malware and
other internet security risks.
- Ensure that by using the API functionality, the Client will not
expose the Institution to the malicious software or security
risks such as malware, trojans, viruses and any other material
which is malicious or technologically harmful either to API,
Institution or other clients of the Institution.
- Periodically, at least once a month, check the API Technical
Specifications in order to be aware of the planning adjustments,
and if there are any, make the necessary adjustments without
undue delay in the Client's part of the integration of the API.
- To comply with the security requirements listed in Article 4 of
- The Institution's obligations:
10. Execute payments initiated by the Client and allow other actions
indicated in Article 2.4 of the Agreement.
11. Maintain the functionality of the API, correct and make the API
updates and changes necessary for the proper functioning of the
12. Ensure the provision of main services as provided for in the
General T&C, the Account Agreement and other agreements signed
by the Parties when the services are provided to the Client
4. Security measures
- Each Client that decides to integrate API obliges to duly comply
with the minimum organizational and technical data security
requirements set herein that must be applicable within the Client's
organization. These security requirements are designed in order to
safeguard data that is processed via use of the API against
corruption, loss or access from unauthorized third party.
- Organizational security measures:
- Security policy and procedures for the protection of personal
- The Client should document a separate dedicated security
policy with regard to the processing of personal data. The
policy should be approved by management and communicated to
all employees and relevant external parties.
- The security policy should be reviewed and revised on an
- Roles and responsibilities
- Roles and responsibilities related to the processing of
personal data should be clearly defined.
- Clear appointment of persons in charge of specific security
tasks should be performed.
- Access control policy
- Specific access control rights should be allocated to each
role (involved in the processing of personal data) following
the "need to know" principle.
- An access control policy should be detailed and documented.
The Client should determine in this document the appropriate
access control rules, access rights and restrictions for
specific user roles towards the processes and procedures
related to personal data.
- Access rights should be reviewed on annual basis and revoked
as soon as they are no longer needed.
- (For High-risk cases) Roles with excessive access rights
should be clearly defined and assigned to limited specific
members of staff.
- Asset management
- The Client should have a register of the IT resources used
for the processing of personal data (hardware, software, and
network). The register could include at least the following
information: IT resource, type (e.g. server, workstation),
location (physical or electronic). A specific person should
be assigned the task of maintaining and updating the
- Roles having access to certain resources should be defined
- IT resources should be reviewed and updated on annual basis.
- Change management
- To ensure that all changes are recorded, tested, evaluated,
validated, implemented and verified, the Client should
establish and implement change management process. The
Client must assess whether changes in the current operating
environment affect existing security measures or require
additional risk mitigation measures. Such changes must be
implemented in accordance with the Client's documented
change management process.
- Software development should be performed in a special
environment that is not connected to the IT system used for
the processing of personal data. When testing is needed,
dummy data should be used (not real data). In cases that
this is not possible, specific procedures should be in place
for the protection of personal data used in testing.
- Data processors
- Formal guidelines and procedures covering the processing of
personal data by data processors (contractors / outsourcing)
should be defined, documented and agreed between the data
controller and the data processor prior to the commencement
of the processing activities. These guidelines and
procedures should mandatorily establish the same level of
personal data security as mandated in the organization's
- Upon finding out of a personal data breach, the data
processor shall notify the controller without undue delay.
- Formal requirements and obligations should be formally
agreed between the data controller and the data processor.
The data processor should provide sufficient documented
evidence of compliance.
- The data controller's organization should regularly audit
the compliance of the data processor to the agreed level of
requirements and obligations.
- (For High-risk cases) The employees of the data
processor who are processing personal data should be subject
to specific documented confidentiality / non-disclosure
- Incident handling / Personal data breaches
- An incident response plan with detailed procedures should be
defined to ensure effective and orderly response to
incidents pertaining personal data.
- Personal data breaches should be reported immediately to the
management. Notification procedures for the reporting of the
breaches to competent authorities and data subjects should
be in place, following art. 33 and 34 of GDPR.
- The incidents' response plan should be documented, including
a list of possible mitigation actions and clear assignment
- (For High-risk cases) Incidents and personal data
breaches should be recorded along with details regarding the
event and subsequent mitigation actions performed.
- Business continuity
- The organization should establish the main procedures and
controls to be followed in order to ensure the required
level of continuity and availability of the IT system
processing personal data (in the event of an incident /
personal data breach).
- A business continuity plan should be detailed and documented
(following the general security policy). It should include
clear actions and assignment of roles.
- Business continuity plans should be tested and updated
annually, based on test results from collected data on
threats and experience from previous events, as well as
changed recovery objectives and / or changed operational
functions, support processes and information resources.
- Confidentiality of personnel
- The Client should ensure that all employees understand their
responsibilities and obligations related to the processing
of personal data. Roles and responsibilities should be
clearly communicated during the pre-employment and / or
- Prior to up taking their duties employees should be asked to
review and agree on the security policy of the organization
and sign respective confidentiality and non-disclosure
- (For High-risk cases) Employees involved in high-risk
processing of personal data should be bound to specific
confidentiality clauses (under their employment contract or
other legal act).
- The Client should ensure that all of its employees are
adequately informed about the security controls of the IT
system that relate to their everyday work. Employees
involved in the processing of personal data should also be
properly informed about relevant data protection
requirements and legal obligations through regular awareness
- The Client should have structured and regular training
programmers for staff, including specific programmers for
the induction (to data protection matters) of newcomers.
- The Client should ensure that all of its employees receive
training at least once a year.
- Technical security measures:
- Access control and authentication
- The use of common user accounts should be avoided. In cases
where this is necessary, it should be ensured that all users
of the common account have the same roles and
- An authentication mechanism should be in place, allowing
access to the IT system (based on the access control policy
and system). As a minimum a username / password combination
should be used. Passwords should respect a certain
(configurable) level of complexity.
- A specific password policy should be defined and documented.
The policy should include at least password length,
complexity, validity period, as well as number of acceptable
unsuccessful login attempts.
- User passwords must be stored in a "hashed" form.
- Logging and monitoring
- Log files should be activated for each system / application
used for the processing of personal data. They should
include all types of access to data (view, modification,
- Log files should be timestamped and adequately protected
against tampering and unauthorized access. Clocks should be
synchronized to a single reference time source.
- Actions of the system administrators and system operators,
including addition / deletion / change of user rights should
- There should be no possibility of deletion or modification
of log files content. Access to the log files should also be
logged in addition to monitoring for detecting unusual
- A monitoring system should process the log files and produce
reports on the status of the system and notify for potential
- Server / Database security
- Servers should be configured in accordance with documented
standards / procedures.
- Server images should be reviewed, tested and kept up to date
(i.e. with recent patches and changes to build /
- Servers should be configured to protect against attacks by:
disabling unnecessary or insecure user accounts, changing
important security-related parameters from their default
settings, restricting physical access to a limited number of
authorized individuals, maintaining up-to-date malware
protection software, monitoring, and by reviewing them on a
- Database and applications servers should only process the
personal data that are actually needed to process in order
to achieve its processing purposes.
- (For High-risk cases) Encryption solutions should be
considered on specific files or records through software or
- (For High-risk cases) Encrypting storage drives should
- Workstation security
- Users should not be able to deactivate or bypass security
- Users should not have privileges to install or deactivate
unauthorized software applications.
- The system should have session time-outs when the user has
not been active for a certain time period.
- Critical security updates released by the operating system
developer should be installed regularly.
- (For High-risk cases) It should not be allowed to
transfer personal data from workstations to external storage
devices (e.g. USB, DVD, external hard drives).
- (For High-risk cases) Full disk software encryption should
be enabled on the workstation operating system drives.
- Network / Communication security
- Whenever access is performed through the Internet,
communication should be encrypted through cryptographic
- Wireless access to the IT system should be protected by
- Remote access to the IT system should in general be avoided.
In cases where this is absolutely necessary, it should be
performed only under the control and monitoring of a
specific person from the Client (e.g. IT administrator /
security officer) through pre-defined devices.
- The network of the information system should be segregated
from the other networks of the data controller.
- Backup and data restore procedures should be defined,
documented and clearly linked to roles and responsibilities.
- Backups should be given an appropriate level of physical and
environmental protection consistent with the standards
applied on the originating data.
- Execution of backups should be monitored to ensure
- Backup media should be regularly tested to ensure that they
can be relied upon for emergency use.
- Copies of the backup should be securely stored in different
- In case a third-party service for backup storage is used,
the copy must be encrypted before being transmitted from the
- Mobile / Portable devices
- Mobile and portable device management procedures should be
defined and documented establishing clear rules for their
- Mobile devices that are allowed to access the information
system should be pre-registered and pre-authorized.
- Mobile devices should be subject to the same levels of
access control procedures (to the data processing system) as
other terminal equipment.
- Personal data stored at the mobile device (as part of the
organization's data processing operation) should be
- Application lifecycle security
- During the development lifecycle best practices, state of
the art and well acknowledged secure development practices,
frameworks or standards should be followed.
- Specific security requirements should be defined during the
early stages of the development lifecycle.
- Specific technologies and techniques designed for supporting
privacy and data protection (also referred to as Privacy
Enhancing Technologies (PETs)) should be adopted in analogy
to the security requirements.
- Secure coding standards and practices should be followed.
- During the development, testing and validation against the
implementation of the initial security requirements should
- Vulnerability assessment, application and infrastructure
penetration testing should be performed prior to the
operational adoption. The application shall not be adopted
unless the required level of security is achieved.
- Periodic penetration testing should be carried out.
- Information about technical vulnerabilities of information
systems being used should be obtained.
- Software patches should be tested and evaluated before they
are installed in an operational environment.
- Data deletion / disposal
- Multiple passes of software-based overwriting should be
performed on all media prior to their disposal. In cases
where this is not possible (CD's, DVD's, etc.) physical
destruction should be performed.
- Shredding of paper and portable media used to store personal
data shall be carried out.
- (For High-risk cases) If a third party's services are
used to securely dispose of media or paper-based records, a
service agreement should be in place and a record of
destruction of records should be produced as appropriate. It
should be considered that the process takes place at the
premises of the data controller (and avoid off-site transfer
of personal data).
- Physical security
- The physical perimeter of the IT system infrastructure
should not be accessible by non-authorized personnel.
Physical barriers should, where applicable, be built to
prevent unauthorized physical access.
- Clear identification, through appropriate means e.g. ID
Badges, for all personnel and visitors accessing the
premises of the organization should be established, as
- Secure zones should be defined and be protected by
appropriate entry controls. A physical logbook or electronic
audit trail of all access should be securely maintained and
- Intruder detection systems should be installed in all
- Vacant secure areas should be physically locked and
- An automatic fire suppression system, closed control
dedicated air conditioning system and uninterruptible power
supply (UPS) should be implemented at the server room.
- The Client takes all the risk, responsibility and obligation to
cover possible damages if it does not follow the above-mentioned
- In such cases Institution takes no responsibility towards the Client
or any third parties, if there is damage caused sue to data leak,
compromised services or any other deficiency.
- Client is fully responsible towards the Institution and any other
third party, if any of its data is leaked or compromised or any
other deficiency occurred.
- The Institution may inspect the Client and ask to provide proof that
the aforementioned organizational and technical data security
requirements are being met within the Client's organization.
- In case the Client does not comply and ensure the organizational and
technical security requirements presented in this Article, the
Institution may cease the provision of API functionality, terminate
this Agreement and the Client may be obliged to cover all damages
incurred by the Institution, if any.
5. Compromise of authorization elements
- In the event the Client losses the confidentiality of any of the
authorization measures indicated in Article 2 of the Agreement,
which are used by the Client in order to access and use its Account
via API, or there is a serious threat or suspicion that such
authorization elements have become known to unauthorized third party
(f. e., there is a hack into the Client's system), the Client must
notify the Institution immediately.
- Once the Institution receives the Client's notification, the
Institution deactivates the API key and (or) removes the respective
IP address (indicated in Article 2.3.2 of the Agreement), which were
primary assigned to the Client, from the approved IP list so that it
would be impossible to further access Account via the API. Used API
keys are never used again. In case the Client requires, the
Institution could temporally or permanently block Client's Account
- The Institution takes all necessary measures it deems appropriate
and useful to prevent any possible consequences arising from
compromise of the Client's authorization elements, however, the
Client is solely responsible for ensuring the confidentiality and
security of its used authorization elements, access to API,
software, internet connection and any other technical measures the
Client uses. The Client is solely responsible for all consequences
arising out of such loss of confidentiality and security of
- This Agreement could be terminated on any grounds specified in the
General T&C or in the Account Agreement.
- The Institution without any prior notice may suspend or terminate
the Client's access and use of the API, as well as terminate this
Agreement in case there are obvious grounds to believe that the
Client has breached conditions of the Agreement.