Merchant Platform Agreement — EU/EEA

Merchant Platform Agreement

RT | BUSINESS PAYMENT ACCEPTANCE

Online edition v3.0 | Issued 20 October 2026 | Effective for each Merchant as stated in Section 1.1.

Parties and purpose

This Merchant Platform Agreement is between Percentagem Envolvente, Lda. ("RT", "Company", "we" or "us") and the business identified in the authenticated signup record ("Merchant" or "you"). The signup must identify both legal entities and the representative before acceptance. RT supplies software and related support for approved business payment acceptance. The Effective Date is determined by Section 1.1. Fees, selected Services and commercial parameters are agreed separately in a private Schedule A; a signup alone does not agree pricing or activate payment processing.

Contracting company

Percentagem Envolvente, Lda. is a Portuguese private limited company, NIPC 517102790, with registered office at Rua Arieiro, 12, 2460-821 Montes, Alcobaça, Portugal. It supplies the RT platform to approved EU and EEA businesses. RealTimePay, Inc. is a separate U.S. company and is not a party to this EU/EEA form. Notices to RT: legal@rt.app. Support: support@rt.app, +1 844-604-1604. Security incidents: security@rt.app. These contacts do not replace any mandatory notice to a payment provider or authority.

What forms the agreement

This online core, applicable version 3.0 Schedules B-K, the version register in Schedule Z, and each separately accepted private Schedule A form the Agreement. Q, R and S apply only to the selected products. The public Schedule A describes the order process and contains no Merchant-specific pricing. The accepted online edition is recorded at signup and is available to download. Separate provider and financial-product agreements remain required for their own services.

Activation and authority

Online acceptance creates the platform contract under Section 1.1; it does not approve underwriting, create a financial account, accept a provider agreement, authorize a bank debit or activate a product. Each relevant RT and provider approval, the private order, required disclosures and production configuration must be completed before processing. A support representative or administrator cannot waive those requirements or amend the Agreement without actual RT authority.

Business agreement

Merchant enters in the course of its business. This packet is not a personal cardholder agreement, deposit agreement, lending agreement, or consumer terms of sale. End-customer rights and mandatory law remain applicable. Existing contracts with Byte Products Inc., DFin AI, Inc. or another entity are changed only by a valid assignment, novation, or replacement agreement that identifies the affected contract and obligations; a brand change alone does not transfer them.

1 | Formation, documents and precedence

1.1 Online formation and Effective Date

RT offers this online edition only through an RT-authorized signup that displays this edition, the correct RT contracting company and the Merchant legal identity. The Agreement takes effect when an authorized Merchant representative affirmatively accepts it and RT successfully creates and confirms the Merchant platform account, with that acceptance recorded. If these events occur at different times, the later event is the Effective Date. A waitlist entry, application submission, website visit or uncompleted signup does not form this Agreement. No RT countersignature is required for this standard online route. If RT instead issues a document expressly requiring both parties to sign, that document takes effect only as its execution clause provides. Each party represents corporate capacity and authority; a representative does not give a personal guaranty merely by accepting for a company.

1.2 Incorporated documents

Schedules B-K apply to the relevant software Services from the Effective Date. Q, R and S apply only to their selected and approved products. Schedule A is a separate private commercial order and is not completed or accepted merely by signup. Its absence prevents paid or transactional Services that require that order, without preventing formation of this platform Agreement. Schedule Z identifies the incorporated edition. Historical Schedule L and special regulated industries require separate underwriting and appropriate terms; no such activity is approved here.

1.3 Priority

Mandatory law prevails. A provider agreement governs that provider’s service without enlarging RT’s authority. For RT and Merchant, mandatory transfer clauses prevail on their subject, then a specific amendment expressly accepted by authorized representatives of both parties; the applicable product schedule on its specific subject; Schedule G on data processing; this core; the accepted private Schedule A on pricing, territories and initial parameters; and the other schedules. A Schedule A exception to a protective core clause must identify that clause and the exact departure and carry express, attributable acceptance by an authorized RT representative. Mere system issuance, a prefilled field or a support conversation is not that approval. Neither an order nor a schedule silently substitutes a contracting entity.

1.4 Website and version control

The edition identified in the signup acceptance record and Schedule Z applies. Posting a new page alone does not amend an existing contract. Later changes require Section 16. The retained accepted edition prevails over a current page until a valid amendment takes effect. RT will provide a retained copy on request. Public summaries and marketing do not add contractual promises. Existing Byte/DFin or v2.0 signed agreements remain governed by their own parties, execution and amendment terms; adoption of this edition for an existing relationship requires an express, valid migration or replacement record.

1.5 Other RT services

General website terms govern general access where relevant. This accepted business Agreement controls its merchant-specific subject matter over general website terms. Personal or business issued cards, financial accounts, credit, custody and other regulated products require their own correct product and provider agreements. They are not included or activated by this merchant MSA. The provider-document directory is a reference route, not acceptance of every linked agreement.

2 | Services, providers and funds flows

2.1 RT software services

RT provides the software interfaces, integrations, reporting and support it has enabled for Merchant. RT may use affiliates and subcontractors while remaining responsible for its own contractual duties. Merchant receives a limited, non-exclusive, non-transferable right to use those Services for its approved business during the Term. RT retains ownership of its technology and may impose reasonable technical and security limits.

2.2 Regulated functions

