DRAFT FOR THE LAWYER, 20 September 2026

Terms of use of the programming interface for companies

Version [1.0] of [DATE]

1. Scope and the Seller's details

1.1. These Terms set the rules under which the Company connects its own information systems to the Seller's system and uses them. They are Annex No. 4 "Terms of use of the programming interface for companies" to the Contract for the sale of petroleum products and services through ePay Company cards (the Contract) and form an integral part of it.

1.2. The Seller is "DII-TEH-GROUP" S.R.L., IDNO 1017600052819, VAT code 0508117, with its seat at mun. Chișinău, str. Socoleni 2/6, Republic of Moldova. Telephone: [TELEPHONE]. Electronic mail address: dev@e-gaz.md. Web page: https://epay.e-gaz.md. Authorisation No. [NUMBER], valid until [DATE], issued by [AUTHORITY]. The same details are published in the documentation of the Interface, under Law No. 284 of 22.07.2004 on information society services.

1.3. These Terms apply to a Company that has chosen the use of the programming interface at item 11 of Annex No. 1 "Special conditions" and whose Cabinet is open. Without that choice, the Seller does not give access to the Interface in the Live environment.

1.4. Where a provision of these Terms conflicts with the Contract, the Contract applies. Where a provision of these Terms conflicts with Annex No. 3 "Terms of use of the Company Cabinet", Annex No. 3 applies. For the Interface, these Terms are the special provision and apply first.

1.5. The technical documentation describes the Interface and creates no new duty for the Company. Where the documentation conflicts with these Terms, these Terms apply. The documentation is changed under chapter 11.

1.6. Both Parties to the Contract are professionals. They agree to derogate from art. 21 para. (3) and from art. 23 para. (1) and (2) of Law No. 284/2004, to the extent that the documentation of the Interface and the Cabinet give the following information:

a) the technical steps of an operation;

b) the storage of the record of the operation and access to that record;

c) the means of correcting an error before sending;

d) the languages in which the documentation is published.

1.7. The Seller has joined no code of conduct that applies to the Interface. Use of the Interface is not compulsory: the same operations are carried out in the Cabinet, under Annex No. 3.

2. Definitions

2.1. The programming interface, hereinafter the Interface, is the set of electronic addresses and technical rules by which the Company's information systems communicate directly with the Seller's system, without human intervention. The technical documentation calls it the API.

2.2. A Request to the Interface is the message that a system of the Company sends to an address of the Interface and to which the Seller replies.

2.3. The Key is the secret string of characters by which a Request to the Interface is attributed to one Company. Keys are of two kinds: the Read key and the Payment key.

2.4. The Live environment is the Interface in operation, in which the Company's real operations are carried out.

2.5. The Test environment is the copy of the Interface that works by the same rules, with test data and test money, at an address separate from the Live environment.

2.6. The Notification address is the electronic address of the Company to which the Seller sends messages about events; the technical documentation calls it a webhook.

2.7. The Integrator is the third party the Company hires to build or to maintain the link between its systems and the Interface.

2.8. Other terms written with a capital letter have the meaning given to them in Art. 1 of the Contract and in Annex No. 3.

3. Access and Keys

3.1. The Owner creates the Keys, in the section "Developer" of the Cabinet. The Accountant sees the list of Keys without their value. The Operator has no access to that section. Once the Cabinet is open, the Seller asks nothing further of the Company for a Key of the Live environment.

3.2. A Read key gives the right to see the Company account, its movements, the Company users, the Company cards, the reports, the events and the documents of the Company. A Payment key also gives the right to top up a Company card. The Keys permit the operations set out in these Terms; a new operation is added only under clause 7.6 and chapter 11.

3.3. The value of the Key is shown once, when it is created. The Seller keeps its cryptographic fingerprint and its first characters, which identify the Key in lists. A lost Key is not recovered: the Company creates another and revokes the old one.

3.4. The Company may hold at most [5] (five) active Keys. A Key has no expiry date.

3.5. The Seller creates a Key in the name of the Company only at the written request of an Owner. A Key so created is attributed to the Company only after an Owner confirms it in the Cabinet. The Company is not liable for Requests to the Interface made with a Key created in any other way.

3.6. The Key is secret. The Company must keep it in a protected place and must give it only to the people who need it for their work. The Key must not be published in source code, must not be placed in a mobile application or in a page opened in a browser, and must not be sent through an unprotected channel. The Key is sent in the header of the Request to the Interface; a Request carrying the Key in the address is refused.

