1. Scope and Definitions
1.1 Scope
These General Terms and Conditions (hereinafter “GTC”) apply to the agreement between the contracting party and checksum AG (hereinafter “checksum”) concerning the acceptance of cashless payment methods at the point of sale and the related products and services.
1.2 Definitions
The following definitions correspond to the use of the respective terms in these GTC.
Acquirer (checksum)
The Acquirer enables its contracting parties to accept payment cards or other payment systems as cashless means of payment in face-to-face transactions and ensures the processing of the transactions generated thereby.
Authorisation
As part of the authorisation process, the card issuer or provider of other payment systems checks whether a card or user app is valid and not blocked, and whether the transaction amount falls within the specified limits.
Debit card
A card used to pay for goods and services, with the cardholder’s account debited immediately (e.g. Visa Debit, Debit Mastercard).
Electronic processing
Processing and submission of a transaction using a hardware or virtual terminal and electronic transmission to the system.
EMV (EMV card, EMV chip, EMV terminal)
Specification for cards equipped with a processor chip and the associated chip card readers (e.g. POS terminals, ticket machines, cash machines, fuel dispensers). EMV transactions are defined as payments where, during processing, the card data is read electronically from the card’s processor chip at an EMV terminal.
Credit
Full or partial refund of a transaction to the cardholder or user of other electronic payment methods who was originally debited.
Infrastructure
All technical facilities of the contractual partner used for the electronic acceptance of cashless payments, including hardware or virtual terminals and associated devices.
Cards
Generic term for payment cards used for cashless payment transactions, namely credit, debit and prepaid cards.
Card issuer
A company authorised by the licensor to issue cards to cardholders.
Cardholder
A person who purchases goods and/or services offered by the contractual partner and pays for them cashlessly using a card (transaction).
Card organisation
Licensor (such as Visa International, Mastercard International) for the issuing and acceptance of cards and cashless payment methods.
Card verification number
A sequence of digits printed on the credit card (e.g. Visa [CVV2], Mastercard [CVC2]), which serves as an additional security feature in remote transactions.
Contactless (contactless card, contactless reader, contactless transaction)
Processing of transactions using Near Field Communication (NFC), an international standard for the transmission of data via radio technology. This requires a terminal with a contactless reader and a card with an NFC-enabled chip or a digital card loaded onto an NFC-enabled device (cardholder). The chip data is read by holding the card or cardholder against the contactless reader.
Credit card
A card used to pay for goods and services, with the cardholder being charged retrospectively
Merchant Category Code (MCC)
A grid specified by the licensors that enables the acquirer to assign the contractual partner’s business activities to one or more industry categories.
mPOS terminal Mobile
card reader operated via a compatible mobile device (e.g. smartphone or tablet) and an app.
Payment Service Provider (PSP)
A technical service provider that provides applications such as virtual terminals to enable the acceptance of electronic payments in online shops.
PCI Standards
Security standards for the payment card industry established by the PCI SSC (Payment Card Industry Security Standards Council), compliance with which is mandatory for licence holders. Further information can be found at pcisecuritystandards.org.
PCI DSS
The PCI DSS (Payment Card Industry Data Security Standard) is a PCI standard that is specifically designed to ensure that companies implement security measures.
PIN (Personal Identification Number)
A personal combination of numbers that authenticates a person as the authorised user of a card
In-store transaction
Transactions in which a person and the card or payment app used are physically present at the point of sale.
QR code
A 2D barcode generated by the contracting party as part of the transaction process and read by the payment method user via the payment app for the purpose of processing the payment.
Chargeback
Reversal of a transaction submitted by the contractual partner or of a payment already made, due to a justified complaint about the transaction by the payer or the relevant issuer. The contractual partner’s claim to payment lapses.
System
The electronic authorisation and settlement system operated by checksum for the processing of transactions. This also includes the “Merchant or Partner Portal” service.
Terminal (hardware or virtual terminal)
Hardware terminals are stationary or mobile devices used to process transactions. Software components that enable the connection between the hardware terminal and other peripheral devices (POS systems, hotel reservation systems, fuel dispensers, etc.) are considered part of the hardware terminal.
Virtual terminals are applications that enable the processing of transactions in remote commerce. Software terminals are usually operated and sold by payment service providers (including checksum).
Transaction
An electronically processed cashless payment transaction, the transaction data for which is subsequently processed by the checksum system.
Transaction receipt
A physical or electronic confirmation generated via a terminal or in a web shop for the processing of a transaction.
Payment confirmation
An (electronic) receipt generated by checksum, which is made available to the payer in the relevant payment application after each transaction. Users of electronic payment methods Users of electronic payment methods.
2 The contracting party
2.1 Identification of the contracting party
checksum is obliged to identify the contracting party and its legally authorised representatives, as well as to record the contracting party’s business activities and assign them to the correct merchant category code (MCC). To this end, the contracting party shall enter into the contract electronically and submit the specified documents, as well as any further necessary documents on a case-by-case basis, to checksum.
2.3 Industry classification (Merchant Category Code, MCC)
The Contractual Partner operates within the industry categories listed in the contract modules and sells goods and/or provides services to cardholders/users of other electronic payment methods that are exclusively assigned to these industry categories. A separate contract module must be concluded for each industry category.
2.4 Changes on the part of the Contractual Partner
In the event of changes on the part of the Contractual Partner (e.g. regarding legal form, business activities, address, bank details, legally authorised representatives, points of sale or infrastructure), the Contractual Partner must notify checksum immediately in writing. checksum is entitled to charge the Contractual Partner for the costs incurred as a result of such changes.
In the event of a material change in the contractual partner’s ownership and control structure, the contractual partner is obliged to inform checksum of this at least one month in advance by post. In this case, checksum is entitled to demand an update of the contractual partner’s identification in accordance with clause 2.1. If this results in increased risks for checksum, it is entitled to terminate the contract modules with immediate effect. Until checksum has been informed in writing of a legal succession, it may make all payments to the previous contracting party with discharging effect.
If there is a significant deterioration in the contractual partner’s creditworthiness (e.g. the opening of insolvency proceedings), the contractual partner must inform checksum immediately. checksum is entitled, at its reasonable discretion, to take appropriate measures immediately, such as adjusting payment terms, withholding payments or demanding suitable security. The contracting party shall be informed without delay of the measures taken.
checksum is entitled, as part of its risk management, to review the contractual partner’s business activities (products and services) and financial position. The contractual partner shall provide checksum with the necessary information (including annual accounts) upon request within 10 days.
3 Contracting Party’s Infrastructure
3.1 General
The acquisition, operation and maintenance of an infrastructure suitable for the electronic processing of cashless payments, as well as the security measures to prevent misuse of the infrastructure—in particular compliance with the PCI DSS in accordance with clause 14.2—are entirely the responsibility of the contracting party. This also applies to adjustments to the infrastructure resulting from system modifications by checksum in accordance with clause 4.1, paragraph 3.
3.2 Obligations of the Contracting Party
3.2.1 General duties of care
The Contractual Partner undertakes to ensure, through appropriate measures, that no manipulation, in particular no unauthorised transactions, is possible and that the terminals are protected against access by unauthorised third parties. The Contractual Partner shall train its staff in the correct handling and use of the infrastructure at appropriate intervals, in particular upon its commissioning. Furthermore, it shall instruct its staff on the measures to be taken to prevent misuse and fraud.
3.2.2 Obligations regarding hardware terminals
The Contractual Partner must position all terminals at the point of sale in such a way that the cardholder or user of other electronic payment methods has direct access to the terminal (in particular to the display, control buttons and card reader) and cannot be observed when entering their PIN, should this be necessary.
3.2.3 Obligations regarding virtual terminals
The Contractual Partner must take all reasonable care to protect the infrastructure used to operate the virtual terminals, in particular the computers (including all associated network elements) and the data storage media (in particular card numbers, expiry dates or transaction data).
3.2.4 Duty to provide information/right to information
Upon request by checksum, the Contractual Partner must inform checksum in writing which terminals are in active use. Furthermore, the Contractual Partner authorises checksum to request this information directly from the terminal manufacturers/software suppliers or other infrastructure providers. The Contractual Partner shall provide checksum with appropriate support in this regard.
The Contractual Partner shall immediately notify checksum in writing of any changes relating to hardware terminals or its online shop, in particular the decommissioning, replacement or change of location or URL.
3.2.5 Transaction routing by third parties
The Contractual Partner is entitled to enter into an agreement with PCI DSS-certified third parties (such as payment service providers or network operators) who submit transactions to checksum on behalf of the Contractual Partner. checksum shall not refuse to recognise such third parties without good cause. The costs incurred in connection with the third party’s connection, in particular for activation, fees, delays and errors, shall be borne by the Contractual Partner. checksum is entitled to invoice such costs and fees to the Contractual Partner or to set them off against payments due to the Contractual Partner.
The Contractual Partner must notify checksum in writing without delay of any adjustments relating to transaction routing by third parties, as well as of any change of such third party. checksum is entitled to refuse such adjustments or changes for good cause.
3.2.6 Acceptance by multiple acquirers
Where the Contractual Partner simultaneously obtains acquiring services from several providers, the separation of transaction data attributable to the respective acquirer must be guaranteed at all times. Cooperation with third-party acquirers must not in any way impair the processing and security of the transactions to be processed by checksum.
4 checksum’s authorisation and settlement system
4.1 General
checksum operates and maintains the system from a technical, organisational and administrative perspective. The contracting party has no entitlement to the constant availability and trouble-free usability of the system. checksum cannot provide any guarantee in this regard. checksum is entitled to suspend operation of the system at its reasonable discretion if this appears necessary for compelling objective reasons, such as system changes and additions, malfunctions, or the risk of misuse. checksum reserves the right to modify or supplement the system in technical and organisational terms. Should this result in adjustments to the infrastructure, the contracting party shall carry these out at its own expense, in accordance with checksum’s instructions. The contracting party is also obliged to adopt any changes and additions made by checksum and the system and infrastructure suppliers or terminal manufacturers, in particular for the purpose of enhancing security standards.
4.2 Authorisation
Unless expressly agreed otherwise, the Contractual Partner is obliged to obtain authorisation from checksum for every form of acceptance using a procedure specified by checksum. Exceptions expressly approved by checksum are reserved
The Contractual Partner acknowledges that the authorisation procedure can only verify whether a card or app of another electronic payment method is not blocked and no limit has been exceeded. The authorisation granted therefore does not entitle the Contractual Partner to reimbursement of the transaction by checksum.
4.3 Transaction processing and settlement
The transactions submitted by the Contractual Partner are processed and settled by the system. The resulting remuneration claims are credited to the Contractual Partner and checksum’s bank is instructed to transfer the amount due to the Contractual Partner’s financial institution.
4.4 Web service ‘Customer or Partner Portal’
The two web services, the ‘Customer and Partner Portal’ (hereinafter referred to as the ‘Web Service’), comprise the electronic provision of payment statements, transaction and terminal information, as well as reports and self-service functions, in connection with the acceptance of cashless payment methods.
The Contractual Partner shall specify to checksum which persons are to be granted access rights to the administration area of the Customer or Partner Portal platform. The personalised login details provided by checksum (hereinafter “Login Details”) authorise these persons to make changes regarding the scope of services and configuration on behalf of the Contractual Partner.
The Contractual Partner is responsible for ensuring that the login details are adequately protected against access by unauthorised third parties. Furthermore, they must change the passwords regularly. Anyone who identifies themselves to checksum using the login details is deemed to be authorised by the Contractual Partner to use the Customer or Partner Portal platform. checksum only verifies the login details; no further identity verification takes place.
If there is reason to fear that unauthorised third parties have gained knowledge of the login details, the Contractual Partner must have the login details blocked immediately by checksum (tel. no. +41 58 329 31 80). The Contractual Partner is liable for all actions carried out by third parties using the login details as if they were their own.
The contracting party may access the data stored on the customer or partner portal platform for a period of at least 6 months. However, checksum accepts no liability for the authenticity and integrity of the data when it is downloaded, recorded and stored by the contracting party.
5 Acceptance
5.1 Obligations of the Contractual Partner
5.1.1 General obligations
The Contractual Partner undertakes to accept all cards of the agreed card brands and types (credit, debit or prepaid cards), as well as other electronic means of payment, regardless of the amount, as a means of payment for goods and/or services.
In connection with acceptance, the Contractual Partner undertakes in all cases to
- not to split a transaction across different cards or into several partial amounts for the same card; unless
- the first payment is a deposit and the second is the balance due for a service or goods to be provided or delivered at a later date,
- it is an instalment payment, the term and individual instalment amounts of which have been agreed in writing between the merchant and the cardholder,
- the cardholder pays part of the total amount by card and the remaining purchase amount in another form (e.g. cash or cheque).
- Not to disadvantage the card or other electronic means of payment compared to other means of payment; in particular, not to charge a surcharge for payment by card or other electronic means of payment, and not to grant cardholders or users of electronic means of payment a discount if they opt not to pay by card or other electronic means of payment in favour of other means of payment;
- not to make cash withdrawals or grant loans against the card/payment; for cash withdrawals (cash advances, purchases with cash back), a supplementary agreement is required (where available);
- to accept the card or other electronic means of payment for services that cannot be provided immediately only if the cardholder or user of electronic means of payment is informed of the subsequent provision of the service in a verifiable written form (including by email);
- not to alter or correct any data on a receipt after it has been signed; if a correction is necessary, a new receipt must be issued;
- to take the measures that would be expected of a diligent trader to prevent the misuse of cards/other electronic payment methods and to report any suspected misuse immediately.
- The Merchant shall comply with the acceptance and branding rules of the respective card schemes and providers of electronic payment methods. In particular, trademarks, logos and other proprietary marks may only be used in accordance with the applicable guidelines of the respective card schemes or payment providers. The Merchant shall not infringe any third-party rights in connection with such use.
5.2 Exclusion of acceptance
The contracting party may not accept the card or other electronic means of payment for
- transactions in which the goods and/or services are not offered or provided by the Contractual Partner but by a third party (prohibition on sub-acquiring);
- Transactions that do not correspond to the agreed industry categories; the processing of transactions outside the industry categories agreed in the contract modules requires the conclusion of an additional contract module;
- Transactions which are unlawful or contrary to public policy in the contracting party’s country, at the place of receipt and/or under the law applicable to the legal transaction with the cardholder/user of electronic means of payment, or which require an official authorisation which the contracting party does not hold;
- Transactions classified under the industry categories ‘Adult Entertainment’ (pornography, erotica, adult entertainment), tobacco, pharmaceuticals, gaming and betting, or auctions; the processing of transactions in these industry categories requires a supplementary agreement;
- Transactions serving to top up other payment methods (e.g. prepaid cards, gift cards or e-wallet solutions); a supplementary agreement is required for the processing of these transactions.
5.3 Acceptance in physical retail
In the case of electronic processing via a hardware terminal, the Contractual Partner must ensure that the reading of card data and any necessary entry of the PIN or scanning of the QR code can be carried out in person at the terminal by the cardholder or the user of electronic payment methods – without the Contractual Partner or any third party viewing the information.
The following applies to card acceptance:
For contactless transactions, the applicable security standard is controlled via the hardware terminal. If the security parameters stored on the card and/or the hardware terminal permit it, neither the entry of the PIN nor a signature is required. Otherwise, the cardholder is prompted to enter the PIN or to sign the receipt generated by the terminal.
If the cardholder’s signature is required for card acceptance, the contracting party may only accept the card provided that it
- is presented within the printed validity period;
- is not recognisably forged;
- bears all security features; and
- is signed by the cardholder.
In the case of transactions requiring a signature, the contracting party must also ensure that
- the cardholder signs the receipt in person in their presence;
- the signature on the paper receipt or on the screen (for mPOS terminals) matches the one on the back of the card; and
- the last four digits of the card number are identical to the last four digits of the number printed on the receipt.
In case of doubt, the contracting party must verify the cardholder’s identity using an official ID document (matching of surname and first name) and note on the receipt that the ID and card details have been compared and verified. For mPOS terminals, this note must be retained together with a reference to the relevant transaction ID.
If a cardholder has forgotten their PIN or the system does not allow further PIN entries, the card must not be accepted in accordance with the fallback procedures set out in clauses 11.2 and 11.3.
5.5 Processing of credits
A credit may only be issued against a previously settled debit and must not exceed the amount of that debit. The Contractual Partner is not permitted to process a refund in any manner other than as described below (e.g. by means of cash or bank transfer). Upon the Contractual Partner issuing a credit, checksum is entitled to demand that the Contractual Partner refund or offset the transaction that has already been settled or reimbursed.
The following applies to card acceptance:
If a transaction is to be refunded to the cardholder in full or in part after it has been processed, the Contractual Partner must issue a credit to the same card. In the case of electronic processing, a credit transaction must be initiated and the corresponding credit notification printed out.
The following applies to the acceptance of other electronic payment methods and to mPOS terminals:
If a transaction is to be refunded in full or in part after it has been processed, the contractual partner has the option of requesting a retrospective credit or partial credit for a transaction from checksum.
6 Receipts
6.1 General
Failure to comply with the obligations set out in clauses 6.2 and 6.3 leads to an increased risk of chargebacks in accordance with clause 10.
6.2 Handover to the cardholder/user of electronic payment methods
In face-to-face transactions, the original receipt printed by the terminal remains with the Contractual Partner (“Merchant Receipt”). The Contractual Partner shall provide the cardholder/user of electronic payment methods with a copy (‘customer receipt’). When using an mPOS terminal, the receipt shall be sent to the cardholder by email upon request. The receipt may be archived in electronic form.
6.3 Retention Obligation
The contracting party shall store all originals of paper documents and copies of electronic documents, all transaction data and daily statements (including individual transaction data), as well as the associated order data and documents, in a secure location for at least 36 months from the date of the transaction.
Electronic data must be stored in encrypted form and protected against unauthorised access. In this context, the contracting party undertakes to comply with the relevant instructions issued by checksum (in accordance with clause 14.2).
7 Submission of Transactions
7.1 Submission deadlines
The Contracting Party undertakes to submit the settled transactions to checksum within 48 hours.
For transactions received in the checksum system later than specified in the above provision, checksum reserves the right not to grant the Contractual Partner any entitlement to remuneration or to reclaim or offset any remuneration already paid.
In distance selling (secure e-commerce, mail/phone orders), the Contractual Partner is also obliged to submit the transactions within 48 hours even if they cannot dispatch/deliver the goods in question immediately or provide the service straight away. The transfer of data from the Contractual Partner’s infrastructure to the system operated by checksum is at the sole risk of the Contractual Partner, regardless of whether this is carried out by the Contractual Partner or by third parties engaged by them.
7.2 Delivery currency
The Contractual Partner must submit the transactions in the currencies agreed in the contract module.
7.3 Retrospective entry (card acceptance)
Provided the Contractual Partner has complied with the submission deadlines in accordance with clause 7.1, manual retrospective entry of lost, incorrect or incomplete transactions is possible in cases where a technical fault in data transmission or processing is the cause. Incorrect bookings (e.g. amount too high or too low) are excluded from this.
The retrospective entry of transactions submitted later than 60 days (debit cards) or 180 days (credit cards) is excluded. The same applies to transactions whose data has not been received by the checksum system.
8 Remuneration
8.1 The Contractual Partner’s Entitlement to Remuneration
checksum shall remunerate the Contractual Partner for the submitted transactions – after deduction of the agreed fees and subject to any subsequent chargebacks – at the agreed remuneration frequency. The details of the settlement are shown on the remuneration statement. On bank holidays, checksum will not process any payments. The Contractual Partner accepts the resulting delays in remuneration. Further country-specific or regional public holidays may lead to additional delays.
8.2 Account for receiving payments
To receive payments, the contracting party must hold an account with a financial institution in the name of the company or the account holder. The IBAN and BIC of the relevant account are required for proper processing.
The Contractual Partner acknowledges that, in the event of incorrect or insufficient account details, payments may either not be executed or may be sent to a different recipient. All costs and fees for investigations or other associated expenses shall be borne by the Contractual Partner.
checksum will transfer payments to the Contractual Partner from the acceptance modules in the form of a collective payment. Should the Contractual Partner wish to receive transfers on a per-card basis, the additional costs shall be borne by them.
8.3 Currency of Remuneration
Remuneration to the Contractual Partner shall generally be made in the local currency valid at the Contractual Partner’s place of business. Should the Contractual Partner wish to receive remuneration in a different currency, the currency submitted by the Contractual Partner shall be converted via CHF into the desired payment currency. The foreign currency conversion rates specified by checksum shall apply in this regard. The Contractual Partner accepts the exchange rates applied by checksum.
8.4 Remuneration statement
checksum shall provide the remuneration statement in the form agreed in the contract module. The remuneration statement shall in all cases be made available via the “Customer or Partner Portal” web service.
The contracting party must raise any objections to the remuneration statement in writing with checksum within 30 days of its provision in the web service or, in the case of other agreed delivery formats, within 30 days of receipt; otherwise, the remuneration statement, including all information contained therein, shall be deemed correct and complete and approved without reservation.
9 Fees
9.1 General
All fees payable by the contracting party to checksum are listed in the contract module. The fees are due for payment upon provision of the service by checksum; they are offset against the accrued remuneration and shown on the remuneration statement (Clause 8.1).
If it is agreed in the contract module that a price and service list is to apply, the currently valid version thereof shall form an integral part of the contract module.
The offsetting of the contracting party’s claims against checksum requires the prior written consent of checksum. checksum is entitled at any time to offset claims against the contracting party.
9.2 Interchange fees
The contracting party will be able to view all information regarding the amount of the interchange fees on the partner or merchant portal.
9.3 Third-party payment fees
Any transfer or foreign currency fees charged by the Contractual Partner’s financial institution in connection with the payment shall be borne by the Contractual Partner and shall be debited directly from the payment. checksum reserves the right to adjust the payment terms in the event of changes in the law and/or changes to the fees charged by third parties.
9.4 Late payment
Should the offsetting of the amounts owed by the contracting party not result in their settlement, checksum shall send the contracting party a payment request for the outstanding amount. The payment deadline is 10 days, after which the contracting party shall be in default without the need for a reminder.
In the event of default by the contracting party, checksum shall be entitled to charge default interest of 5% p.a. on the outstanding amount and to invoice the contracting party for all reminder and collection costs.
9.5 Taxes
Unless otherwise stated, the fees for checksum’s products and services set out in the contract modules are exclusive of VAT, withholding tax and other levies. All taxes and levies which, under the legislation of the contracting party’s country, are or may in future be payable on the services to be provided by checksum under the contract modules shall be borne by the contracting party. The Contractual Partner is in any case obliged to comply with the provisions applicable in its country in relation to indirect taxes, withholding taxes and any other levies. Should third parties make any claims against checksum arising therefrom, the Contractual Partner shall indemnify checksum in full.
10 Chargebacks and Fraud Monitoring
10.1 Chargebacks
Cardholders/users of electronic payment methods and the respective issuers are entitled to dispute a transaction provided that the conditions for initiating a chargeback procedure, in particular the existence of grounds for a chargeback, are met.
If a chargeback procedure is initiated, the Contractual Partner must, at checksum’s request, send copies of all supporting documents and records (as per Clause 6) that may refute the grounds for the chargeback to checksum by registered post within 10 days. If the grounds for the chargeback cannot be refuted by the evidence submitted by the contracting party, or if the required evidence is not submitted by the contracting party within the specified time limit, checksum is entitled to reclaim transactions already paid for from the contracting party or to set these off against payments due to the contracting party (‘chargeback’). This also applies in cases where the delivery of goods or provision of services is not carried out directly by the Contractual Partner but by third parties, for example where the Contractual Partner acts as an intermediary or agent for such third parties.
If, following the initiation of a chargeback procedure, the Contractual Partner intends to issue a credit note in favour of the card or other electronic means of payment used for the disputed transaction, it must inform checksum’s chargeback department of its intention. Upon approval by checksum, the Contractual Partner must issue the credit in accordance with the provisions of Section 5.5 of .
During the chargeback procedure, the contracting party must refrain from taking any legal action against the cardholder or user of other electronic means of payment.
10.2 Grounds for chargebacks in face-to-face transactions (card acceptance)
In the case of card acceptance in face-to-face transactions, checksum is entitled to a right of chargeback in particular if the cardholder disputes the transaction and the contractual partner cannot prove the presence of the card at the point of sale at the time of the transaction. This applies in particular if the contractual partner
- when accepting EMV cards, reads the card data via a ‘non-EMV terminal’ (without an EMV chip reader);
- does not read the card data from either the EMV chip or the magnetic stripe, but enters it manually via the terminal’s keypad (in accordance with the fallback procedures set out in clauses 11.2 and 11.3);
- uses an imprinter when accepting cards and the receipt is not signed by the cardholder.
This list of grounds for chargebacks is not exhaustive.
10.4 Fraud Monitoring
As part of fraud monitoring, checksum may at any time issue instructions to the Contractual Partner to prevent cases of fraud (e.g. the obligation for the cardholder to present identification). The instructions come into force immediately upon notification to the Contractual Partner, and the Contractual Partner is obliged to comply with them in full.
In the event of a justified suspicion of fraud, checksum is entitled to withhold payments to the contractual partner until the suspicion has been clarified. Clause 10.2 remains reserved. In the event of an excessive frequency of fraud cases, checksum also reserves the right to terminate the contract modules with immediate effect.
10.5 Compliance with limits
The Contractual Partner shall ensure that the following monthly limits are observed for the agreed card brands/other electronic means of payment:
- The ratio of the total volume of chargebacks plus credits to gross turnover per month is less than 2%;
- Ratio of number of chargebacks plus credits to number of transactions per month less than 1%;
- Ratio of total volume of fraudulent transactions to gross turnover per month less than 0.75%;
- Ratio of the number of fraudulent transactions to the number of transactions per month less than 3% and fewer than 3 fraudulent transactions.
If any of these limits is exceeded, checksum is entitled to charge the contracting party case-related expenses for each excess chargeback, credit note or fraudulent transaction. Furthermore, checksum is entitled to pass on penalty and/or processing fees charged by the licensors to the contracting party, to defer payment for the submitted transactions for up to 180 days, and to terminate the contract modules with immediate effect.
14 Data Protection
14.1 Processing of personal data
As the data controller, checksum processes personal data in accordance with applicable legislation. The processing of personal data is further detailed in checksum’s privacy policy.
14.2 PCI DSS data security standard
Card data (in particular card numbers and expiry dates) must be protected against loss and unauthorised access by third parties. The data security provisions of the licensors to be observed in this regard are set out in the PCI DSS. In this context, the contracting party undertakes to observe and comply fully and at all times with the currently applicable version of the “Guidelines for Compliance with PCI DSS Security Requirements” issued by checksum, which forms an integral part of these General Terms and Conditions. In particular, the Contractual Partner is obliged to carry out the certification measures, e.g. the Self-Assessment Questionnaire, and to confirm compliance with the PCI DSS to checksum.
In the event of card data theft or a suspected case of card data theft, the Contracting Party must notify checksum immediately. In such a case, the Contracting Party expressly authorises checksum to commission an audit firm accredited by the licensors to prepare a “PCI Audit Report”. In doing so, the circumstances surrounding the occurrence of the damage will be investigated and, at the same time, it will be verified whether the Contracting Party has complied with the PCI DSS. The Contracting Party is obliged to cooperate fully with the audit firm; in particular, it shall grant the audit firm unrestricted access to its premises and to its infrastructure. Once the PCI audit report has been drawn up, the Contractual Partner must, at its own expense, fully rectify all identified security deficiencies within a timeframe specified by checksum. If the investigation reveals that the security requirements under the PCI DSS were not complied with at the time of the data theft, the costs of drawing up the PCI audit report shall also be borne by the Contractual Partner.
checksum is entitled to pass on any claims for damages made by the licensors to the Contractual Partner and/or to terminate the Contract Module with immediate effect if the Contractual Partner fails to comply with the PCI DSS or does not confirm such compliance upon request. This applies equally in the event of card data theft or suspected card data theft.
15 Liability
Notwithstanding any further statutory provisions and unless expressly provided otherwise, the Contractual Partner shall be liable in particular for any damage caused by it or by third parties engaged by it, which arises for checksum as a result of the Contractual Partner’s defective fulfilment of its obligations, namely in the technical, organisational and administrative areas. In particular, checksum is entitled to pass on to the contracting party any claims for damages caused by a culpable breach of duty by the contracting party or by third parties engaged by the contracting party, as well as penalty and/or processing fees charged by the licensors and other case-related expenses. The contracting party shall indemnify checksum in full against these and shall assume these claims and the other case-related expenses.
Unless expressly provided otherwise, checksum or third parties engaged by it shall be liable in cases of intent or gross negligence in accordance with the statutory provisions. Liability on the part of checksum for slight negligence is entirely excluded.
The liability of the contracting parties for culpable injury to life, limb or health, as well as statutory product liability, remains unaffected.
16 Notifications
Unless another form has been expressly agreed in the contract module, notifications shall be made in writing. Written form also includes communications by electronic means (e.g. by email or via a platform provided by checksum as part of a service).
17 Amendments and additions to the contract modules, including fees
Amendments and additions to the contract modules, in particular the General Terms and Conditions and other integral components, must be made in writing to be valid.
checksum reserves the right to amend and supplement the contract modules, in particular the General Terms and Conditions and the other integral components, as well as the fees, at any time. These amendments or supplements shall be notified to the contracting party in writing at least 30 days before they come into force. If the Contractual Partner does not indicate in writing their rejection of the notified amendments or additions before the proposed date of entry into force of the amendments or additions, this shall be deemed to constitute consent to the amendments or additions. This does not apply to changes to the price and service list; the applicable price and service list is published on the partner or dealer portal and comes into force upon publication.
The implementation of protective measures in accordance with clause 2.4, paragraph 3, changes to the system in accordance with clause 4.1, paragraph 3, and changes to fees within an agreed fee framework shall not be deemed to be changes within the meaning of this clause and therefore do not entitle the contracting party to terminate the contract.
18 Entry into force, duration and termination
18.1 Entry into force
The contract module generally comes into force upon dispatch of the activation confirmation by checksum to the contracting party. However, if the contract module explicitly provides for countersignature by checksum, the contract module comes into force upon signature by the contracting parties.
18.2 Duration
The contract module is concluded for an indefinite period, but for at least the agreed minimum contract term, if any. Upon expiry of the minimum contract term, the contract module is automatically extended for a further 12 months, unless it has been terminated by one of the contracting parties.
The contracting party’s right to terminate the contract in accordance with clause 17, as well as the contracting parties’ right to terminate the contract with immediate effect for good cause in accordance with clause 18.4, remain reserved.
18.3 Ordinary termination
Unless otherwise agreed, the contract module may be terminated by registered letter subject to a notice period of 6 months, initially at the end of the minimum contract term, and subsequently on any date falling 12 months after the end of the minimum contract term. If there is no minimum contract term, the termination date shall be the annually recurring date on which the Contract Module was signed by the contracting party. The termination of a Contract Module does not result in the termination of the other Contract Modules.
18.4 Extraordinary termination
The contracting parties are entitled to terminate the contract modules with immediate effect at any time if there are good cause. Good cause includes, in particular:
- serious or repeated breaches of the provisions of the contract module by one of the contracting parties;
- repeated complaints/chargebacks and/or transactions reported as fraudulent by card issuers or issuers of other electronic payment instruments (in accordance with clause 10);
- other discrepancies in settled transactions;
- a material change in the contractual partner’s ownership and control structure;
- the commencement of insolvency proceedings in respect of the contracting party’s assets.
The extraordinary termination of contract modules for the acceptance of cashless payment methods entitles checksum to immediately terminate all existing contract modules.
18.5 Automatic termination of the contract
The contract modules are automatically terminated without the need for notice if the contracting party has not submitted any transactions for a period of two years.
The automatic termination of contract modules for the acceptance of cashless payment methods results in the automatic termination of all existing contract modules.
18.6 Consequences of contract termination
The obligations under clauses 6.3 (Duty of retention), 14 (Data protection), 15 (Liability), 18.6 (Consequences of termination of the contract), 19 (Confidentiality), 20.3 (Prohibition of assignment) and 20.7 (Governing law and jurisdiction) shall continue to apply even after the termination of a contract module.
Upon termination of the contract module, the contracting party must remove all references to the relevant services provided by checksum that are visible to customers.
Upon termination of a contract module, checksum is entitled to withhold payment of remuneration to the contracting party with immediate effect and for 180 days beyond the date of termination of the contract module, in order to set it off against any claims that may arise subsequently, in particular chargebacks. Should criminal or other legal proceedings be initiated against the Contractual Partner or a criminal complaint be filed against the Contractual Partner, checksum reserves the right to withhold payment of remuneration at least until the conclusion of the proceedings.
19 Confidentiality
The contracting parties mutually undertake to keep confidential the agreed terms and conditions, as well as all information, documents, data and procedural techniques that become known to them during the performance of the contract modules, which are marked or recognisable as confidential and which are neither publicly nor generally accessible, and to make these available to third parties only with the prior written consent of the other contracting party. This shall not prevent the contracting parties from disclosing confidential information where such disclosure is based on the application of mandatory statutory provisions.
20 Final Provisions
20.1 Right of checksum to issue instructions
The contracting party is obliged to comply with the technical, organisational and administrative instructions and guidelines issued by checksum and by the terminal or infrastructure suppliers.
20.2 Brokerage activities of checksum
checksum also acts as an intermediary for other acquirers and infrastructure providers, brokering their contracts in their name, at their risk and for their account. The contracting parties for the services provided in this way are the respective service provider and the contracting party.
20.3 Prohibition on Assignment
Any assignment of the contracting party’s rights or obligations towards checksum is only permitted with the prior written consent of checksum.
20.4 Involvement of third parties/transfer to group companies
checksum reserves the right to engage third parties at any time to fulfil its contractual obligations without having to notify the contracting party.
checksum is entitled to transfer the contractual module to another group company. In such cases, the contracting party shall be notified in an appropriate manner.
20.5 Waiver of Rights
Should checksum fail to assert any rights arising from the contractual modules, this shall in no way constitute a waiver of such rights, unless checksum issues an express written waiver.
20.6 Severability clause
If any provision of the contract modules (including fees) is declared invalid, the remaining provisions shall remain unaffected and shall be interpreted as if the relevant contract module had been concluded without the invalid provision. The same applies to any gaps in the contract.
20.7 Applicable Law and Jurisdiction
All legal relationships between the contracting party and checksum arising from the concluded contract modules are governed by Swiss law. The exclusive place of jurisdiction is Zug.