Accounts, acquiring, payment processing, money movement, currency conversion, custody and settlement are performed by the applicable providers under their own authorizations and agreements. Merchant must accept required provider terms before use. RT is not appointed as a bank, acquirer, escrow holder, trustee or custodian by this Agreement. Whether a provider is licensed and which services it may supply must be assessed for the actual product and jurisdiction; no label here is a regulatory opinion.

2.3 Provider instructions

Within the permissions actually available in the approved program, Merchant authorizes RT to transmit transaction, refund, risk, reserve, reconciliation and payout instructions necessary to provide the selected Services, collect agreed fees, address exposures and comply with law or provider rules. RT may receive and use relevant account and transaction information for those purposes, as described in Schedule G. A provider may independently decline or override an instruction. RT does not promise the ability to freeze an external wallet, recover a completed transfer or direct every provider balance.

2.4 Specific flow prevails

The actual provider, charge model, asset, payout beneficiary and permissions must be identified in Schedule A or the accepted activation record. A card-funded NFT purchase, a Stripe card payment and a direct USDC payment are different flows. A successful blockchain entry does not establish that a card payment is irreversible. Schedule D and the applicable product schedule govern their respective operational steps.

2.5 Limited payment agency

Only where the approved flow and applicable law support it, Merchant appoints the specifically identified collection provider, and RT only to the extent it actually performs an approved collection function, as its limited collection agent for that sale. Receipt by that authorized recipient discharges the buyer's obligation for the amount received, subject to lawful refunds and reversals; Merchant must not collect it twice. This appointment does not declare an exemption from financial-services law or authorize a new funds flow. RT may disable or restructure a flow if its legal basis or provider support is uncertain.

3 | Underwriting, territories and changes

3.1 Continuous approval

Access is conditional on RT's and each provider's continuing acceptance of Merchant, its beneficial owners, activities, locations, products, websites, delivery model and financial condition. RT may decline an application or impose conditions in its risk judgment, exercised honestly and consistently with law. An RT approval is not a regulator's or provider's approval.

3.2 Information and verification

Merchant warrants that information supplied in its application and updates is accurate, complete and current. Merchant authorizes lawful verification and sharing with relevant providers, advisers and authorities for underwriting, fraud, compliance, dispute and enforcement purposes. Merchant must supply reasonably requested ownership, licensing, business, financial, fulfillment and transaction evidence within five Business Days, or a shorter justified deadline for an urgent risk, provider deadline or legal requirement. RT may suspend affected activity pending a sufficient response.

3.3 Geographic and product restrictions

Merchant may transact only within its approved establishment and customer territories and under applicable provider restrictions. Approval is specific to the Merchant legal entity and program. It does not extend to an affiliate, third-party seller, undisclosed website, new product line, restricted sector, recurring billing or a new provider. Merchant must implement lawful location, age and eligibility checks appropriate to its approved sales and must not conceal or alter the true activity, beneficiary, location, descriptor or merchant category.

3.4 Material changes

Merchant must obtain prior written approval before a change in control, legal entity, payout beneficiary, core business, sales channel, regulated product, fulfillment model or supported territory. Where practicable it must give at least 30 days' advance notice. Unexpected insolvency, license loss, enforcement action, material fraud or security incident must be reported without undue delay; incidents follow Section 10. RT may re-underwrite and change risk controls before or after the change.

3.5 Monitoring and audits

Merchant will permit proportionate audits of records and systems relevant to the Services on reasonable notice, with expedited access for serious incidents or legal/provider deadlines. Access must preserve other customers' confidentiality and security. RT may require an independent assessment and reasonable remedial measures. Merchant bears its own response costs and documented reasonable external costs attributable to its breach or material risk event. An audit, provider review or failure to detect an issue does not relieve Merchant of its duties.

4 | Merchant sales and fulfillment

4.1 Merchant is the seller

Merchant is responsible for the legality, safety, quality, rights, descriptions, pricing, taxes, delivery, warranties, refunds and customer support for its offerings. Unless a separately accepted provider model expressly establishes another seller of record, Merchant must identify itself clearly as the seller. RT's involvement in software or payment routing does not make RT the supplier, manufacturer or guarantor of Merchant's goods or services.

4.2 Buyer disclosures

Before payment Merchant must clearly disclose its legal or recognizable trading name, support details, material product characteristics, total price and mandatory charges, delivery timing, cancellation and refund terms, subscription terms if approved, and any NFT or digital-asset component. It must obtain the buyer authorizations required by law and the payment method. It must not hide an NFT purchase, misdescribe a prohibited item as software or a token, or use labels such as "research only" to conceal actual intended or marketed use.

4.3 Delivery and evidence

Merchant must deliver as promised and maintain records that connect payment, order, customer consent, delivery and any redemption. A token mint, wallet transfer or redemption record alone does not prove delivery of an off-chain product or defeat a chargeback. Merchant must not take payments for goods it cannot lawfully and reasonably expect to supply. Material delays, cancellations or inability to fulfill must be disclosed to RT promptly and addressed with buyers through lawful remedies.

4.4 No laundering or third-party processing

Merchant must submit only genuine sales of its approved business. Factitious transactions, self-funding, card testing, cash-equivalent conversion, transaction laundering, processing for an undisclosed seller, duplicate collection and masking descriptors are prohibited. Marketplaces, facilitators, sub-merchants, donations, prior-debt collections and cash advances require a separate expressly authorized model where lawful; this packet alone does not permit them.

4.5 Consumer obligations remain