3.7. On any suspicion that a Key has been compromised, the Company must change it: it creates a new Key, puts it into use and revokes the old one. Revocation takes effect at once.

3.8. The Company may revoke any of its Keys at any time, from the Cabinet. The Seller revokes a Key where there are signs that it has been compromised, of abuse or of unauthorised access. The Seller must tell every Owner the same day, by electronic mail, and must state the reason.

3.9. On the creation and on the revocation of a Key the Seller sends a message to every Owner: the name of the Key, its first characters, who acted and when. For a Key unused for [60] (sixty) days the Seller sends a reminder.

3.10. The Seller recommends that the Company state, for a Payment key, the addresses of the servers from which Requests to the Interface are accepted. The Company enters them in the Cabinet.

3.11. A Request to the Interface authenticated with a Key of the Company is presumed to be a request of the Company. The presumption may be rebutted by any means of proof. It does not apply to Requests whose cause lies in the Seller's systems or in the Seller's organisation.

3.12. The presumption of clause 3.11 ends at the earlier of two moments. The first is the revocation of the Key in the Cabinet, which takes effect at once. The second is the receipt by the Seller of the Company's notice that the Key has been compromised. By derogation from Art. 46 of the Contract, that notice counts as received when it is sent to dev@e-gaz.md.

4. The Test environment

4.1. The Seller gives the Company the Test environment at [TEST ENVIRONMENT ADDRESS], with Keys of its own. Access is free and is never invoiced.

4.2. The Test environment holds test data and test money. No operation carried out there touches the Company account, the Company cards or a Company user, and none creates an obligation to pay.

4.3. The Company must not enter real personal data in the Test environment. The content of Requests to the Interface and of the answers is kept in that environment under clauses 12.1 and 12.3.

4.4. A Key of the Test environment does not work in the Live environment, and a Key of the Live environment does not work in the Test environment.

4.5. The Seller may delete the data of the Test environment, including the trial companies and their movements. It announces the deletion in the Cabinet and by electronic mail [7] (seven) days in advance. Keys of the Test environment and the Notification address remain in force after the deletion.

4.6. The Test environment has no availability target. A result obtained there does not bind the Seller: the Live environment behaves as the documentation and these Terms say.

5. Limits of use

5.1. The rate of Requests to the Interface is limited on each Key: [20] (twenty) requests a second for reading and [5] (five) requests a second for money operations. A further allowance for traffic peaks is added, of [60] (sixty) and [20] (twenty) requests respectively. Above that the Seller refuses the Request and states in the answer the moment from which it may be repeated. The same figures apply in the Test environment.

5.2. Top-ups through the Interface are limited to [50,000.00] lei for one operation and to [200,000.00] lei for one calendar day, by the official time of the Republic of Moldova. The limit protects the Company account if a Key reaches an outsider: no more than the stated sum can leave through the Interface in a day.

5.3. The Owner changes both sums in the Cabinet. The change takes effect at once, is written to the log and is sent by electronic mail to every Owner.

5.4. Where there are signs that a Key is being abused, the Seller may set those sums itself and may close their change from the Cabinet. The measure is announced to the Company with its reason and lasts only as long as the reason lasts.

5.5. The Seller may lower a limit to protect the working of the system or to stop an abuse. It tells the Company in the Cabinet and by electronic mail [5] (five) days in advance. Where the reduction answers a security incident in progress, it takes effect at once and the Seller reports it, with the reason, within 24 (twenty-four) hours. The reduction lasts only as long as its reason lasts; the Seller must restore the previous value as soon as the reason has ended and must tell the Company. A reduction kept for more than [10] (ten) days gives the Company the right to declare the termination of the Contract under Art. 39 of it, with no penalty.

5.6. The limits of this chapter concern the Interface only. They do not touch payments made by Company users at the Seller's Sites: a card that has been topped up is spent in full.

6. Rules of use

6.1. The Company must use the Interface only to run its own fleet, in performance of the Contract.

6.2. The building and the upkeep of the link may be entrusted to an Integrator. The Company is liable for the acts of the Integrator as for its own, gives it access only to the Keys it needs, and takes that access away when their relations end. The Key remains the Key of the Company.

6.3. The Company must not:

a) sell, rent out or make available to another person its access to the Interface;

b) extract data about other companies, about people who are not its own Company users, or about their personal operations;

