Channel Schedules set out the technical, security, and compliance requirements applicable to each payment environment. Each Schedule becomes operative upon activation of the relevant environment and forms part of the Agreement.
Role codes: M Merchant · MP Marketplace · P Partner · O Operator
Where a Customer operates in more than one environment, all applicable Schedules apply simultaneously.
Applies to: Merchants (M) and Marketplaces (MP)
This Schedule governs the Customer’s use of Dintero’s payment services in the online environment and forms part of the Agreement upon activation. Capitalised terms have the meanings given in the General Terms or the applicable Supplementary Terms.
O.1.1 This Schedule is activated by default for all Customers upon execution of the Agreement. It applies to all transactions initiated by End Buyers through a website, web application, or mobile application.
O.1.2 Where a Customer also operates in-store or via payment links, the In-store Schedule and/or the Payment Link Schedule apply to those environments in addition to this Schedule.
O.2.1 The Customer shall integrate with Dintero’s payment services using one of the integration methods published in Dintero’s technical documentation. The Customer shall at all times use the most current version of Dintero’s integration that Dintero designates as supported.
O.2.2 The Customer shall register all websites, web applications, and mobile applications as Stores in the Backoffice before processing transactions.
O.2.3 The Customer shall not store, log, or cache full card numbers (PAN), CVV2 codes, or other sensitive authentication data at any point during or after a transaction. Card data must be transmitted directly to Dintero’s hosted payment page or processed via Dintero’s tokenisation service.
O.2.4 The Customer shall display Dintero’s payment page or embed Dintero’s payment components in a manner consistent with Dintero’s integration documentation. The Customer shall not modify or obscure the payment page in a way that misleads End Buyers about the nature of the payment process.
O.3.1 The applicable PCI-DSS Self-Assessment Questionnaire (SAQ) type depends on the Customer’s integration method:
O.3.2 The Customer shall complete the applicable SAQ annually and provide Dintero with evidence of compliance upon request.
O.3.3 Where the Customer’s integration requires SAQ D compliance, the Customer shall also undergo an annual network scan by an Approved Scanning Vendor (ASV).
O.4.1 All transactions processed in the online environment are subject to SCA requirements under PSD2 and applicable national law unless a recognised exemption applies.
O.4.2 Dintero applies 3D Secure authentication to card transactions as the primary SCA mechanism. The Customer shall not attempt to suppress or bypass 3D Secure authentication unless an exemption has been explicitly agreed with Dintero in writing.
O.4.3 Where an SCA exemption is applied and the transaction is subsequently subject to a chargeback, the Customer bears full liability for that chargeback regardless of whether the exemption was applied by Dintero, the Acquirer, or the issuer.
O.4.4 The Customer is responsible for ensuring that its technical integration correctly passes the transaction context required for SCA exemption processing (e.g. transaction risk analysis data, low-value flags, recurring transaction identifiers).
O.4.5 SCA exemption activation. The right to claim specific SCA exemptions — including but not limited to transaction risk analysis (TRA) exemptions and low-value exemptions — may require a separate written agreement with Dintero. Where such an agreement is required, the Customer shall not activate or rely on the relevant exemption until that agreement is in place. Exemption requests that are not supported by the required agreement or transaction flag will be disregarded and the transaction will be subject to full SCA. Additional fees may apply for exemption processing as set out in Dintero’s prevailing price list.
O.4.6 SCA credential confidentiality. The Customer shall not request or store End Buyer SCA credentials (including passwords, PINs, or biometric data used for authentication). SCA must be performed exclusively through the mechanisms provided by Dintero, the Acquirer, or the issuer.
O.5.1 Before resubmitting a transaction that has previously been authorised, declined, or returned an ambiguous response, the Customer shall verify that the original transaction has not already been processed. Resubmission of a duplicate transaction without such verification is prohibited.
O.5.2 Where the Customer’s system generates a retry or resubmission, the Customer shall transmit the original transaction identifier to enable duplicate detection by Dintero’s systems. The Customer shall not generate a new transaction identifier for a retry that relates to the same End Buyer purchase.
O.5.3 Where Dintero detects a probable duplicate transaction, Dintero may decline or hold the second submission and notify the Customer. The Customer shall investigate and confirm whether the transaction is a duplicate before requesting release.
O.6.1 Recurring Payments, Card-on-File arrangements, and Merchant Initiated Transactions are governed by Schedule R — Recurring Payments and Merchant Initiated Transactions, which applies in addition to this Schedule and requires separate activation.
O.6.2 Where a Customer processes any Transaction that is not fully initiated and authenticated by the End Buyer in real time, Schedule R applies and must be complied with in full.
O.7.1 The Customer shall provide End Buyers with a transaction receipt or confirmation containing at minimum:
(a) the date and time of the transaction;
(b) the transaction amount and currency;
(c) a description of the goods or services purchased;
(d) the Customer’s name and contact information; and
(e) a transaction reference number.
O.7.2 Receipts may be provided electronically (by email or on-screen confirmation). Physical receipts are not required in the online environment.
O.8.1 All transactions in the online environment are card-not-present transactions. The Customer bears full liability for chargebacks on card-not-present transactions as set out in the applicable Supplementary Terms.
O.8.2 The Customer shall retain the following documentation for a minimum of five (5) years to support chargeback disputes:
(a) proof of delivery or service fulfilment;
(b) End Buyer consent records (including IP address, timestamp, and acceptance of terms);
(c) SCA authentication results and 3D Secure authentication data; and
(d) correspondence with the End Buyer relating to the transaction.
O.8.3 High-risk goods. Where a transaction relates to the sale of high-value or high-risk goods (including electronics, jewellery, luxury goods, or categories designated as high-risk in Dintero’s prevailing guidelines), the Customer shall obtain and retain signed or electronically confirmed proof of delivery from the End Buyer. Where delivery is made by carrier, tracked delivery with confirmed delivery status satisfies this requirement. Without such evidence, the Customer may be unable to successfully dispute a chargeback.
Applies to: Merchants (M), Marketplaces (MP), and Partners (P)
This Schedule governs the Customer’s use of Dintero’s payment services in the in-person (card-present) environment, referred to by Dintero as In-Person Payments (IPP), and forms part of the Agreement upon activation. Capitalised terms have the meanings given in the General Terms or the applicable Supplementary Terms.
S.1.1 This Schedule is activated when Dintero enables IPP terminal functionality on the Customer’s Account. It applies to all transactions where the End Buyer and the payment card (or device) are physically present at the point of sale.
S.1.2 The Customer must request activation of the in-person environment through the Backoffice or by contacting Dintero. Activation is subject to Dintero’s assessment and any applicable Acquirer requirements.
S.1.3 Compliance with instructions. The Customer shall at all times comply with all applicable instructions, technical specifications, and operational guidelines issued by Dintero in connection with the IPP service, including instructions published in Dintero’s technical documentation, communicated via the Backoffice, or otherwise provided in writing. Where Dintero’s instructions conflict with instructions from a third-party equipment supplier, Dintero’s instructions take precedence. Failure to follow applicable instructions may result in the Customer bearing sole liability for any resulting loss.
S.1.4 Geographic restriction. The Customer may only use the IPP services within the geographic areas covered by the Agreement. Use of the Dintero Services outside those areas is prohibited without Dintero’s prior written consent.
S.2.1 The Customer may only use Terminals that have been supplied or approved by Dintero. Use of unapproved Terminals is prohibited and may result in immediate suspension of in-person processing.
S.2.2 The Customer shall register each Terminal on its Account in the Backoffice before processing transactions. Each Terminal must be associated with the correct Store.
S.2.3 Physical security. The Customer shall protect all Terminals from tampering, theft, and unauthorised access by:
(a) inspecting each Terminal upon delivery and at regular intervals for signs of tampering or unauthorised attachments;
(b) positioning Terminals so End Buyers can view the screen and enter their PIN without being observed by others;
(c) storing Terminals securely when not in use and not leaving them unattended in public areas;
(d) restricting access to authorised personnel only; and
(e) following Dintero’s and the manufacturer’s security guidelines as published from time to time.
S.2.4 Tamper response. If the Customer discovers or suspects tampering with a Terminal, the Customer must immediately: (a) cease using the device; (b) isolate it physically; and (c) notify Dintero in writing without delay. The Customer shall preserve all evidence and cooperate fully with any investigation.
S.2.5 The Customer shall not: (a) attempt to repair, modify, or open any Terminal; (b) circumvent or disable any security feature; (c) connect a Terminal to an untrusted network or device; or (d) install unauthorised software or hardware on a Terminal.
S.2.6 Lost or stolen Terminals. Lost or stolen Terminals must be reported to Dintero immediately. The Customer remains liable for transactions processed on a Terminal until the report has been made and the Terminal has been deactivated by Dintero.
S.2.7 Terminal relocation. The Customer shall not relocate a Terminal to a different Store, transfer it to a different channel, or transfer it to another entity without Dintero’s prior written consent. Where the Customer intends to relocate a Terminal, it shall notify Dintero at least four (4) weeks in advance. Unauthorised relocation or transfer may result in the Customer bearing sole liability for all losses arising from transactions processed at the unauthorised location.
S.2.8 Third-party equipment. Where the Customer uses technical equipment supplied by a third party in connection with the IPP service, the Customer shall enter into a separate written agreement with that supplier and shall ensure that the equipment meets all requirements of this Agreement. Dintero must be given the opportunity to inspect and approve third-party equipment before it is put into production. If deficiencies or deviations are discovered, Dintero may require immediate remediation; if not remediated, Dintero may terminate the relevant Store under Clause 9.5 of the General Terms. Where the Customer uses unapproved third-party equipment, the Customer is solely liable for all losses arising for both the Customer and Dintero from that use.
S.3.1 Terminals supplied by Dintero are PCI PTS-certified. The Customer shall not connect Terminals to any system or network that could compromise their security certification. All Terminals must be PCI PTS-certified and listed on the PCI Security Standards Council’s approved device list at the time of use. The Customer shall not use a Terminal that has exceeded its PCI PTS approval period or been removed from the approved list, unless Dintero has expressly confirmed in writing that it may continue to be used pending replacement.
S.3.2 The Customer shall not store, retain, or log any Sensitive Authentication Data, including full magnetic stripe data, PIN data, or card security codes (CVV/CVC). The Customer shall ensure that its POS systems and network infrastructure do not intercept or store card data beyond what is strictly necessary for processing the relevant Transaction, and in no case beyond what is permitted under PCI-DSS.
S.3.3 Account Data Compromise. In the event of an actual or suspected Account Data Compromise involving a Terminal or related POS systems, the Customer must notify Dintero no later than forty-eight (48) hours after discovery. The Customer shall also comply with any notification obligations toward End Buyers and regulators as required under GT 12 (Privacy and Data Protection) and applicable law.
S.3.4 The applicable PCI-DSS SAQ type depends on the Customer’s setup:
S.3.5 Where Dintero provides a P2PE-validated solution, the Customer may qualify for reduced PCI-DSS scope. The Customer is responsible for confirming its applicable SAQ type with Dintero.
S.4.1 EMV chip acceptance. The Customer must accept EMV chip card transactions at all Terminals. Where an End Buyer presents a chip card, the transaction must be processed using the chip. The Customer shall not encourage End Buyers to use the magnetic stripe in preference to the chip.
S.4.2 Contactless acceptance. Terminals must be capable of, and the Customer must accept, contactless card and device payments (NFC) at all active Stores. Contactless transactions must comply with applicable Scheme Rules regarding transaction limits and CVM requirements. Where a contactless transaction exceeds the applicable SCA threshold under PSD2, the Terminal must prompt for PIN or other required CVM.
S.4.3 Honor-All-Cards. The Customer must accept all valid, unexpired cards bearing the logos of Payment Methods activated on its Account, regardless of issuer or country of issuance. The Customer must not:
(a) refuse a card solely because it is debit, credit, prepaid, or commercial;
(b) impose additional requirements or fees on End Buyers for using a specific card type, except as expressly permitted by applicable law and Scheme Rules; or
(c) establish minimum or maximum transaction amounts not permitted by the applicable Scheme Rules.
S.4.4 No surcharging. The Customer shall not impose any surcharge or additional cost on End Buyers for paying by card, except to the extent expressly permitted by applicable Scheme Rules and local law. Where surcharging is permitted, the surcharge may not exceed the Customer’s direct cost of accepting the relevant card type.
S.4.5 Payment Method logos. The Customer must display logos and acceptance marks for all Payment Methods activated on its Account in accordance with the relevant brand guidelines. At physical Stores, accepted card scheme logos must be clearly visible to End Buyers at or near the point of payment.
S.4.6 Authorisation. The Customer must obtain online authorisation from Dintero for all card Transactions. The Customer shall not complete a declined Transaction and shall not split a single Transaction into multiple smaller transactions to avoid authorisation thresholds or Scheme Rules.
S.4.7 Manual key-entry. The Customer shall process all card-present transactions through the Terminal and shall not manually key-enter card details unless the Terminal is unable to read the card and manual entry is permitted by the relevant Scheme Rules.
S.4.8 Authentication. The Customer shall always request PIN or contactless authentication as required by the Terminal and Scheme Rules. The Customer shall not complete a transaction if the End Buyer’s authentication fails, except where permitted by applicable fallback procedures in the Scheme Rules.
S.4.9 Contactless limits. Contactless transaction limits are governed by the applicable Scheme Rules and may be set by the relevant Acquirer. The Customer shall not split a single transaction across multiple contactless payments to circumvent contactless limits.
S.4.10 The Customer shall not process a card-present transaction for an amount different from the amount agreed with the End Buyer at the point of sale.
S.4.11 Card verification. Where a card is presented physically, the Customer’s staff shall, to the extent reasonably practicable:
(a) verify that the card has not visibly expired;
(b) check that the card does not show visible signs of tampering, alteration, or damage; and
(c) where a signature-based transaction is processed, verify that the signature on the receipt matches the signature on the back of the card.
The Customer shall not complete a transaction if the card shows clear signs of having been tampered with or counterfeited.
S.4.12 Identity verification. The Customer shall verify the End Buyer’s identity (by checking a government-issued photo ID) where:
(a) the Terminal prompts for ID verification;
(b) a transaction involves manual key-entry of card data;
(c) the Customer has reasonable grounds to suspect that the card is being used fraudulently; or
(d) the applicable Scheme Rules require identity verification for the transaction category.
Where ID verification is performed, the Customer shall retain a note of the verification having been carried out but shall not copy, photograph, or retain the ID document itself.
S.4.13 Gratuities (tips). Where the Customer accepts tips or gratuities, the tip amount must be either: (a) included in the total transaction amount authorised by the End Buyer at the Terminal before authentication; or (b) processed as a separate supplementary authorisation where permitted by the applicable Scheme Rules, following the End Buyer’s explicit approval of the tip amount. The Customer shall not add a gratuity to a completed transaction after the End Buyer’s authentication without obtaining the End Buyer’s explicit consent to the adjusted total.
S.4.14 Magnetic stripe fallback. The Customer may use magnetic stripe processing only as a fallback where the chip reader fails to read the card’s chip after at least one attempt. The Customer shall not routinely process magnetic stripe transactions in preference to chip-based processing. Where magnetic stripe fallback is used, the Customer shall log the fallback and, where required by applicable Scheme Rules, the Customer bears full liability for any resulting chargeback.
S.4.15 Card confiscation. Where a Terminal displays an instruction to retain the End Buyer’s card, the Customer’s staff may politely retain the card only if it can be done without confrontation or risk to personal safety. The Customer shall not use physical force or coercion to confiscate a card. Any retained card shall be reported to Dintero or the relevant issuer without delay.
S.4.16 Klarna at POS. Where the Customer accepts Klarna at POS, the Customer must comply with Klarna’s POS-specific terms as communicated by Dintero, including requirements regarding customer identification and verification, receipt and confirmation process, return and refund handling, and applicable SCA requirements.
In the event of conflict between this Schedule and the applicable Scheme Rules, the Scheme Rules prevail.
S.5.1 In the in-person environment, SCA is fulfilled through chip-and-PIN, chip-and-signature, or contactless authentication with the applicable transaction limit, as required by the Terminal and the relevant Scheme Rules.
S.5.2 The Customer shall not disable or bypass the Terminal’s SCA mechanisms.
S.6.1 The Customer shall ensure that all staff who handle in-person transactions have received adequate training in the correct use of Terminals, the Customer’s obligations under this Schedule, and the procedures for identifying and responding to suspected fraud or tampered cards. Training must cover, as a minimum:
(a) correct card acceptance and verification procedures;
(b) recognition of signs of card tampering or Terminal skimming;
(c) PIN and authentication procedures;
(d) the refund and cancellation process; and
(e) the Customer’s escalation and reporting obligations under this Schedule and the General Terms.
S.6.2 The Customer is responsible for ensuring that any third-party contractors or agents operating Terminals on the Customer’s behalf are equally aware of and compliant with the requirements of this Schedule.
S.7.1 The Customer shall offer End Buyers a receipt for each completed transaction. Receipts may be provided in printed or electronic form.
S.7.2 Receipts must contain at minimum:
(a) the date and time of the transaction;
(b) the transaction amount and currency;
(c) the last four digits of the card number (masked PAN);
(d) the payment method used (e.g. Visa, Mastercard, Vipps);
(e) the authorisation code; and
(f) the Customer’s trading name and Store identifier.
S.7.3 Where applicable law requires a printed receipt, the Customer shall provide one. The Customer is responsible for ensuring compliance with local receipt requirements in each jurisdiction in which it operates.
S.8.1 Card-present transactions authenticated via chip-and-PIN carry a significantly reduced chargeback risk compared to card-not-present transactions. However, the Customer remains liable for chargebacks arising from:
(a) counterfeit card fraud where the Terminal did not use chip-based authentication;
(b) transactions where the Customer bypassed PIN or chip authentication;
(c) disputes relating to the delivery of goods or services regardless of authentication method; or
(d) any other chargeback reason permitted under the applicable Scheme Rules.
S.8.2 The Customer shall retain the following documentation for a minimum of five (5) years:
(a) Terminal transaction logs;
(b) signed receipts where applicable;
(c) proof of goods or service delivery; and
(d) any other documentation relevant to the transaction.
S.9.1 Refunds for card-present transactions shall be returned to the same card used for the original purchase via the Terminal. Cash refunds for card transactions are prohibited.
S.9.2 The Customer may not accept cash or other compensation in exchange for processing a card refund.
S.10.1 Procurement models. Terminals supplied by Dintero are available under two models:
(a) Purchase — the Customer buys the Terminal outright. Title and ownership pass to the Customer upon receipt of full payment. Risk of loss or damage passes to the Customer upon delivery. The Customer is responsible for the Terminal from the point of delivery.
(b) Subscription — Dintero or its appointed supplier retains ownership of the Terminal throughout the Subscription period. The Customer has a non-exclusive, non-transferable right to use the Terminal for the duration of the Subscription period, subject to this Schedule. The Customer acquires no ownership rights over a Terminal provided under a Subscription.
The applicable model, associated fees, and Subscription period are set out in the applicable price list.
S.10.2 Delivery and acceptance. The Customer shall inspect each Terminal upon delivery and notify Dintero of any visible damage, defects, or missing components within five (5) Banking Days of receipt. Failure to notify within this period constitutes acceptance of the Terminal in good working order. Delivery timescales are indicative only and Dintero shall not be liable for delays outside its reasonable control.
S.10.3 Care and maintenance. The Customer shall handle all Terminals with reasonable care and in accordance with Dintero’s instructions. The Customer is responsible for any damage to a Terminal that goes beyond normal wear and tear, regardless of whether the Terminal was purchased or provided under a Subscription.
S.10.4 Loss and damage. The Customer shall notify Dintero without delay of any Terminal that is lost, stolen, or damaged. Where a Terminal is lost, stolen, or damaged beyond repair:
(a) for a purchased Terminal: the Customer bears the cost of replacement if replacement is requested;
(b) for a Subscription Terminal: the Customer is liable for the then-current purchase price of the Terminal as set out in the applicable price list, less any amounts already paid under the Subscription. The Subscription continues following replacement and the replacement Terminal remains Dintero’s property.
For repairable damage that does not require full replacement, Dintero will invoice the Customer for reasonable repair costs. Dintero may deduct the applicable replacement or repair cost from the Customer’s Balance. The Customer shall maintain appropriate insurance covering Subscription terminals throughout the Subscription period.
S.10.5 Software updates and connectivity. Dintero may from time to time update Terminal software remotely, including updates required by Scheme Owners or for PCI PTS compliance. The Customer shall ensure that Terminals remain connected to the internet or otherwise reachable for software updates as specified in Dintero’s technical documentation. Failure to install a mandatory update within the specified timeframe may result in suspension of the affected Terminal until the update is applied.
S.11.1 Whether a Terminal is purchased or provided under a Subscription, the Customer receives only a limited, non-exclusive, non-transferable licence to use the terminal software and firmware solely for processing payments through the Dintero Services (the “Software Licence”). The Software Licence is not transferable with the Terminal hardware.
S.11.2 The Customer shall not:
(a) copy, decompile, reverse-engineer, or disassemble the software;
(b) attempt to access the source code;
(c) use the software for any purpose other than payment processing through the Dintero Services; or
(d) sub-licence or transfer the Software Licence to any third party.
S.11.3 Software Licence Fee (purchased Terminals). For Terminals purchased outright, the Software Licence is not included in the hardware purchase price and is invoiced separately at the rate set out in the applicable price list, commencing from the date the Terminal is activated on the Customer’s Account. The Software Licence Fee may be changed with at least one (1) month’s written notice. If the Customer does not accept an increase, the Customer may deactivate the relevant Terminal by written notice within the notice period.
S.11.4 Software Licence Fee (Subscription terminals). For Terminals provided under a Subscription, the Software Licence is included in the Subscription Fee.
S.12.1 Support. Dintero provides first-level technical support for Terminal. The Customer must contact Dintero directly for all support requests, providing the Terminal serial number, a description of the fault, and any error messages. Support contact details and channels are available via the Dintero support portal.
S.12.2 Warranty. Terminals are covered by the manufacturer’s limited warranty for one (1) year from the date of delivery. Warranty claims must be submitted to Dintero in writing. The warranty does not cover damage from misuse, neglect, or physical impact; unauthorised modification or repair; liquid damage; use outside manufacturer specifications; or normal wear and tear.
S.12.3 Replacement. Where a fault is confirmed, Dintero will dispatch a replacement Terminal within two (2) Banking Days. The cost to the Customer depends on the circumstances:
S.12.4 Return of defective Terminal. In all cases, the Customer must return the defective Terminal within seven (7) calendar days of receiving the replacement, using the return process communicated by Dintero. Return shipping is at Dintero’s cost for in-warranty replacements and at the Customer’s cost for out-of-warranty Subscription replacements where the damage was Customer-caused. Failure to return within this period entitles Dintero to invoice the Customer for the full then-current purchase price of the unreturned Terminal.
S.12.5 Service continuity. Dintero maintains arrangements to ensure terminal payment processing services remain available to Customers for the duration of the Agreement. In the event of a material change to the terminal platform or underlying service provider, Dintero will provide advance notice and use reasonable efforts to ensure continuity of service.
S.13.1 Minimum Commitment Period. Each Subscription has a Minimum Commitment Period as set out in the applicable price list, commencing from the date of activation of the relevant Terminal.
S.13.2 Early termination fee. If the Customer terminates a Subscription before expiry of the Minimum Commitment Period — other than due to Dintero’s material breach — the Customer shall pay the early termination fee set out in the applicable price list per remaining month of the Minimum Commitment Period, due immediately upon termination.
S.13.3 Termination of the Agreement terminates all active Subscriptions and triggers the early termination fee for any Subscription within its Minimum Commitment Period.
S.13.4 Return of Subscription terminals. Upon expiry or termination of a Subscription or the Agreement, the Customer shall return all Subscription terminals to Dintero in good working order (subject to normal wear and tear), within ten (10) Banking Days of the termination date, using the return process communicated by Dintero. If a Terminal is not returned within this period, Dintero may charge a daily late-return fee at the rate set out in the applicable price list and may invoice the Customer for the full then-current purchase price of any unreturned Terminal.
S.13.5 No transfer. The Customer shall not sell, sub-let, pledge, encumber, or otherwise transfer a Subscription terminal or the Customer’s rights under a Subscription to any third party without Dintero’s prior written consent.
Purchased Terminals are not subject to a return obligation. Upon termination of the Agreement, Dintero will deactivate purchased Terminals and is not obliged to reactivate them under any future agreement. The Customer may retain the hardware but it will no longer be supported or connected to Dintero’s payment infrastructure. The Software Licence terminates automatically on the date the Agreement ends.
S.15.1 Dintero may with immediate effect suspend or terminate the Customer’s right to use Terminal where:
(a) the Agreement or the Customer’s Account is suspended or terminated for any reason;
(b) the Customer breaches any provision of this Schedule and fails to remedy the breach within ten (10) Banking Days of written notice from Dintero;
(c) the Customer fails to install a mandatory security or compliance update within the timeframe specified by Dintero;
(d) Dintero has reasonable grounds to believe Terminal is being used fraudulently or unlawfully; or
(e) the Customer becomes insolvent, is placed in liquidation, or is subject to analogous insolvency proceedings.
S.15.2 Upon suspension or termination, the Customer must immediately cease using the affected Terminal. Where the arrangement is a Subscription, the return obligations in clause S.13.4 apply immediately on termination.
S.16.1 Dintero’s maximum aggregate liability arising out of or in connection with Terminal shall not exceed the amounts paid by the Customer to Dintero for the relevant Terminal in the twelve (12) months preceding the relevant claim. This cap is in addition to, and does not replace, the general liability cap in Clause 13.2 of the General Terms.
S.16.2 Dintero shall not be liable for any loss of transaction data, loss of revenue, or business interruption arising from a fault or failure of Terminal.
S.16.3 The Customer is solely responsible for ensuring Terminal is used in compliance with all applicable Scheme Rules and this Schedule. Fines, penalties, or costs imposed on Dintero by any Scheme Owner, Financial Institution, or Intermediary as a result of the Customer’s non-compliance shall be passed on to the Customer and constitute a debt immediately due and payable.
Applies to: Merchants (M) and Marketplaces (MP)
This Schedule governs the Customer’s use of Dintero’s payment link functionality and forms part of the Agreement upon activation. Capitalised terms have the meanings given in the General Terms or the applicable Supplementary Terms.
P.1.1 This Schedule is activated when Dintero enables payment link functionality on the Customer’s Account. It applies to all transactions initiated via a payment link sent to an End Buyer by SMS, email, or other messaging channel.
P.1.2 Payment links enable the Customer to request payment from an End Buyer without requiring the End Buyer to visit a website or be physically present. The End Buyer completes payment via a Dintero-hosted payment page accessed through the link.
P.1.3 This Schedule applies in addition to the Online Schedule. The PCI-DSS and SCA requirements of the Online Schedule apply equally to payment link transactions unless this Schedule states otherwise.
P.2.1 Payment links may be used for:
(a) invoicing and request-for-payment scenarios where the End Buyer is not present at the time of sale;
(b) post-service payment collection (e.g. after a service has been delivered);
(c) instalment or partial payment collection; and
(d) any other use case approved by Dintero in writing.
P.2.2 Payment links shall not be used for:
(a) collecting payment for goods or services that have not been agreed or ordered by the End Buyer;
(b) unsolicited payment requests (spam);
(c) any transaction that would constitute a prohibited activity under Section 6 of the General Terms; or
(d) circumventing SCA requirements applicable to the transaction.
P.3.1 Payment links must be generated through Dintero’s API or Backoffice. The Customer shall not generate or distribute payment links through any other mechanism.
P.3.2 Each payment link shall correspond to a specific transaction with a defined amount and description. Generic or open-amount payment links are not permitted unless explicitly approved by Dintero.
P.3.3 Payment links have a validity period as configured in the Backoffice or API. Expired links shall not be reactivated. The Customer shall issue a new link if payment is required after a link has expired.
P.3.4 The Customer shall send each payment link only to the intended End Buyer. The Customer is responsible for ensuring that payment links are not forwarded, shared, or accessible to unintended recipients.
P.4.1 All payment link communications sent to End Buyers shall:
(a) clearly identify the Customer as the requesting party;
(b) state the amount payable and the reason for the payment;
(c) include a clear description of the goods or services to which the payment relates; and
(d) include contact information for the Customer’s customer service.
P.4.2 The Customer shall not send payment link communications in a manner that could reasonably be mistaken for phishing or fraudulent messages. Communications shall be sent from a verified sender identity (e.g. a registered business number or email domain).
P.4.3 The Customer shall comply with applicable marketing, electronic communications, and data protection legislation when sending payment link messages, including obtaining any required consent from End Buyers.
P.5.1 Payment link transactions are card-not-present transactions and are subject to SCA requirements under PSD2 and applicable national law.
P.5.2 Dintero applies SCA via 3D Secure on the Dintero-hosted payment page. The Customer shall not attempt to configure payment links in a way that suppresses or bypasses SCA.
P.5.3 Where an SCA exemption is applied to a payment link transaction and the transaction is subsequently subject to a chargeback, the Customer bears full liability as set out in the Online Schedule.
P.6.1 Upon successful payment, Dintero will display a payment confirmation to the End Buyer on the payment page. The Customer is responsible for providing the End Buyer with a full transaction receipt as set out in the Online Schedule.
P.6.2 Where the payment link relates to an invoice, the Customer shall mark the invoice as paid and provide the End Buyer with confirmation without undue delay following receipt of payment notification from Dintero.
P.7.1 Payment link transactions are card-not-present transactions. The Customer bears full liability for chargebacks as set out in the Merchant Terms or Marketplace Terms and the Online Schedule.
P.7.2 In addition to the documentation requirements in the Online Schedule, the Customer shall retain records of:
(a) the payment link generation timestamp and the End Buyer’s contact details to which the link was sent;
(b) End Buyer confirmation of the order or service prior to payment; and
(c) delivery or fulfilment records for the underlying goods or services.
Applies to: Merchants (M) and Marketplaces (MP)
This Schedule governs the Customer’s use of Dintero’s services for Recurring Payments, Card-on-File arrangements, and Merchant Initiated Transactions (MIT), and forms part of the Agreement upon activation. It supplements the Online Schedule. Capitalised terms have the meanings given in the General Terms or the applicable Supplementary Terms.
R.1.1 This Schedule is activated when Dintero enables MIT and Recurring Payment functionality on the Customer’s Account. Activation requires a separate written agreement between Dintero and the Customer and is subject to Dintero’s assessment of the Customer’s business model, volume, and risk profile.
R.1.2 This Schedule applies to all Transactions initiated by the Customer using stored card credentials, including:
(a) Recurring Payments — charges made at agreed intervals for a fixed amount, where the End Buyer has given standing authority (for example, subscriptions and membership fees);
(b) Unscheduled MIT — charges initiated by the Customer at a time or for an amount not fixed in advance, based on a prior mandate from the End Buyer (for example, top-ups, balance shortfalls, or charges triggered by actual usage); and
(c) Card-on-File transactions — individual charges made using stored card credentials following a specific End Buyer instruction or trigger event.
R.1.3 This Schedule applies in addition to the Online Schedule. The PCI-DSS, SCA, receipt, and chargeback requirements of the Online Schedule continue to apply to MIT transactions unless this Schedule states otherwise.
R.2.1 Before initiating any MIT, the Customer must have obtained a valid written mandate from the End Buyer. The mandate must specify, at minimum:
(a) the Customer’s identity and the purpose of the charge;
(b) the payment method and the card to be charged;
(c) for Recurring Payments: the charge amount, billing frequency, and the duration or termination conditions;
(d) for Unscheduled MIT: a clear description of the circumstances under which the Customer may initiate a charge and an acknowledgement that the amount may vary; and
(e) the procedure by which the End Buyer may cancel the mandate.
R.2.2 The mandate must be obtained in a manner that constitutes explicit, informed consent. A general acceptance of the Customer’s terms of sale is not sufficient — a separate, affirmative consent action is required, as specified in the applicable Supplementary Terms.
R.2.3 The Customer shall retain a copy of each mandate in a durable and retrievable format for a minimum of five (5) years from the date of the last Transaction made under that mandate.
R.3.1 The first Transaction made under any Card-on-File arrangement, Recurring Payment, or Unscheduled MIT mandate must be a Cardholder Initiated Transaction (CIT) authenticated using Strong Customer Authentication (SCA) via 3D Secure.
R.3.2 The Customer shall transmit the recurring or Card-on-File flag in the transaction data for the initial CIT to enable correct identification and processing by the Acquirer and card scheme.
R.3.3 The Customer shall not initiate subsequent MIT Transactions until the initial CIT has been successfully Authorised and Captured.
R.4.1 Following a successful initial CIT, the Customer may initiate subsequent MIT Transactions without requiring the End Buyer to actively participate in each Transaction, provided that:
(a) the mandate obtained under R.2 remains valid and has not been revoked;
(b) each Transaction is initiated within the scope and conditions of the mandate;
(c) the Customer transmits the correct MIT indicator and a reference to the original CIT transaction identifier in each subsequent Transaction; and
(d) for Recurring Payments: the charge amount does not exceed the amount specified in the mandate unless the Customer has obtained updated consent from the End Buyer.
R.4.2 MIT Transactions are exempt from SCA. However, the Customer bears full liability for any chargeback on an MIT Transaction, including chargebacks arising from claims by the End Buyer that the Transaction exceeded the scope of the mandate or that the mandate had been cancelled.
R.5.1 For Unscheduled MIT Transactions, the Customer must be able to demonstrate that each Transaction was triggered by a specific event or condition described in the mandate. The Customer shall maintain records linking each Unscheduled MIT to the triggering event.
R.5.2 The Customer shall notify the End Buyer of each Unscheduled MIT charge either prior to the charge or, where prior notice is not operationally practicable, immediately following the charge. The notification shall state the amount, the reason, and a contact for the End Buyer to raise queries.
R.5.3 Certain industries — including accommodation, vehicle rental, and related sectors — may be subject to specific Scheme Rules governing Unscheduled MIT. The Customer shall comply with the applicable Scheme Rules for its industry. Dintero may provide guidance on applicable requirements upon written request.
R.6.1 The Customer shall provide End Buyers with a clear and accessible mechanism to cancel their mandate or Card-on-File arrangement at any time.
R.6.2 Upon receiving a cancellation request from an End Buyer, the Customer shall:
(a) cease initiating new MIT Transactions under the cancelled mandate immediately or, if a pending Transaction has already been submitted, without undue delay following settlement of that Transaction;
(b) confirm cancellation to the End Buyer in a durable format without undue delay; and
(c) update the Customer’s systems to prevent further Transactions under the cancelled mandate.
R.6.3 Initiating a Transaction after a mandate has been revoked constitutes a breach of the Agreement and will result in mandatory Refund at the Customer’s cost.
R.7.1 For Recurring Payments, the Customer shall notify the End Buyer before the first charge under the mandate and, where the charge frequency exceeds one month or where the amount changes, prior to the relevant charge.
R.7.2 Where a Recurring Payment amount increases from the amount specified in the mandate, the Customer must obtain fresh consent from the End Buyer before initiating the charge at the higher amount.
R.7.3 The Customer shall notify End Buyers of any change to the billing terms (amount, frequency, or duration) a reasonable time in advance — and in no event less than the notice period required under applicable consumer protection law.
R.8.1 Scope. This section applies to industries where the final transaction amount is not known at the time of the initial authorisation, including accommodation, vehicle rental, and similar service categories.
R.8.2 Where the final amount is not determinable at the time of check-in, rental commencement, or equivalent event, the Customer may submit a pre-authorisation for an estimated amount (the “pre-auth amount”). The pre-auth amount should represent a reasonable estimate of the final charge based on the services agreed with the End Buyer.
R.8.3 The Customer shall perform the final Capture at the actual transaction amount. The Capture amount may exceed the pre-auth amount only to the extent permitted by the applicable Scheme Rules for the relevant service category. The Customer shall not use pre-authorisation as a mechanism to reserve funds in excess of a reasonable estimate of the final charge.
R.8.4 Where the Capture amount will materially exceed the pre-auth amount, the Customer shall notify the End Buyer of the adjusted amount before performing Capture, and shall obtain the End Buyer’s acknowledgement where required by applicable Scheme Rules.
R.8.5 Pre-authorisations that are not captured within the period permitted by the applicable Scheme Rules will be automatically released. The Customer is responsible for monitoring pre-authorisation expiry and for ensuring timely Capture.
R.8.6 The Customer shall inform End Buyers at the time of the initial pre-authorisation that a hold will be placed on their available funds and that the final charge may differ from the pre-auth amount.
R.9.1 MIT Transactions may attract a higher service fee than standard CIT Transactions. The applicable fee for MIT processing is set out in the Customer’s pricing schedule. Pass-Through Fees, including scheme fees applicable to MIT Transactions, are payable by the Customer in addition to Dintero’s service fee.
R.10.1 The Customer bears full liability for all chargebacks on MIT Transactions. The Customer shall retain the following documentation for a minimum of five (5) years to support chargeback disputes:
(a) the End Buyer mandate, including the version accepted at the time of the initial CIT;
(b) confirmation of the initial CIT, including SCA authentication data and the transaction identifier;
(c) for each subsequent MIT: the transaction reference, the MIT indicator used, and the link to the original CIT;
(d) for Unscheduled MIT: records of the triggering event for each Transaction; and
(e) any cancellation requests received and the actions taken in response.
R.10.2 Where a chargeback is raised on the basis that a mandate was not obtained, had been revoked, or that the Transaction exceeded the scope of the mandate, the Customer bears full evidentiary responsibility and must provide the documentation in R.10.1 to Dintero within the timeframe specified in the applicable Supplementary Terms.
Applies to: Marketplaces (MP) and Operators (O)
This Schedule governs the Split Payout service and applies to any Customer for whom Split Payout has been activated. It forms part of the Agreement upon activation of Split Payout and is in addition to any role-specific obligations set out in the applicable Supplementary Terms.
SP.1.1 Split Payout is Dintero’s service by which a single payment received from an End Buyer is divided and distributed to one or more designated recipients and, where applicable, to the Customer itself, in accordance with the Customer’s payout instructions.
SP.1.2 This Schedule also governs the reimbursement fund distribution model used by Operators and Employers. In that model, funds originate from an Employer (rather than an End Buyer) and are distributed by Dintero to Reimbursement Recipients on the Operator’s instruction. References in this Schedule to “End Buyers” and “sales” apply by analogy to Employers and reimbursement fund transfers respectively, where the context requires.
SP.1.3 Split Payout is activated on request and subject to Dintero’s approval. Dintero may impose conditions on activation, including security requirements and minimum documentation.
SP.2.1 The Customer is solely responsible for providing accurate and complete payout instructions to Dintero for each Transaction or batch of Transactions. Dintero will execute payout instructions as provided and bears no liability for errors in payout instructions submitted by the Customer.
SP.2.2 Each payout instruction must identify each recipient by their Payout Destination registered with Dintero. The Customer may not instruct Dintero to pay to a Payout Destination that has not been approved by Dintero.
If the Customer submits an incorrect payout instruction, it shall notify Dintero immediately. Dintero will use reasonable efforts to reverse or correct the instruction where technically possible, but cannot guarantee recovery of funds already disbursed. The Customer bears full liability for any loss resulting from an erroneous instruction.
Each recipient’s funds are held separately. Dintero may not use funds belonging to one recipient to cover a negative balance caused by another recipient. The Customer may not instruct Dintero to do so.
Where chargebacks, refunds, or other reversals result in a negative balance for any recipient, the Customer is responsible for covering that negative balance. The Customer shall provide funds to cover the negative balance within forty-eight (48) hours of being notified by Dintero. If security held by Dintero is sufficient to cover the shortfall, Dintero may deduct the amount from that security. If the security is insufficient, the Customer shall top up the remaining shortfall within the same forty-eight (48) hour period.
Split Payout disbursements to each Seller are subject to the payout frequency configured for that Seller in the Backoffice at the time of onboarding or as subsequently updated. Where no Seller-specific frequency has been configured, the Customer’s standard settlement cycle applies. Dintero may withhold or delay a recipient’s payout where that recipient is subject to a security hold, a chargeback investigation, a compliance review, or a suspension.
Dintero shall provide the Customer with an overview of Transactions processed using Split Payout, accessible through the Backoffice.
The Customer shall not use Split Payout to:
(a) distribute funds to recipients who have not been approved by Dintero;
(b) process Transactions unrelated to actual sales of goods or services through the Customer’s platform; or
(c) make payments to the Customer’s own accounts in a manner that conceals the nature of the Transaction.
Fees for the Split Payout service — including the monthly platform fee, the per-Seller fee, and the variable payout fee — are set out in the Customer’s individual pricing schedule. The applicable fee level is determined at activation and may be amended in accordance with the fee change provisions in the applicable Supplementary Terms.