Merchant's policies cannot override mandatory buyer rights, network dispute rights or required refunds. RT may require Merchant to correct misleading disclosures, cease a listing, notify affected buyers or fund a lawful refund where needed to protect the program. Merchant must not claim that RT or a provider has approved product safety, legal status, investment value or medical efficacy. Merchant must not direct product complaints to RT as though RT were the seller, while cooperating with payment and platform inquiries.

5 | Payment-method and network obligations

5.1 Applicable rules

Merchant must comply with the current rules and provider instructions applicable to each enabled method. Schedule E addresses payment acceptance and Schedule F addresses operations. RT may pass through a provider's restrictions and require changes needed for compliance. Network thresholds, retry limits and authentication requirements vary and are not fixed by a generic number in this Agreement.

5.2 Authorization and capture

Merchant must obtain valid authorization and submit accurate transaction data through the approved integration. Authorization, authentication, risk scoring, a receipt or an apparent available balance does not guarantee settlement or eliminate a dispute. Merchant must respect declines and provider retry rules, use idempotency and status checks for uncertain transactions, and avoid splitting or rerouting transactions to evade restrictions.

5.3 Card data and recurring payments

Use provider-hosted payment capture or another expressly approved compliant integration. Merchant must not send full card credentials through email, support chat, logs or ordinary RT forms, and must never retain prohibited sensitive authentication data after authorization. Merchant must maintain the PCI validation appropriate to its actual scope. Mail/telephone orders, recurring charges, installments, delayed capture and card-present use require specific approval and applicable consent, cancellation and authentication controls.

5.4 Charges and disclosures

Merchant may impose a surcharge, convenience fee or similar buyer charge only after RT's written approval and where the relevant law and method rules allow it. Merchant must comply with eligibility, registration, cap, display, receipt and notice requirements. Approval of a commercial fee to RT does not approve a buyer-facing surcharge. Merchant must honor applicable restrictions on debit and prepaid surcharges.

5.5 Bank and digital-asset payments

ACH, SEPA and other bank debits require valid mandates and scheme-compliant retention, notifications and returns handling. Direct digital-asset acceptance is limited to approved assets, networks and flows. Finality depends on that network and provider's confirmation requirements. Merchant must not treat a token event as proof of final fiat payment, or assume a completed digital-asset transaction can be recalled. Required refunds and return obligations remain.

5.6 Provider agreements

Merchant is responsible for its direct provider obligations. RT's assumption of a commercial loss under its provider agreement does not release Merchant from reimbursement properly due here, and this Agreement does not expand rights against Stripe or another provider. Product schedules distinguish those relationships.

6 | Fees, taxes and account records

6.1 Payment obligation

Merchant must pay the fees agreed in Schedule A and documented provider/network charges, refunds, reversals, chargebacks, assessments and reasonable recoverable costs attributable to Merchant under this Agreement. Amounts are payable when deducted in an authorized settlement flow or, if invoiced, within ten Business Days unless an urgent provider obligation or Schedule A specifies an earlier lawful deadline. RT must identify the basis of an amount and avoid duplicate recovery.

6.2 Billing records and objections

RT will make reasonably available transaction, deduction and settlement records through the supported interface or on request. Merchant must reconcile its records and report apparent errors promptly, ordinarily within 30 days after the statement is made available. This administrative period does not shorten mandatory rights or excuse fraud, concealed errors or amounts that were not lawfully chargeable. Merchant must pay undisputed amounts while a good-faith dispute is reviewed. RT's books are evidence, not an irrevocable determination of a contested legal debt.

6.3 Pass-through amounts

Assessments, dispute fees, investigation charges or other provider costs may be recovered only where attributable to Merchant and actually incurred, contractually payable or reasonably secured for an identified exposure. RT may protect itself against a contingent exposure through a reserve without recording it as a final earned fee. RT may provide a redacted provider statement or meaningful calculation where confidentiality prevents disclosure of the original.

6.4 Late payment

Overdue undisputed sums bear simple interest at the lower of 1% per month and the maximum lawful rate, calculated without compounding. Merchant reimburses reasonable documented collection and enforcement costs recoverable under this Agreement and law. No provision imposes punitive interest or authorizes payment to an unverified destination. A court or arbitrator may resolve a genuine dispute over the amount.

6.5 Taxes and recordkeeping

Merchant is responsible for taxes on its sales and applicable reporting, invoicing and licensing, except taxes on RT's net income. RT may collect or withhold taxes where legally required and will account for them. Merchant must retain accurate transaction, consent, fulfillment and dispute evidence for applicable legal and network periods; ordinary commercial records should be retained for seven years where lawful and necessary. Personal data and payment credentials remain subject to minimization and retention limits, rather than an indiscriminate seven-year rule.

7 | Settlement, refunds and disputes

7.1 Conditional payout timing

Payouts follow Schedule A and the approved provider flow, subject to clearing, cut-offs, weekends, holidays, provider availability, verification and Sections 8-9. An estimated settlement date or dashboard figure is not a promise of an immediately withdrawable balance. RT is responsible for instructions it undertakes to transmit with reasonable care; it does not guarantee an independent provider's performance or insurance treatment.

7.2 Refunds

Merchant must honor required refunds and its disclosed lawful refund policy, maintain adequate funds and submit requests promptly through the approved process. Refunds should return through the original method and to the original payer where method rules require it. An alternative requires provider approval and applicable identity, sanctions and fraud controls. Merchant must not pay an unverified third party or issue a duplicate refund during a dispute. A refunded NFT entitlement must be invalidated where supported and lawful.

