Terms and Conditions
Welcome to ZTL!
These Terms and Conditions (“Terms“) govern the use of ZTL’s Payment Solution and related services, which are integrated via APIs with the Partner’s Software Solution. In addition to these Terms, the Partner and ZTL have entered into the ZTL partner agreement (the “Partner Agreement”). Together, these Terms and the Partner Agreement constitute a legally binding agreement between ZTL and the Partner (each as identified in the Partner Agreement) regarding the integration and use of ZTL’s Payment Solution (the “Agreement“).
These Terms outline the rights and responsibilities of both ZTL and the Partner in relation to the integration and use of ZTL’s Payment Solution under the Agreement.
ZTL may update these Terms periodically to reflect changes in services, legal requirements, or business operations in accordance with the terms set out in section N. Any modifications will be posted on this page.
In the event of any conflict or inconsistencies between these Terms and the Partner Agreement, the terms of the Partner Agreement shall prevail.
For more details regarding policies, including privacy and data protection, please review the Privacy Policy. Any questions regarding these Terms should be directed to ZTL
Definitions
Capitalized terms used in these Terms, which are not otherwise defined herein, shall be interpreted as follows:
API | Means an application programming interface consisting of a set of functions and protocols for building and integrating application software. |
Payment Services | Means conduction money transfers from one bank account to another initiated by the End Clients’ use of the Payment Solution, as further described in the ZTL Documentation Portal. |
Intellectual Property Rights | Means current and future rights under applicable patent, copyright, trademark, design, marketing, database and other law as well as other similar registrable or non-registrable rights. |
Personal Data | Means any information relating to an identified or identifiable natural person explicitly defined as a regulated category of data under the applicable Data Protection Law (as defined above). |
Implementation Project | Means the project that establishes an interface between the Software Solution and the Payment Solution, making the Payment Solution available to the End Clients, as an integrated functionality in the Solution. |
Claim | Means any and all claims, losses (including economical losses), demands, taxes, liens, liabilities, judgments, awards, provisional injunctions, remedies, debts, damages, injuries, costs, legal and other expenses, or causes of action of whatsoever nature, and in whatever jurisdiction the foregoing may arise. |
Payment Solution Aggregate Data | Means any report, statistic, pattern, log, trend, database, metadata and similar high-level collection of data generated by the use of the Payment Solution, which is neither Authorised User Data nor Personal Data. Fully anonymized data from Authorised User Data or Personal Data included as part of Payment Solution Aggregate Data will be considered parallel data sets and be independent from their original datasets for the purpose of title and ownership. |
Authorised User Data | Means any content, materials, data, Personal Data or other information uploaded or otherwise introduced to the Payment Solution and/or the Software Solution by an Authorised User in relation to its use of the Payment Solution and/or the Software Solution. |
Software Solution | Means the Partner’s application through which the Partner will provide access to the Payment Solution for the End Clients. |
Payment Solution | Means ZTL’s solution including its APIs for pricing and processing payments as further detailed in the solution description provided in the ZTL Documentation Portal to which the Partner has been provided access by ZTL. |
Financial Services Regulations (FSR) | Means all laws, regulations, policies and standards etc. applicable to the provision of financial services through the Payment Solution, including (a) the Financial Institutions Act 2015 (Nw: Finansforetaksloven); (b) the Anti-Money Laundering Act 2018 (Nw: Hvitvaskingsloven); (c) the Financial Contracts Act 1999 (Nw: Finansavtaleloven); (d) the Payment Services Regulation 2019 (Nw: Forskrift om betalingstjenester); (e) the Systems for Payment Services Regulation 2019 (Nw: Forskrift om systemer for betalingstjenester); (f) the Regulations on Risk Management and Internal Control 2008 (Nw: Forskrift om risikostyring og internkontroll); and (g) instructions and guidance issued by the Financial Supervisory Authority (FSA) (Nw: Finanstilsynet). |
Data Protection Law | Means (a) the General Data Protection Regulation 2016/679 (GDPR); (b) the Norwegian Personal Data Act 2018 (In Norwegian (“Nw”): Personopplysningsloven); and (c) and any other laws, regulations, policies and standards applicable to the processing of Personal Data (as defined below) implementing and/or supplementing the aforementioned. |
Software Solution Aggregate Data | Means any report, statistic, pattern, log, trend, database, metadata and similar high-level collection of data generated by the use of the Software Solution, which is neither Authorised User Data nor Personal Data. Fully anonymized data from Authorised User Data or Personal Data included as part of Software Solution Aggregate Data will be considered parallel data sets and be independent from their original datasets for the purpose of title and ownership. |
ZTL Documentation Portal | Means the digital documentation repository maintained by ZTL to which the Partner is given access under this Agreement, electronically available at https://docs.ztlpay.io/#getting-started . |
Authorised User | Means a user of the Software Solution that subscribes to, accesses and uses the Payment Solution. |
Release(s) | Means the planned roll-out and implementation of updates, improvements and further developments to the Payment Solution in its production environment, as further detailed in clause 7.3. |
Information Services | Means the account information services which ZTL shall offer to provide to the End Clients in addition to or independent of the provision of Payment Services, as further described in the ZTL Documentation Portal. |
End Clients | Means the customers using the Payment Solution for Payment Services. |
Roll-out date | Means the mutually agreed date in the implementation plan where ZTLs Payment Solution is made available to a larger group of end-clients, following a successful pilot phase |
Regulatory Requirements | Means all regulations, laws, policies, standards and instructions from supervisory authorities applicable to the Payment Solution, the Software Solution and/or the processing of data therein (as required by the context), including the Data Protection Law and Financial Services Regulations. |
General
The rights and remedies (Nw: misligholdsbeføyelser) available under Norwegian law apply to this Agreement with respect to default (Nw: kontraktsmislighold).
Notification of defaults
Whenever one of the parties becomes aware of defaults or may reasonably expect that there is a risk of defaults, the first party shall give notice to the other party in writing, specifying the underlying reasons therefore. If possible, the defaulting party shall also state the possible consequences of the default and at what time performance can take place, if applicable.
Remedies for default
Subject to the provisions set out in clause 12 below, a party may claim damages in respect of any direct loss that can be reasonably attributed to default on the part of the defaulting party, unless the defaulting party demonstrates that the default is caused by the other party or by force majeure.
In case of material default by either party, the non-defaulting party may terminate the Agreement for cause in accordance with clause below. (“Termination for cause”)
Business Model
The business model is built upon ZTL Payment Solution providing the Payment Solution through the Software Solution to strengthen the Partner’s offering. Providing an interface for the Payment Solution into the Software Solution will aim to make the payment process smoother for the End Client. The Partner is not allowed to share data extracted from the APIs with any third parties other than the End Client without prior written approval from ZTL, except to the extent that Partner’s Software Solution may be hosted in public cloud services such as among others Amazon Web Services or Microsoft Azure,.
The Payment Solution will use liquidity bank(s) for international payments and API gateways for communication with the banks
Implementation Project
In order to enable ZTL to provide End Clients access to the Payment Solution, the parties shall in cooperation carry out an Implementation Project to successfully connect the Software Solution and the Payment Solution in addition to establish and develop marketing and roll-out plans, ready for execution when the implementation phase is done. ZTL will provide access to APIs and environments and will walk through relevant documentation with the Partner’s Development team, enabling the Partner to connect the Software Solution to the Payment Solution. The timeline and scope of the Implementation Project, including the responsibility allocation and each party’s deliverables, is further described in Appendix 1 (Implementation Project).
SCOPE
The Partner is responsible for connecting the Software Solution to the Payment Solution through the Payment Solution’s standard APIs. ZTL will support the Partner in this work through giving access to the ZTL Documentation Portal as well as access to the APIs and corresponding environments. ZTL will in addition present and walk through the API connections and technical infrastructure for the Partner’s Development Team. After successful connection to the Payment Solution, the Partner will execute an acceptance test, defined by ZTL, before the Partner can start roll out to the End Clients.
DELIVERABLES
ZTL and the Partner agree to run the implementation project as efficiently as possible.
COOPERATION
Both parties will contribute to a successful Implementation project to connect the Software Solution to the Payment Solution. The execution of the project will start with a common Kick-off to secure common understanding of the technical infrastructure and implementation plan. A meeting plan will be set to facilitate cooperation and communication between the Parties and resolve any impediments for meeting the overall implementation plan. Agreed frequency of Steering Committee meetings with ZTL and the Partner will be organised during the implementation and roll out phase.
Support & Maintenance
Maintenance and support
The Payment Solution is developed as a multitenant software as a service (“SaaS”) solution hosted in a cloud environment containing the same version of the service for all its End Clients.
ZTL and the Partner will each be responsible for managing the hosting environments for the Payment Solution and the Software Solution, respectively, including monitoring the hosting environments for unauthorized attacks and other threats.
ZTL is responsible for the maintenance and support of the Payment Solution and its functionality as further described in Appendix 2. The Partner is responsible for the maintenance and support of the Software Solution and the Software Solution’s implementation of the Payment Solution. ZTL and the Partner are each separately responsible for maintaining Payment Solution-side or the Software Solution-side (as applicable) system interfaces in accordance with specifications and notifying the other party if there is reason to believe that there is a risk of errors on the side of the other party.
(iv) ZTL and the Partner may perform maintenance that leads to a non-availability of the Payment Solution or the Software Solution, respectively, in specific time windows. Such maintenance windows shall be duly notified to the other party in advance. Planned non-availability shall not be taken into account for the purposes of calculating the Payment Solution availability in accordance with Appendix 2.
Further Development and API compliance
ZTL will make updates, improvements and further developments to the Payment Solution available in the form of planned Releases in accordance with ZTL’s product road map and plans. A new Release may contain both functional and technical changes and enhancements to the Payment Solution. ZTL will communicate such new Releases, its content and dates for availability in advance. A Release may contain changes affecting the APIs between the Payment Solution and the Software Solution requiring the Partner to make changes to the Software Solution-side APIs, in order for such APIs to remain functional and the Payment Solution to remain available to the End Clients. A Release affecting the APIs will be announced with a longer lead time in order for the Partner to ensure API compliance before the Release date. It is the Partner’s sole responsibility to ensure continued Software Solution-side API compliance when required by the implementation of Releases. If the Partner is not able to comply within Release date, the Partner may request to postpone the Release. ZTL will in good faith try to accommodate the request. Further, it is the Partner’s responsibility to ensure that the Software Solution’s integration with the Payment Solution standard APIs is performed and maintained in a manner ensuring that Releases which do not affect the functioning of the APIs, will not cause API non-compliance with the Partner. The Partner will cover commercially reasonable cost for any changes to the Software Solution or Software Solution-side APIs related to the integration of new Releases.
The Partner may request changes to the Payment Solution. Such requests from the Partner shall be submitted to ZTL’s Product Manager. These changes will be evaluated in accordance with ZTLs change handling process and be considered for inclusion in the Payment Solution’s future development roadmap and backlog. Changes suggested by the Partner may be implemented at ZTL’s sole discretion and convenience. ZTL is entitled to amend the functionality of any changes requested by the Partner to fit the Payment Solution or decide that the change will not be implemented. ZTL will provide a written explanation of its reasoning if it decides not to proceed with a change requested by the Partner. In such circumstance of non-implementation of material features the Partner may terminate the agreement on 3 months written notice
Delivery of an ‘as-is’ and ‘as-available’ service
ZTL provides the Payment Solution on an ‘as-is’ and ‘as-available’ basis only. The availability of the service is described in Appendix 2. ZTL does not make any warranty that the use of the Payment Solution will be uninterrupted or error free and undertakes no obligations to remedy defects in the Payment Solution other than the service levels offered for the Payment Solution in accordance with Appendix 2.
The parties acknowledge that the Payment Solution is dependent on functionality and services provided by third parties, except those directly subcontracted, over which ZTL has no control (e.g. MPS, BankID, End Client house banks, receiving banks etc.). The Parties agree that ZTL shall not, except for gross negligence by ZTL, be held liable for down time-related costs or claims as a result of errors, faults or non-availability in the Payment Solution, the Payment Services or the Information Services to the extent caused by faults in such third-party functionality or services, or the non-availability thereof. In any technical integrations between ZTL’s own systems and such third parties, ZTL is responsible for its part of the integration technical chain. ZTL is further responsible for following up, coordinating, and escalating towards such third parties, and all costs for such follow ups and escalations, as set out in Appendix 2. The aspects in 7.3) must be back-to-back declared by ZTL in the end user terms of service.
1 SERVICE AND SUPPORT
ZTL and the Partner have agreed on connecting each other’s support teams by giving the Partner’s support staff access to the ZTL Service Desk, and enable the Partner to receive and forward service requests and incident reports concerning the Payment Solution from the End Clients.’
The Partner is responsible for providing first line support to End Clients who are using the Payment Solution. It it’s the Partner’s responsibility to ensure that its Support staff is adequately trained to both answer questions from End Clients as well as determine if a defect needs to be raised with ZTL for further investigations.
The ZTL Support Model is defined and organized in three levels;
a) ZTL Service Desk
First point of contact with support for the Partner’s staff to contact. They create tickets in ZTL’s Support Help Desk system for reporting issues and incidents. Queries and Enhancement suggestions will also be reported in the Help Desk system in accordance with the applicable service levels set out in clause 2(i) below. The Service Desk is open within ZTL’s regular business hours, which are 08.00–16.00 CET/CEST. Opening hours for irregular periods will be published on ZTL’s website.
b) ZTL 2nd line support
Support tickets that cannot be resolved by ZTL Service Desk are allocated to ZTL 2nd line support (2LS), who are able to access and have technical knowledge to troubleshoot the Payment Solution and rectify a problem if so required. 2LS is primarily staffed with developers and senior personnel with in-depth knowledge of the Payment Solution.
c) Third-parties’ support
Third-parties support is a part of ZTL’s Support Model. ZTL has established collaboration with mirrored service level agreements towards any of the parties who are a business-critical part of the Payment Solution.
All incidents, queries and other reports shall be submitted to the ZTL Service Desk using the ZTL Support Help Desk.
ZTL Support Desk will follow its internal Incident management procedure for incidents raised to the Payment Solution.
2 SERVICE LEVELS – SUPPORT
(i) The ZTL support services will be provided in accordance with the service levels set out in the table below:
(ii) In the event of a category A-Major incident, ZTL Service Desk shall always be contacted.
Service availability is measured on a calendar-month basis and classified according to the following Availability Tiers:
Tier Monthly Availability Status
≥ 99.9% Green Target Availability≥ 99.5% and < 99.9% Yellow Degraded Availability< 99.5% Red Material Degradation
(Total minutes in the month − Downtime) ÷ Total minutes in the month × 100
“Downtime” means periods during which the core Services are fully unavailable due to an error or failure within ZTL’s direct control.
Operational Response by Tier
In the event that the applicable Availability Tier is not achieved, ZTL’s obligations are limited to the following operational measures:
Green: No action required.
Yellow: ZTL will, upon request, provide a written incident summary and a high-level remediation plan.
Red: ZTL will provide a root-cause analysis and a corrective action plan outlining reasonable mitigation measures and indicative timelines.
Exclusions
The following are excluded from Downtime calculations:
Scheduled maintenance communicated in advance;
Emergency maintenance required to protect the integrity or security of the Services;
Interruptions caused by third-party services or infrastructure, including cloud providers, payment networks, authentication services, or telecommunications providers;
Client systems, integrations, misuse, configuration errors, or network failures;
Force majeure events.
Maintenance
ZTL may perform planned or emergency maintenance as required. Planned maintenance will, where reasonably practicable, be scheduled outside normal business hours and communicated in advance.
No Warranty
Except as expressly stated in these terms, the Services are provided on an “as available” basis. Availability targets represent operational objectives only and do not constitute warranties or guarantees.
SANDBOX ENVIRONMENT AND DEVELOPER SUPPORT
(i) The ZTL Sandbox environment is a technical environment meant for the Partner to test against when integrating the Software Solution to the Payment Solution and for ZTL to do demonstrations when needed. The Partner will also use the environment for future tests and verifications released to new features or fixes being made available.
(ii) ZTL will support this environment with best effort SLA and enquiries will normally be answered during workdays between 09:00 and 15:00 CET/CEST in a dedicated Slack channel.
(iii) ZTL will provide the Sandbox environment with test data that is relevant for the Software Solution verification. ZTL does not guarantee test data to be kept in the environment over several days – test data can be reset at any given time.
(iv) ZTL will not work with DPA nor GDPR compliance in the Sandbox environment. The Partner has the responsibility to use the environment and test data appropriate for this purpose only.
Compliance
General
(i) ZTL acknowledges and agrees that it is solely responsible for complying with any Regulatory Requirements applicable to the Payment Solution and any Authorised User Data processed or generated in the Payment Solution.
(ii) Partner acknowledges and agrees that it is solely responsible for complying with any Regulatory Requirements applicable to the Software Solution and any Authorised User Data processed or generated in the Software Solution.
Financial Services Regulations (FSR)
(i) ZTL shall have the overall responsibility for compliance with the Financial Services Regulations in relation to the provision of the Payment Solution to the End Clients.
(ii) ZTL will be responsible for all necessary FSR-compliance tasks including carrying out the required strong customer authentication (“SCA”), know your customer (“KYC”) and anti-money laundering (“AML”) procedures. To the extent allowed by law, the Parties shall cooperate in order to further improve all aspects of FSR-compliance, including fraud detection procedures.
(iii) ZTL will carry out the FSR-compliance functions and collect the necessary data in this regard itself or through the use of subcontractors, either directly in the Payment Solution, or by redirecting the End Client to the appropriate websites (e.g. the End Client’s house bank’s authentication portal of choice).
(iv) The Partner agrees to execute such instructions and implement such changes as are deemed necessary by ZTL to ensure that ZTL is able to provide the Payment Solution through the APIs with the Software Solution in compliance with the Financial Services Regulations and/or instructions from the Norwegian FSA at all times.
Personal Data
(i) ZTL is responsible for compliance with the applicable Data Protection Law in connection with the processing of Personal Data in the Payment Solution.
(ii) Partner is responsible for compliance with the applicable Data Protection Law in connection with the processing of Personal Data in the Software Solution.
(iii) ZTL acts as a Personal Data controller (as defined under the Data Protection Law) with respect to the End Clients’ use of ZTL’s Payment Service. The End Clients will authorise the transfer of data from and to the Software Solution in connection with the End Client onboarding process.
(iv) In connection with ZTLs provision of the Payment Service to the End Clients, the Partner will, on ZTL’s behalf, handle the receipt of service requests and incident reports from End Clients concerning their use of Payment Solution and forward such requests and reports to ZTL’s support team (as further described in Appendix 2). The Partner’s handling of the receipt of End Client service requests and incident reports concerning the Payment Solution means the Partner will process certain Personal Data concerning the Authorized Users or other relations of the End Clients on ZTL’s behalf. In this respect, the Partner will be acting as a Personal Data processor (as defined under the Data Protection Law) and shall enter into a separate data processor agreement with the End Clients. The parties have consequently entered into terms consistent with a data processing agreement as a part of this Agreement, included as Appendix 4 and Appendix 5 hereto.
(v) The parties agree that in case of conflict between the data processing agreement and any other contractual document entered into between ZTL and the Partner concerning the Partner’s processing of Personal Data on behalf of ZTL, the provisions of the data processing agreement shall prevail.
(vi) If the Partner is to provide ZTL with services and/or data not related to the Payment Service, the parties will need to enter into a separate Data Processing Agreement
IT Security
(i) Both parties shall ensure that their respective solutions meet all regulatory security requirements and any additions reasonably required by the other part
(ii) ZTL is responsible for ensuring the applicable information security requirements during the End Clients’ transaction, while the Partner shall be responsible for ensuring the same before the transaction is initiated and after it is completed.
(iii) In order to ensure compliance with the applicable Financial Services Regulations, the Partner shall implement any reasonable changes to the Software Solution that ZTL deems necessary to ensure that the End Clients’ use of the Payment Solution is in accordance with regulatory requirements and ZTL’s information security policy.
Audits
(i) The Partner and ZTL agrees to submit to, and within reasonable notice time participate in audits performed by an independent third party appointed by the other party, or any supervisory authority (including the Financial Supervisory Authority) to the extent necessary to fulfil each party’s obligations pursuant to the Regulatory Requirements and/or demonstrate that the Payment Solution or the Software Solution is in accordance with the same.
Changes due to the Regulatory Requirements
(i) To the extent that changes in the Regulatory Requirements requires changes to the interfaces between the Payment Solution and the Software Solution, each party shall cover its own cost for such changes.
Intellectual Property Rights
All Intellectual Property Rights belonging to a party prior to signing of this Agreement shall remain vested and remain the property of that party.
Under the Agreement ZTL will own all right, title and interest, including all Intellectual Property Rights, in and to: (a) new functionality of the Payment Solution; (b) Authorised User Data generated in the Payment Solution; (c) Payment Solution Aggregate Data; (d) ZTL’s trade secrets; and (e) any application interfaces created by ZTL to accommodate the integration of the Payment Solution with the Software Solution, and other developments designed to facilitate the interaction between the two.
Both Parties agree that the other Party is free to use, in perpetuity and without additional consideration, any suggestions, ideas, enhancements requests, feedback, recommendations or other information provided by the other Party pertaining to each Party’s Intellectual Property Rights for the purpose of refining and/or further developing such Intellectual Property Rights without affecting each party’s rights therein.
Under the Agreement the Partner or the End Customer (as applicable, and as agreed between the Partner and the End Customer) will own all right, title and interest, including all Intellectual Property Rights, in and to: (a) new functionality in the Software Solution; (b) Authorised User Data generated in the Software Solution; (c) Software Solution Aggregate Data; (d) Partner’s trade secrets; and (e) any application interfaces created by Partner to accommodate the integration of Software Solution with the Payment Solution, and other Software Solution-side developments designed to facilitate the interaction between the two.
ZTL warrants that it holds all necessary Intellectual Property Rights to the Payment Solution and the necessary third-party licenses or rights to provide the Payment Solution through the Software Solution.
Partner warrants that it holds all necessary Intellectual Property Rights to the Software Solution and the necessary third party licenses or rights to offer the Software Solution together with the Payment Solution as set out in this Agreement.
Each party agrees to reasonably assist the other Party to fulfil the assignment or transfer of any relevant Intellectual Property Rights, if such assignment or transfer is mutually agreed
Limitation of liability
Neither party will hold the other party liable for its indirect losses arising under or in connection with the Agreement.
Except in case of gross negligence by a party, the total maximum liability of that party towards the other party arising out of or in relation to the Agreement, shall be limited to the greater of (i) a maximum aggregate sum equal to five percent (5%) of all compensation paid by both parties to the other party under the Agreement in the six (6) months preceding the Claim; or (ii) NOK 250,000 (whichever is higher). For claims arising before 6 months have passed, the limitation shall be equal to an extrapolation to 6 months based on the payment incurred at the time of the Claim.
In no event shall either Party be held liable to the other Party for any fraudulent or otherwise criminal acts committed by an Authorized User through the Payment Solution.
In no event shall ZTL be held liable for losses incurred as a result of circumstances encompassed by Clause “Delivery of an ‘as-is’ and ‘as-available’ service” (Support & Maintenance).
The indemnities set out in clause 13 are not subject to the limitation of liability.
Indemnification
Each party (as the indemnifying party) shall indemnify and hold harmless the other party and the other party’s affiliates, subsidiaries, agents and subcontractors, and its and their employees and other representatives (as the indemnified party) from and against all Claims in respect of any infringement by the indemnifying party of a third party’s Intellectual Property Rights, provided that: (a) the indemnified party notifies the indemnifying of such Claims forthwith as they arise; (b) that the indemnified party gives the indemnifying party full control of the defense against such Claims, including without limitation the timing, nature and size of any settlement of such Claims; and (c) that the indemnified party provides assistance to the indemnifying party as reasonably requested by it in its defense against such Claims.
Confidentiality
Each party agrees to keep confidential any information it receives from the other party in the course of this Agreement which, by denotation or reasonable circumstances, is considered confidential to the disclosing party.
The receiving party shall treat such received information with reasonable care and diligence, not disseminating or disclosing it to third parties without the prior written consent of the disclosing party, provided however that each party may share such information with its officers, employees, affiliates, subsidiaries or subcontractors who are subject to confidentiality obligations reflecting the principles herein.
The obligations set forth above shall not apply to (a) a Party’s reference to the other Party in any efforts to secure other business, unless the Party expressly and in writing forbids such reference, or (b) to any information which: (a) was or becomes known to the recipient from a third party without any confidentiality obligation; (b) is or becomes generally available in the public domain through no act or failure to act on the part of the recipient; (c) is required to be disclosed by any competent court, governmental agency, or other relevant public authority in accordance with applicable laws, court order or other public regulation; or (d) has demonstrably been developed by the recipient independently from this Agreement.
Each party shall keep all information concerning the business or personal circumstances of End Clients received in connection with the Payment Services and Information Services confidential, and take all necessary measures to prevent unauthorized third parties from gaining access to such information.
For the avoidance of doubt, the duty of confidentiality pursuant to this clause 14 shall under no circumstances be deemed, or practiced, in a manner that is less restrictive than the duty of confidentiality pursuant to section 16-2 of the Financial Institutions Act 2015.
Exit Management
Termination for convenience
After the Roll-out date, either party may terminate the Agreement in whole, not in part, for convenience by giving six (6) months’ prior written notice. The 6 month termination period shall commence on the first calendar day of the next month following a party’s notice of termination.
Termination for cause
Each party may, by giving written notice to the effect thereof, terminate this Agreement as of the date specified in such notice for material breach by the other party, unless the material breach is curable. If the material breach is curable, the defaulting party shall be given sixty (60) calendar days to rectify the breach. If the material breach is not rectified within such time frame, the other party may terminate the Agreement for cause.
Termination in other circumstances
Each party may terminate this Agreement by giving written notice to the other party if a party is declared bankrupt, files a petition for bankruptcy, requests for reconstruction or similar insolvency proceedings, unless the bankruptcy estate is entitled, in accordance with applicable law, to adopt the Agreement and wishes to do so.
Each party may terminate this Agreement by giving written notice to the other party if a party is materially hindered in performing its obligations under the Agreement due to an event which under the applicable law must be considered force majeure, and non-performance due to such force majeure event persists for more than 60 (sixty) calendar days from the service of such notice.
Change Management
ZTL may update these Terms from time to time. ZTL will provide the Partner with written notice of all changes made to these Terms.
Changes to the Terms made by ZTL in accordance with this section will become effective seven (7) months after ZTL’s notice to the Partner thereof. Notwithstanding the aforesaid, changes implementing requirements mandated by Regulatory Requirements or other applicable law may become effective sooner, as set out in ZTL’s notice.
Changes to the Payment Solution and ZTL’s services
ZTL may at its own discretion implement changes to the Payment Solution as a result of legal and/or Regulatory Requirements, security measures or similar. In addition, ZTL may implement changes to its services in order to optimize or rationalize ZTL’s business from time to time, e.g. in the form of Releases. ZTL will inform the Partner of any changes with a reasonable notice taking into consideration the nature of the change.
Governing Law and Disputes
The Agreement shall be exclusively governed and construed in accordance with the laws of Norway without regard to principles of conflicts of law. Any dispute arising in relation to or as a consequence of the Agreement, which cannot be settled amicably through negotiations between the parties, shall be brought exclusively in the courts of Oslo, Norway
DPO & DORA
DPO & DORA
ZTL has appointed a Data Protection Officer (DPO) to ensure compliance with applicable data protection laws, including but not limited to the General Data Protection Regulation (GDPR). The DPO serves as the primary point of contact for data protection matters.
Access to the DPO
ZTL Partners, End Clients and data subjects may contact the DPO for inquiries, complaints, or exercising their rights under applicable data protection laws and DORA-related inquiries. The DPO may be contacted at; dpo@ztlpay.io
Cooperation with Supervisory Authorities
The DPO shall cooperate fully with data protection supervisory authorities and DORA-compliant competent authorities, facilitating audits, investigations, and compliance-related processes as required by law.
Digital Operational Resilience Act (DORA) Compliance
ZTL Payment Solutions acknowledges the requirements outlined under the Digital Operational Resilience Act (DORA) and integrates them into its operational and data protection framework. This includes:
ICT Risk Management:
ZTL implements robust internal controls, risk management frameworks, and ICT governance practices to safeguard against operational disruptions and cyber threats.
Incident Reporting:
ZTL ensures timely reporting of any significant operational or cybersecurity incidents affecting the services to competent authorities, clients, and relevant stakeholders in line with DORA guidelines.
Third-Party Risk Management:
ZTL applies strict due diligence and continuous monitoring of third-party ICT service providers, ensuring their compliance with DORA requirements.
Operational Continuity and Recovery:
ZTL maintains comprehensive business continuity and disaster recovery plans to ensure uninterrupted service delivery, even during severe operational disruptions.
Testing and Auditing:
Regular testing of ICT systems, including penetration testing and vulnerability assessments, is conducted to identify and mitigate potential risks. All critical systems are audited periodically to verify compliance with DORA and data protection regulations.
Marketing Permissions
- Use of Logo
- The Customer allows ZTL Payment Solution to include the Customer’s logo in reference lists published on ZTL Payment Solution’s website and in company presentations.
- Customer Reference
- The Customer agrees, where appropriate and upon prior request, to act as a reference for ZTL Payment Solution on selected occasions.
- Case Studies and Press Releases
- The Customer permits ZTL Payment Solution to create and publish case studies, press releases, and related marketing communications—including social-media announcements such as on LinkedIn—describing the cooperation between the parties. Any such materials require the Customer’s prior approval, and no publication or distribution is allowed without this approval.
- Revocation of Permissions
- The marketing permissions set out in this section are independent of the duration and validity of the Agreement. The Customer may revoke any or all of these permissions at any time with immediate effect by providing written notice (email sufficient). Such revocation does not affect the remaining parts of the Agreement.
Acceptable Use Policy (AUP)
1 Purpose & Scope
This Acceptable Use Policy (“AUP”) governs access to and use of ZTL’s Application Programming Interfaces (“APIs”) and related payment-initiation (PIS) and account-information (AIS) services (collectively, the “Services”) by third-party providers (“Clients”). It supplements the ZTL API Terms of Service and aims to ensure:
- Fair, reliable and secure operation of the ZTL platform;
- Compliance with Directive (EU) 2015/2366 (PSD2), its Regulatory Technical Standards (RTS) and relevant EBA guidelines.
2 Definitions
API Call – A single HTTPS request/response interaction with any ZTL API endpoint.
Batch Job – A programmatic process that submits multiple payment orders or account-information requests as a single unit of work.
Burst/Spike – A short-lived surge in API traffic exceeding the sustained rate limit.
Client – A licensed PISP/AISP, merchant, partner or other party authorised to use the Services.
3 General Acceptable Use
- Clients must only access the Services with valid credentials issued by ZTL.
- Use of the Services must relate to legitimate, user-authorised payment or account-information activities.
- Partners must not store or cache end-user authentication credentials (e.g. BankID secrets, passwords, SCA factors). Tokens, consent IDs, account identifiers and other PSD2-permitted artefacts may be stored in accordance with PSD2 and GDPR.
; reverse-engineer, probe or penetrate ZTL systems; transmit malware, spam or illegal/harmful content; or use the Services for high-risk or prohibited transactions unless expressly permitted in writing.
4 API Usage Requirements
4.1 Daily & Monthly Quotas
|
Scope |
Limit |
|
Daily (per Client ID) |
100,000 API calls |
|
Monthly (aggregate) |
3M API calls |
Higher quotas may be granted under a written SLA.
4.2 Rate-Limiting
|
Parameter |
Limit |
|
Sustained rate |
10 requests / second |
|
Burst window |
≤ 50 requests in any rolling 5-second window |
Clients must implement exponential back-off and retry-after logic.
> Note: ZTL will periodically review real-world traffic patterns and may adjust these limits based on observed peak partner usage.
4.3 Batch Jobs & Concurrency
- Concurrent payment-initiation batches: ≤ 5
- Concurrent account-information refresh jobs: ≤ 3
- Maximum items per batch: 5000
- Jobs breaching these thresholds require prior written approval.
4.4 Traffic Spikes
Traffic must not exceed 120% of the sustained rate (section 4.2) in any 5-minute window. Spikes above this threshold will be automatically throttled and may trigger service suspension.
5 Payments Service (PIS) Usage
- All payments must be initiated in real time on explicit end-user instruction.
- Payment/payroll status polling: status may be queried once every 30 minutes per active payment. An active payment is a payment not yet in a final status (e.g., completed, rejected, cancelled).
- Prohibited activities include:
- split payments to bypass single-transaction limits;
- test or dummy payments against production endpoints;
- transactions that violate sanctions, AML/CTF or card-scheme rules;
- excessive polling beyond the limits above.
- Clients must promptly cancel or reverse unauthorised or duplicated transactions on request.
6 Account-Information Service (AIS) Usage
- Data retrieved must be minimal and relevant to the specific service provided to the user (Art 5(1)(c) GDPR; Art 36 RTS).
- Refresh frequency: Maximum 4 automated AIS requests per account, per endpoint, per day when the user is not present. Additional requests are only permitted when explicitly triggered by active user interaction.
- Stored account data must be encrypted at rest and retained no longer than necessary.
7 PSD2 Compliance Obligations
|
Area |
Requirement |
|
Consent Management |
Clients must maintain auditable records of end-user consent and provide these to ZTL or competent authorities on request. |
|
Strong Customer Authentication (SCA) |
All payment orders and data requests must be preceded by SCA in accordance with Art 97 PSD2 and the RTS on SCA & CSC. |
|
Interface Availability & Performance |
ZTL ensures ≥ 99.5% monthly availability (Art 32-33 RTS). Clients must respect the limits in section 4 to avoid degrading this level. |
|
Traceability & Logging |
Clients must log request IDs, timestamps and user identifiers for at least 18 months (Art 30 RTS). |
|
Incident Reporting |
Suspected or actual security incidents affecting user data or funds must be reported to ZTL within 24 hours. |
8 Monitoring, Enforcement & Penalties
- ZTL employs real-time monitoring and automated throttling.
- First violation: warning email and temporary 4xx responses.
- Repeated or material violation: suspension of credentials and regulatory notification under PSD2 Art 96(6).
- ZTL reserves the right to immediately terminate access in cases of fraud, money-laundering or systemic risk.
9 Amendments
ZTL may amend this AUP at any time. Material changes will be notified 30 calendar days before the effective date, unless earlier amendment is required by law or regulator.
10 Contact & Queries
Questions about this AUP should be directed to aup@ztlpay.io or your ZTL account manager.
Last review
17 November 2025
Changelog
Edited:
January 9, 2026Updated Payment Solution Availability.
November 17, 2025
Created and published.
Published: March 1st, 2025