c) run load tests or automated scans against the Live environment; such tests belong in the Test environment, and security tests also need the written agreement of the Seller;

d) create further Keys or trial companies in order to exceed the limits of chapter 5;

e) apply money operations to cards other than the Company cards of its own Company users.

6.4. A top-up with a note is made under clause 7.9 of Annex No. 3. The note holds at most [64] characters of plain text. It must not present the top-up as loyalty units, as money of the Company user, or as the discharge of a debt the Seller owes that person.

6.5. The money credited stays the money of the Company, and the settlement between the Company and the Company user happens outside the ePay system. The Company must not present the Interface to third parties as a service of its own and must not use the ePay trade marks without the written agreement of the Seller.

7. Money operations through the Interface

7.1. One money operation is carried out through the Interface: the top-up of a Company card from the Company account. The money moves between two records of the same Company. The Interface creates no money and opens no credit.

7.2. A top-up is carried out within the payment regime chosen under Art. 20 of the Contract: under payment in advance, from the balance of the Company account; under the credit ceiling regime, within the remaining ceiling under Art. 20.1. The Company account does not go below zero.

7.3. A top-up is carried out only to an active Company card of a Company user whose link with the Company is active. A Request to the Interface addressed to a card of another company, to a deleted card or to an ePay card is refused.

7.4. The Interface does not touch the User's ePay card, that person's Balance, Stamps or Coupons.

7.5. The User part is not taken back through the Interface. It is spent first and stays at the disposal of the Company user, under Art. 17 of the Contract.

7.6. The Company part is taken back from a card by a Company staff member, in the Cabinet. At the written request of the Company the Seller may open that operation in the Interface too, on the Payment key.

7.7. The Interface does not create Company users, does not enable or delete cards, and does not change the limits, the Notification address, the Keys, the details of the Company or the Company staff. A Company staff member carries out those actions in the Cabinet. Their absence from the Interface is a security measure: a Key that reaches an outsider cannot create a new recipient of money.

7.8. The Company gives each money operation an idempotency key, which stops the same Request to the Interface being carried out twice. Requests carrying the same idempotency key and the same content are carried out once, and on a repeat the Seller returns the same answer, marked as a repeat. The same idempotency key with different content is refused. The idempotency key is kept for at least [24] (twenty-four) hours. A Request without an idempotency key is refused.

7.9. Where it receives no answer at all, the Company repeats the Request to the Interface with the same idempotency key. The repeat does not produce a second top-up.

8. Events and notifications

8.1. The Company learns of movements on the Company account and on the Company cards by reading the event log or by receiving notifications at the Notification address. The event log is kept for [30] (thirty) days.

8.2. The Notification address is a public HTTPS address. The Seller refuses an unprotected address, an address that leads into an internal network, and an address that redirects the message.

8.3. Every notification carries a cryptographic signature computed by the HMAC SHA-256 method with a signing secret the Company obtains in the Cabinet. The Company must check the signature of every message it receives. It must refuse a message whose signature does not match and a message whose timestamp differs from the current time by more than [300] (three hundred) seconds. When the signing secret is changed, the old and the new secret are both valid for [24] (twenty-four) hours.

8.4. The Seller must keep the signing secret protected and must tell the Company without delay of any security incident that concerns it. A message signed with a compromised secret is not a message of the Seller.

8.5. The same notification may arrive several times, and the order of notifications is not guaranteed. The Company distinguishes notifications by the identifier of the event and handles a repeat without doubling the operation in its own systems.

8.6. If the Notification address does not answer, the Seller repeats delivery at growing intervals, at most [12] (twelve) attempts within 3 (three) days of the first failure. After [50] (fifty) consecutive failures delivery stops and the Seller tells the Owners.

8.7. The Company switches the Notification address back on from the Cabinet. Switching it back on does not resend the notifications that were not delivered; the Company obtains them by reading the event log, within the period of clause 8.1.

9. Personal data

9.1. For the data of Company users connected with the Company cards, sent or received through the Interface, the Company is the controller and the Seller is the processor. The processing is carried out under the Agreement on the processing of personal data (Annex No. 2 to the Contract) and Law No. 195 of 25.07.2024 on the protection of personal data.

9.2. The Seller is an independent controller for the User account, the ePay card and the Balance of the same person, for its own sales on any card, and for the log of chapter 12. The suspension of access on security grounds is the Seller's own act as controller, and not a processing on the Company's instruction.