7.3 Chargebacks and returns

Merchant bears amounts and associated fees properly attributable to its transactions, including after payout, refund, token mint, withdrawal, suspension or termination. A provider's decision may bind the payment process under its rules, while any separate contractual claim remains subject to Section 15. RT need not advance its own money, absorb Merchant losses or guarantee a representment result.

7.4 Evidence and escalation

Merchant must monitor its designated dispute channels and provide complete factual evidence by RT's notified cut-off, which may reasonably precede the provider deadline. Merchant should ordinarily respond within two Business Days, or sooner where an actual deadline requires. RT may decline unsupported or economically unreasonable escalation and may require a deposit for expected external fees before arbitration or a further provider dispute stage. It will not fabricate evidence or knowingly submit false information.

7.5 Reconciliation and shortfalls

A provisional credit does not discharge Merchant until finally received and no longer reversible under the applicable rules. If eligible proceeds are insufficient, Merchant must fund a documented shortfall within two Business Days of demand, subject to any shorter lawful provider deadline. Successful recovery is credited against the debt, and subsequent reversals, refunds of assessments and duplicate payments must be reconciled. Currency conversions used for recovery must use a commercially reasonable disclosed basis.

8 | Holds, reserves and suspension of payouts

8.1 Risk triggers

RT may take protective action when it reasonably identifies actual or likely exposure arising from fraud, disputes or returns; delayed or unfulfilled sales; misleading or prohibited activity; material volume or business changes; negative balances; deficient verification or financial condition; insolvency risk; a security incident; conflicting ownership claims; threatened claims attributable to Merchant; or a legal, network or provider requirement. RT need not wait for a loss or final judgment where preventive action is reasonably necessary.

8.2 Available measures

To the extent legally permitted and supported by the approved provider permissions, RT may decline or cap transactions, suspend a feature, pause or delay payouts, establish a fixed, rolling or capped reserve, increase its amount, require prefunding or additional security, and instruct a provider to implement corresponding measures. A reserve may include up to 100% of affected eligible proceeds when justified by the exposure. RT may act immediately where advance warning would worsen risk, defeat a lawful restriction or breach a provider instruction.

8.3 Calculation and notice

RT determines a reserve using relevant unsettled and historical volume, dispute/return windows, fulfillment liabilities, likely refunds and assessments, financial information and provider requirements. As soon as reasonably practicable, RT will notify Merchant of the action, amount or calculation, general reason and review/release conditions, except where prohibited or where disclosure would prejudice a lawful investigation. RT may withhold security-sensitive details and protected suspicious-activity information.

8.4 Reviews and release

RT will review an active hold or reserve at least every 30 days and reduce or release the portion no longer reasonably needed, subject to provider control and law. There is no automatic right to release at 180 days if a documented claim, unexpired exposure period, continuing investigation or binding restriction remains. RT must identify the continuing basis where disclosure is lawful and must not retain funds indefinitely merely because Merchant terminated or requested payment.

8.5 Ownership and limits

Held amounts are not forfeited to RT merely by a restriction. They remain subject to their actual legal ownership and may be applied only to a properly due obligation or lawful disposition. RT cannot promise a segregated account, perfected lien, deposit insurance, trust status or control over an external self-custody wallet unless the real arrangement supports it. Merchant may submit corrective evidence and request review at legal@rt.app; review does not automatically suspend protective action.

9 | Recovery, setoff and security

9.1 Recovery authority

Merchant authorizes RT, within the approved program and applicable law, to net or set off matured amounts Merchant owes under this Agreement against Merchant's eligible settlement entitlements, reserves or other amounts payable by RT in connection with the Services. RT may instruct an authorized provider to make a permitted deduction. An unquantified contingent exposure is secured through a reserve until it becomes payable. No right extends to another customer's property or assets outside a lawful mandate.

9.2 Statements and disputes

RT will provide a prompt statement of the date, amount and category of each applied recovery and credit any excess or later recovered duplicate. Where a substantial contractual claim is disputed and no urgent requirement applies, RT will give a reasonable opportunity to supply contrary evidence before final application, without waiving its right to secure the exposure. Merchant must not obstruct lawful recovery but retains non-waivable defenses and access to Section 15.

9.3 Security grant

To secure Merchant's obligations under this Agreement, Merchant grants RT a continuing security interest in Merchant's rights to receive settlement under the Services, Merchant-owned reserves established for those Services, and identifiable proceeds, to the extent assignable under law and provider terms. It excludes end-customer or other third-party property and assets not described here. Merchant authorizes accurate financing statements and reasonable further assurances, at Merchant's reasonable cost, where applicable. Attachment, perfection, priority and enforcement depend on the steps and law actually applicable; this text does not certify a perfected first-priority lien.

9.4 Competing interests and enforcement

Merchant must disclose material competing claims affecting that collateral and must not knowingly impair RT's lawful security without consent. RT may require additional arrangements or suspend exposure if adequate protection cannot be established. Enforcement must comply with mandatory notice, priority, insolvency, stay and commercially reasonable disposition rules. A service termination alone is not a default allowing confiscation of assets. RT will release its security after secured obligations and properly retained exposures are discharged.

9.5 Guarantees and mandates