9.3. Through the Interface the Company must send only the data needed to run the fleet. Those data are the label it gave the Company user, its own identifier for that person and, where it uses that function, the registration number of the vehicle. The Company must not send data about health, about family life, or other data unconnected with the fleet.

9.4. The Interface returns no telephone numbers, no names and surnames of Company users and no card numbers. A search by telephone number takes an exact number and shows only whether that number belongs to one of the Company's own Company users; the number itself does not appear in the answer.

9.5. The Seller processes, as controller, the data of the Company staff who create and revoke Keys, and the technical data of the Requests to the Interface. The processing is carried out under the Privacy policy, published at https://epay.e-gaz.md, and Law No. 195/2024 (Monitorul Oficial No. 367-369 of 23 August 2024, art. 574, in force from 23 August 2026).

9.6. The Company is responsible for its own systems that receive the data and for informing its Company users, under Art. 27 of the Contract and clause 7.7 of Annex No. 3.

10. Availability and technical support

10.1. The availability of the service as a whole is set by clause 11.1 of Annex No. 3. For the Interface the Seller works towards a target of [AVAILABILITY LEVEL] % per calendar month. The target shows what the Seller works towards and is not a guaranteed level.

10.2. Planned maintenance windows of the Interface are announced in the Cabinet and by electronic mail at least 24 (twenty-four) hours in advance, with the interval and the expected effect. They are set between [22.00] and [06.00], except where the work cannot wait. Maintenance required for security is carried out at once, and the Seller tells the Company within 24 (twenty-four) hours.

10.3. Payments with Company cards at the Seller's Sites are carried out within the sums held on the cards, including while the Interface is unavailable.

10.4. Technical support for the Interface is given at dev@e-gaz.md and at [COMPANY SUPPORT TELEPHONE], on working days, during [SUPPORT HOURS]. Incidents that stop the Interface or payments with Company cards are treated first, and the Seller gives a first answer within [4] (four) working hours. In its message the Company states the log reference of the Request to the Interface, which it sees in the Cabinet.

10.5. Missing the target of clause 10.1 gives no separate compensation. The Seller's liability remains that set by Art. 34 of the Contract, and the right of each Party to declare termination under Art. 39 of the Contract is not affected.

11. Versions of the Interface

11.1. The version of the Interface appears in the electronic address. Within one version the Seller may add new addresses, new fields in requests and answers, new kinds of event, new error codes and new values in lists. The Company must build its own systems so that these additions do not stop them. A Request to the Interface that holds an unknown field is refused.

11.2. A change that is not compatible with the version in force is made only by a new version, published beside the old one. The Seller announces it at least [90] (ninety) days in advance, in the Cabinet, by electronic mail to the addresses of the Owners and in the documentation. The announcement shows what changes and what has to be done.

11.3. The old version stays available for at least [12] (twelve) months from the day the new one is published. In the last [3] (three) months of that period it answers reading requests only. These periods are also shown in the answers of the Interface, in the headers set by the documentation.

11.4. A security fix is applied at once only where it does not change the rights and duties of the Company. Where it changes them, the 30 (thirty) days' notice of clause 15.1 applies. The fix is limited to what is necessary and proportionate to the security reason and lasts as long as the reason lasts; the Seller restores compatible behaviour as soon as it can. The Company is not liable for non-performance caused by such a fix.

11.5. The Seller changes the Interface for one of the reasons set by Art. 19.1 of the Contract:

a) the law or the requirement of an authority changes;

b) a supplier of the Seller or the payment channel changes;

c) a function or a service line is added or withdrawn;

d) the security of the system requires it;

e) an error is corrected.

11.6. A Company that does not accept a change that is not compatible may declare the termination of the Contract under Art. 39 of it, by a notice sent before the date from which the change applies. Until the Contract ends the previous version applies, and access to the Interface does not stop.

12. The request log and audit

12.1. The Seller records every Request to the Interface, whatever its outcome. The record holds the Key used, the time, the address requested, the network address of the requester, the outcome, the error code and the log reference of the Request. The content of Requests and answers is kept in the Test environment only.

12.2. The Seller uses the log only for the security of the Interface, for proof of operations, for accounting and for statutory duties. The log is not passed to any person other than the processors named in Annex No. 2. The processing is carried out under the Privacy policy.

12.3. The log is kept for [400] (four hundred) days for the Live environment and for [14] (fourteen) days for the Test environment.