No director, employee, shareholder, corporate signatory or customer gives a personal guaranty merely by using or accepting this Agreement. RT may condition a particular approval on a separate, expressly signed guaranty or security document that identifies the guarantor, obligations and applicable law. A bank debit or cross-entity setoff likewise requires a valid specific legal basis; no blanket affiliate seizure is created here.

10 | Security, credentials and integrations

10.1 Merchant security

Merchant must use unique authorized-user accounts, protect credentials, apply least privilege and multifactor authentication where offered, remove access promptly when roles change, and prevent unauthorized access by staff, affiliates or third parties. It must maintain proportionate safeguards for its systems, data and integrations, keep supported software current, validate signed webhooks, protect secrets server-side and implement idempotency and reconciliation. It must not bypass risk controls or request privileged actions through an unverified support message.

10.2 Incident notice

Merchant must notify security@rt.app without undue delay and in any event within 24 hours after becoming aware of an actual or reasonably suspected compromise affecting the Services, account, credentials, transaction integrity or relevant personal/payment data. Merchant must contain the incident, preserve evidence, revoke compromised access and cooperate with proportionate investigation and required provider forensics. It should provide known facts promptly and supplement them; it must not wait for a completed investigation.

10.3 RT obligations

RT will maintain safeguards appropriate to its processing and notify Merchant without undue delay after becoming aware of a personal-data breach affecting data it processes for Merchant, with an initial notice where feasible within 24 hours and timely supplements. Schedule G governs data roles and assistance. These obligations do not assert that RT has a particular audit certification, backup frequency, recovery objective or uptime SLA. A specific certification or service commitment applies only if RT supplies current evidence or expressly signs that commitment.

10.4 Authorized agents and automation

An agent or integration may act only within actual customer authorization and enabled technical permissions. Merchant must validate the identity, scope, amount, expiry, revocation and final state of each request, prevent duplicate payment and require human approval where configured or legally required. An AI-generated instruction is not evidence of the payer's legal consent by itself. Schedule S applies only if that product is selected and enabled.

10.5 Protective access controls

RT may revoke credentials, stop unsafe calls, require patches or reauthentication, restrict data access or temporarily disable integrations when reasonably needed for security, compliance or program integrity. RT may set an urgent remediation deadline based on severity. Merchant is responsible for its personnel and vendors within its control; allocation of loss remains subject to causation, provider rules, this Agreement and mandatory law.

11 | Data, intellectual property and confidentiality

11.1 Data roles

Each party is responsible for processing for which it determines the purposes and means, including its own legal, risk and business administration. Where RT processes personal data solely on Merchant's documented instructions, Schedule G applies as the data processing agreement. A payment provider may be an independent controller under its own terms. The public privacy notice is a notice to individuals; it does not alone replace the parties' contractual processing obligations or create marketing consent.

11.2 Merchant instructions and content

Merchant warrants lawful collection, notices, consents where required, authority to provide data and content, and the accuracy of instructions. Merchant must minimize data and avoid sensitive data unless expressly approved with appropriate terms. It must not add names, contact details, government-ID, health, card or authentication data to public-chain metadata. Public wallet addresses and transaction references inherently required by an approved on-chain flow require a lawful basis, minimization and clear disclosures. Hashes and wallet addresses may still identify a person. RT may reject unsafe fields and require off-chain handling.

11.3 Ownership and license

Each party retains its pre-existing technology, data, marks and content. Merchant grants RT and its permitted providers a non-exclusive license to use Merchant content, identifiers and marks as necessary to provide, secure, support and document the Services and the resulting transaction records. A token transfer does not itself transfer copyright. RT may use voluntary feedback without restriction but may not thereby acquire Merchant confidential information or personal data rights. Public customer-logo use requires Merchant's separate consent.

11.4 Confidentiality

Each party must protect the other's non-public business, technical and security information with reasonable care, use it only for this relationship and disclose it only to personnel, providers, advisers or authorities with a proper need and appropriate safeguards. Exclusions cover information independently developed, lawfully known or received without restriction, or public without breach. Compelled disclosures must be limited as legally appropriate, with notice where lawful. Confidentiality does not prohibit protected reports, truthful evidence, complaints or communications with regulators or advisers.

11.5 Retention and exit

Merchant should export its commercial records regularly. On termination it may request an available export for 30 days unless a shorter legal or security restriction applies. RT may retain records needed for disputes, fraud, compliance, legal holds and required periods, under continuing safeguards; otherwise it will delete or return processor data as Schedule G requires. Public-chain data may persist beyond either party's technical control. Direct personal identifiers must remain off-chain; necessary public transaction references require the safeguards in Section 11.2.

12 | Compliance, warranties and indemnity

12.1 Merchant assurances

Merchant represents and covenants that its approved activity and each submitted transaction are lawful and genuine; it owns or has rights to its content and products; it holds required permissions; its statements are not misleading; and it complies with applicable sanctions, anti-fraud, consumer, product, tax, data, network and sector rules. It must not use RT to evade a restriction. Required legal obligations apply to the party and activity actually subject to them; this Agreement does not declare every merchant a regulated financial institution.

12.2 RT assurances

RT represents that it has corporate authority to enter this Agreement and will perform its own agreed software duties with reasonable care and comply with laws applicable to its role. Neither party represents that a contract label determines a regulator's classification. RT may suspend a legally uncertain or prohibited flow and cooperate on a compliant alternative without promising a license, regulatory approval or uninterrupted replacement.

12.3 Merchant indemnity

Merchant will defend and indemnify RT, its affiliates and their officers, directors, employees and authorized representatives against third-party claims and reasonable documented losses, costs and recoverable assessments to the extent arising from Merchant's products, fulfillment or customer promises; unlawful or infringing content; fraud or misconduct; breach of this Agreement; unlawful data instructions or a security failure within Merchant's responsibility; or provider/network liabilities attributable to Merchant's activity. Merchant must also reimburse its properly payable refunds, returns, chargebacks and negative balances as a direct contractual obligation.

12.4 Boundaries

Merchant does not indemnify losses to the extent caused by the indemnitee's fraud, willful misconduct, gross negligence or independent breach of its own legal obligations. Indemnification of fines or penalties applies only where lawful. A regulator's requirement that RT obtain a license for RT's independent activity is not shifted to Merchant merely by this clause. No double recovery is permitted, and settlement of a claim must respect the defense procedures below.

12.5 Defense procedure

The indemnitee must give reasonably prompt notice, with any delay reducing the obligation only to the extent of actual prejudice, provide reasonable cooperation and permit a competent defense. RT may control a matter involving its regulatory status, significant conflict or failure of Merchant to defend, with reasonable recoverable costs attributable to the indemnified claim. Neither party may settle for an admission, non-monetary burden or unreimbursed payment by the other without its written consent, not unreasonably withheld. RT may secure a reasonably evidenced exposure under Section 8 while the claim is resolved.

13 | Disclaimers, liability and individual protection

13.1 Service and provider risks

EXCEPT FOR EXPRESS DUTIES IN THIS AGREEMENT, THE SERVICES ARE PROVIDED AS AVAILABLE. TO THE EXTENT LAWFUL, RT DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR PURPOSE AND NON-INFRINGEMENT. RT DOES NOT GUARANTEE SALES, APPROVALS, UNINTERRUPTED ACCESS, FRAUD DETECTION, A DISPUTE OUTCOME, SETTLEMENT SPEED OR DIGITAL-ASSET VALUE. Independent networks and providers may delay, fail, restrict or discontinue services. This disclaimer does not erase an express RT duty or liability that law does not permit to be excluded.

13.2 Excluded damages and cap

TO THE MAXIMUM EXTENT PERMITTED BY LAW, RT IS NOT LIABLE FOR INDIRECT, CONSEQUENTIAL, SPECIAL, EXEMPLARY OR PUNITIVE LOSS, OR LOST PROFITS, GOODWILL OR OPPORTUNITIES. RT'S AGGREGATE LIABILITY ARISING FROM THIS AGREEMENT AND THE SERVICES IS LIMITED TO THE PLATFORM FEES ACTUALLY PAID TO RT BY MERCHANT DURING THE TWELVE MONTHS BEFORE THE FIRST EVENT GIVING RISE TO THE CLAIM. Provider charges, taxes, transaction principal and reserves are not RT platform fees. Related claims are aggregated; multiple claims do not multiply the cap.

13.3 Mandatory exceptions

The foregoing cap and exclusions do not apply to fraud, willful misconduct, gross negligence, death or personal injury where exclusion is unlawful, or any other liability that cannot lawfully be limited. They do not permit RT to retain Merchant funds to which RT has no lawful entitlement or eliminate mandatory data-subject, payment or consumer rights. Merchant's properly payable transaction debts and indemnities are not capped by the amount of platform fees.

13.4 Company and founder separation

Merchant's contractual recourse is against its RT contracting entity. RT's shareholders, directors, officers and employees do not assume personal contractual liability merely by serving in those roles, administering the platform or signing in a representative capacity. Each is an intended beneficiary of this protection and the applicable defenses. Nothing shields an individual from liability imposed by mandatory law for that individual's own actionable conduct, or prevents a lawful court determination concerning fraud or corporate separateness.

13.5 Risk allocation

The parties acknowledge that the price and service scope reflect this allocation. Each must take reasonable steps to mitigate loss and preserve evidence. RT gives no legal, investment, medical, tax or accounting advice and no assurance that a product or token has a particular legal status. Merchant must obtain advice appropriate to its business. An adverse outcome does not by itself establish breach by either party.

14 | Term, suspension and termination

14.1 Term and ordinary exit

This Agreement begins on the Effective Date and continues until terminated. Either party may terminate on 30 days' written notice unless a clearly disclosed Schedule A minimum commitment applies. Expiry of a commitment does not automatically renew a new minimum commitment without a disclosed agreement. Accrued liabilities, legitimate reserves and valid claims are not discharged by notice or closure.

14.2 Immediate action

RT may immediately restrict, suspend or terminate affected Services where Merchant materially breaches this Agreement, verification fails, a prohibited activity or material security/risk event occurs, a required license or provider relationship is lost, a legal/provider direction requires it, or continued service would create unacceptable documented financial or compliance exposure. RT may also act on credible evidence of fraud or likely serious loss without waiting for a final finding. Insolvency remedies remain subject to applicable insolvency law and stays.

14.3 Notice and cure

Where lawful and practicable RT will provide the general reason and reasonable remediation instructions. For a remediable non-urgent material breach, a party ordinarily has 15 days after written notice to cure. No cure period requires RT or a provider to continue an unlawful flow, extend credit, increase an exposure or compromise an investigation. Restoration depends on verified remediation and provider permission; RT may require revised controls or security.

14.4 Wind-down