12.4. Every top-up made through the Interface carries, in the Seller's records, the Key that started it. A top-up made by a system is in this way distinguished from a top-up made by a Company staff member in the Cabinet.

12.5. The Company reads the Requests to the Interface of the last [7] (seven) days in the Cabinet. At the Company's request the Seller must make available the records of the period of clause 12.3, in CSV format, within 5 (five) working days.

12.6. In a dispute about an operation the Parties to the Contract examine the records of the log. The Seller does not decide on its own whether a Request to the Interface was carried out correctly. The log is a means of proof and does not limit the right of either Party to offer other proof.

12.7. Keys and the signing secret do not appear in the log, in electronic mail messages or in the answers of the Interface.

13. Suspension and termination of access

13.1. The Company may itself stop access through the Interface, by the corresponding setting in the Cabinet. The stop takes effect at once. Access is resumed from the Cabinet too, and resumption needs a confirmation.

13.2. The Seller suspends access through the Interface where the Company breaks the rules of chapter 6. It does the same where the Company's Requests to the Interface endanger the working of the system, and where there are signs of unauthorised access. It also suspends access in the cases set by Art. 21.3 and Art. 40 of the Contract.

13.3. For breaches that do not endanger the security or the working of the system, the Seller gives the Company [5] (five) days to put the matter right before it suspends access.

13.4. The Seller tells the Owners before the suspension, or, where the suspension cannot wait, within 1 (one) hour after it. The message states the category of the reason and what has to be done for access to be restored.

13.5. A suspension of access through the Interface is not decided automatically. A member of the Seller's staff checks the situation and decides, and the decision is written to the log with its reason.

13.6. The Seller may stop the Interface for all companies, by a general switch, where the security or the working of the system requires it. It may also suspend the access of a single Company. Clauses 13.4 and 13.7 apply in both cases.

13.7. The Company may ask for a suspension or for the revocation of a Key to be reconsidered, by a message sent to dev@e-gaz.md. The Seller answers within [3] (three) working days. A suspension or a revocation made without grounds is made good under Art. 34 of the Contract.

13.8. Suspension of access through the Interface does not suspend the Cabinet and does not stop payments from Company cards already topped up, save in the cases the Contract provides.

13.9. Access to the Interface ends with the Contract. The Read key stays active during the period of access for consultation only set by Art. 42 of the Contract, and money operations end with the Contract. The sending of notifications stops, and the log is kept under clause 12.3.

14. Liability

14.1. The Seller's liability to the Company is that set by Art. 34 of the Contract.

14.2. The Seller must keep the Keys, their cryptographic fingerprints and the signing secret protected. It must tell the Company without delay of any security incident that concerns the Company's Keys, the signing secret or the Company's data.

14.3. Damage caused by a suspension, by the revocation of a Key or by a reduction of the limits made without grounds is made good under Art. 34 of the Contract.

14.4. The Company is liable for keeping its Keys safe, for the Requests to the Interface made with them and for the acts of the Integrator, within the limits of clauses 3.11 and 3.12.

14.5. The limits of clause 5.2 apply to the Company as a whole. A Company that entrusts a Key to an Integrator may ask in writing for those limits to be lowered, and the Seller applies the lower limits.

14.6. The Seller is not liable for the working of the Company's systems or for its internet connection. Nor is it liable for the consequences of a top-up correctly carried out at the Company's request to a card the Company chose in error; at the Company's request the Seller helps to put the matter right by returning to the Company account the Company part left on the card.

14.7. Nothing in these Terms removes liability for intent or for gross fault.

15. Change of these Terms, applicable law and disputes

15.1. The Seller changes these Terms for one of the reasons stated in clause 11.5, on 30 (thirty) days' notice given in the Cabinet and by electronic mail to the addresses of the Owners, under Art. 47.1 of the Contract. The announcement contains a short list of the changes and the date from which the new version applies.

15.2. At the first sign-in after that date the Cabinet asks the Owner to accept the new version. Use of the Interface does not count as acceptance of the new version.

15.3. A Company that does not accept the new version may declare the termination of the Contract under Art. 39 of it, by a notice sent before the date from which the new version applies. Until the Contract ends the previous version applies, and access to the Interface does not stop.

15.4. The Romanian text is the binding text. The Seller may make available courtesy translations into Russian and English.

15.5. These Terms are governed by the law of the Republic of Moldova. Disputes between the Seller and the Company are settled under Art. 44 of the Contract.