Merchant must stop new transactions when instructed, remove payment branding and credentials as required, fulfill or lawfully refund existing orders, cooperate with outstanding disputes, pay amounts due and arrange lawful data/content migration. RT may maintain a limited interface or provide records where feasible without restoring processing. RT will arrange release of available eligible funds through the provider, less properly recoverable obligations and justified reserves, subject to law and provider restrictions.

14.5 Continuing protection

Fees and payment/recovery obligations, reserves and security to the extent needed for existing exposures, confidentiality, data duties, IP ownership, indemnity for relevant pre-termination matters, liability limits, disputes and necessary definitions survive for their applicable legal periods. RT will not use survival to create new post-termination transactions or an indefinite reserve without a continuing basis. Retention, deletion, abandoned property and asset disposition must follow applicable law.

15 | Notices, complaints and disputes

15.1 Notice channels

Legal notices to RT must be sent to legal@rt.app; Merchant’s address is its authenticated signup notice address, as updated by an accepted Schedule A or later authenticated update. RT may send notices by email or a dashboard notice accompanied by email. A notice is effective on confirmed receipt or the next Business Day after successful electronic transmission without a failure message, subject to mandatory law. Merchant must maintain a working notice channel. Service of judicial process must follow applicable procedural law.

15.2 Review and escalation

Operational complaints go to support@rt.app and contractual or funds-hold review requests to legal@rt.app, identifying the Merchant, transaction or reserve reference and disputed issue. RT will acknowledge a complaint within two Business Days and aim to provide a substantive response within 15 Business Days, with an update if investigation or provider information is still required. Mandatory complaint deadlines prevail. A complaint does not automatically halt a justified risk measure or excuse undisputed payment.

15.3 Governing law and forum

Portuguese law governs the parties' contractual relationship. The competent courts of Lisbon, Portugal have jurisdiction over disputes between the parties, subject to mandatory jurisdictional and procedural rules. The choice does not displace mandatory protections under applicable EU or national law. Mandatory rules applicable to the Merchant and affected individuals remain enforceable. The parties exclude the UN Convention on Contracts for the International Sale of Goods to the extent it might otherwise apply.

15.4 Informal resolution

Before ordinary proceedings, the parties will attempt in good faith to resolve a written contractual dispute for 30 days. This does not bar urgent protective relief, a mandatory complaint, a regulatory report, an approaching limitation deadline, lawful collections needed to preserve rights, or proceedings necessary to recognize or enforce a judgment. Either party may seek relief the law allows; a contractual reserve right is not a waiver of access to a competent tribunal.

15.5 Procedure and costs

Costs and legal fees are recoverable only as Portuguese procedural law and the competent court allow. No U.S. jury waiver, U.S. arbitration protocol or contractual waiver of mandatory EU/EEA rights applies to this form. The parties may later agree a separate arbitration process for a specific dispute. Neither this Agreement nor an incorporation link silently appoints an arbitrator, waives a non-waivable remedy or changes a provider's independent dispute procedure. Network/payment disputes remain subject to their applicable operational rules.

16 | Changes and general provisions

16.1 Prospective changes

RT may prospectively update this core, incorporated schedules and operating rules by giving at least 30 days’ advance notice of a material increase in fees or obligations, identifying the changed document, effective date and retained edition. Private order pricing changes also require the authority and procedure in that order and this Agreement. A shorter period applies only to the extent necessary for law, a binding provider/network requirement or an urgent security or fraud concern, with notice as soon as lawful and practicable. No change retroactively rewrites an accrued claim or completed transaction. Merchant may terminate an affected Service before a material change takes effect; existing debts and justified exposures remain.

16.2 Consent and controlled records

Continued use after a properly notified effective date constitutes business acceptance only where the Agreement and applicable law permit it; RT must obtain affirmative acceptance where required. RT retains the old edition and evidence of the notice and acceptance mechanism. A change of contracting entity, personal guaranty, materially different regulated flow or other change requiring express agreement needs a specific instrument and legally required consent. Schedule G and mandatory transfer instruments control their own changes. Publication, silence, a support message or a new account screen cannot bypass these requirements.

16.3 Assignment and independence

Merchant may not assign this Agreement without RT's written consent. RT may assign it to an affiliate or successor in a bona fide reorganization or business transfer on notice if lawful and without reducing mandatory rights; any required provider or Merchant consent must still be obtained. No assignment by itself moves funds or transfers a separate provider account. The parties are independent contractors except for a specific limited agency lawfully established under Section 2.

16.4 General mechanics

This Agreement is the entire agreement for the selected merchant software Services. Except for valid Section 16 updates, an amendment must expressly identify its terms and be accepted in a written or authenticated electronic record by authorized representatives of both parties. Electronic acceptance is permitted unless the instrument or mandatory law requires signatures or another formality. A delay in enforcement is not a waiver. Invalid provisions are severed only to the lawful extent. Events beyond reasonable control excuse affected performance only while reasonably unavoidable; mitigation, accrued payment and legal safeguards continue. Headings aid navigation and do not enlarge rights.

16.5 Protected communications and beneficiaries

Nothing prohibits truthful reviews, protected whistleblowing, legal advice, law-enforcement cooperation or a lawful regulatory complaint. RT may restrict false or deceptive representations, threats, misuse of its marks and disclosure of protected third-party information under applicable law. End customers do not become contractual beneficiaries merely by using Merchant's checkout. RT personnel protected by Section 13 and relevant providers may enforce protections expressly granted to them, subject to all applicable limitations and defenses.

16.6 Interpretation

"Business Day" means a weekday other than a public holiday at the relevant processing location, subject to the provider calendar stated in Schedule A. "Including" is illustrative. Rights are cumulative only to the extent consistent with law and no double recovery. A typo does not create a new power or allow RT alone to rewrite a material disputed term; the parties must interpret the documents reasonably and correct an actual error in writing.

Product activation | Separate acceptance requirements

Merchant services

The platform contract, private commercial order, provider agreement and production approval are distinct records. Before use, RT must identify the selected product, country, RT entity, actual provider and program, account type, funds flow and permissions. No service is approved by an empty field or public listing. A new product can require additional verification and an amended order.

Connected-account processing

Custom Connect may use an RT-branded interface. The applicable Stripe agreement, Stripe privacy notice and required acquirer disclosure must nevertheless be presented for the actual account country and full-service or recipient-only model. Capture the required express acceptance before accepting or receiving payments. Schedule Q applies only to the enabled processing model.

NFT, USDC and bank-transfer checkout

Identify the actual checkout provider, collection recipient, token function, issuer, asset/network, beneficiary and applicable customer agreements. Apply Schedules D, E, J and R where relevant. A bank debit needs its separate mandate. A merchant contract does not authorize an unsupported on-ramp, custody model, country or underlying industry.

Issued cards and financial accounts

These services fall outside this merchant MSA. Obtain the correct consumer or business cardholder, authorized-user, account, custody, electronic-communications and fee documents for the actual approved program. A corporate-card form does not enroll a personal cardholder. A supplier contract does not itself open an end-user account or give that user the supplier’s private commercial terms.

Document availability

The reference directory is https://rt.app/legal/payment-services/. Only documents actually presented and validly accepted for the applicable product govern that product. If a required final program agreement, provider permission, completed data-processing information or lawful transfer mechanism is unavailable, the affected activation or processing must wait. Required legal identities and disclosures cannot be hidden as confidential implementation detail.

Schedule Z | Incorporated document register

Z.1 Edition accepted online

This core and the following public schedules are online edition v3.0, issued 20 October 2026. The Effective Date for each Merchant follows Section 1.1. RT retains the accepted core and schedule snapshot until validly amended. A completed private Schedule A carries its own order ID, version and acceptance record and incorporates the specified MSA edition. Q, R and S apply only to selected products and approved activation.

• A — Commercial Order Form
• B — Definitions and Interpretation
• C — Operational Security and Controls
• D — Provider Roles, Funds Flows and Risk Controls
• E — Payment Acceptance and Network Requirements
• F — Operating Rules and Processing Procedures
• G — Data Processing and Privacy Requirements
• H — Acceptable Use and Restricted Businesses
• I — Merchant Platform Use Terms
• J — Digital-Asset Risk Disclosures
• K — Service Transparency, Support and Complaints
• Q — Connected-account payment processing
• R — NFT Checkout Product Terms
• S — Merchant APIs and Authorized-Agent Acceptance
• Z — Version Control and Incorporation

Z.2 Durable copy

The public schedule snapshot is available at https://rt.app/legal/merchants/archive/2026-10-20/RT-Merchant-Schedules-v3.0.pdf. Its SHA-256 digest is 5ccbc6e3dc8246dfb7b82810dadb539d5f7f5d8e5878e797b8a52af9d39f6070. The core files and version manifest are available in the same archive. A digest identifies those bytes, not a legal opinion or later replacement. RT retains the signup record, accepted core and schedules, each separately accepted order, required provider acceptances and later valid changes.

Z.3 Exclusions

Historical Byte/DFin schedule letters and definitions are not imported by matching letters. Schedule L (eGaming / sweepstakes) and any unidentified "Schedule Z" from earlier forms are not incorporated. The new Schedule Z is this version register. A special-industry contract, guaranty, debit mandate, issued-card agreement or provider enrollment must be separately documented where required.

Schedule Z | Online acceptance and records

Z.4 Merchant online acknowledgment

The Merchant representative must have authority to bind the identified business, be able to access and retain the linked edition and take an affirmative acceptance action. The signup must clearly state that accepting creates this business contract, identify the RT entity, and link the core and schedule snapshot before that action. Merchant accepts the applicable reserve and hold rights in Section 8, recovery and security in Section 9, indemnity in Section 12, liability allocation in Section 13 and dispute provisions in Section 15, subject to mandatory law. Acceptance is not a statement that an uncompleted private order or unpresented provider agreement has been accepted.

Z.5 RT assent and alternative signed route

For the standard online route, RT’s issuance of the signup offer and successful account confirmation establish RT’s assent under Section 1.1 without a countersignature. A private order is accepted separately under its own stated mechanism. A signed-document route retains its express signature conditions. A DocuSign profile, sender mailbox, template upload or internal administrator identity is not evidence of signing authority. No signature is applied by this document.

Z.6 Record retention

RT must retain the accepted document bytes, version and hash; Merchant and RT legal identities; representative name, title and authority declaration; authenticated user/account reference; acceptance and account-confirmation timestamps with time zone; IP address and user agent where lawfully collected; the displayed consent and button wording and interface version; and the durable acceptance receipt. Retain separate order, provider, underwriting, activation and later notice records. For signed documents also retain the envelope ID and completion certificate. An unchecked or missing acceptance, failed signup or a payment capability flag alone is not a contract-acceptance record.