1. Operator, scope and agreement status
CryptiumPay is the product name. The contracting operator, registered address, company number and jurisdiction have not yet been confirmed. In this draft, references to we, us or the operator mean the operator to be identified in the final agreement. Publishing or viewing this draft does not make it an accepted merchant agreement. An effective version must identify the contracting party, its effective date and the process by which the merchant accepts it.
2. Eligibility and authority
The proposed service is intended for merchants conducting lawful business. An individual using the service should have full legal capacity and be at least 18, or the higher age required by applicable law. A person acting for a business must have authority to do so. Business information must be accurate and kept current. Merchant activation remains subject to the operator's eligibility, verification and risk requirements, which must be confirmed before live onboarding.
3. Accounts, credentials and team access
Keep account credentials, API keys and recovery information confidential, use available security controls and grant only the access each authorised person needs. You are responsible for managing your authorised users and integrations. Notify support promptly if you suspect unauthorised access, revoke compromised credentials where possible and cooperate in securing the account. Responsibility for a loss must be assessed under the final agreement and applicable law; this draft does not automatically make you liable for every unauthorised action.
4. Services and the merchant's role
CryptiumPay provides a merchant interface and integrations for creating invoices, presenting available payment methods, tracking payment information, managing products and requesting withdrawals. Availability depends on the enabled features and merchant configuration. The merchant remains the seller of its goods or services and is responsible for descriptions, prices, delivery, customer support, taxes and its lawful refund obligations. A checkout page or merchant activation is not an endorsement of the merchant's products.
5. Invoices, assets and networks
An invoice identifies the requested payment and the token and network combinations currently available for it. The payer should use the displayed asset, network, address, amount and any required reference, and follow the invoice's time limits. Sending another asset, using another network or reusing an address outside the invoice instructions may prevent identification or recovery of a payment. A shared token name does not mean that transfers on different networks are interchangeable.
6. Payment status and merchant fulfilment
A submitted blockchain transfer may require confirmations and further processing before an invoice is treated as paid or funds become available. A transaction hash or a customer's screenshot alone is not proof that the required payment has been credited. Merchants should verify the current invoice and payment status before fulfilment and handle partial, excess, late or unresolved payments under their customer terms and the Payments & Refunds Policy. Blockchain reorganisations, network disruption and processing failures can affect status and timing.
7. Fees, quotes and taxes
The applicable processing terms must be disclosed to and agreed with the merchant before live use. Processing fees, withdrawal fees and blockchain network costs may differ. Review the displayed withdrawal quote, including the debit, fee, asset, network and amount to receive, before confirming. A quote may expire and need to be refreshed. This draft establishes no fixed fee, free processing promise or exchange-rate guarantee. Each party remains responsible for the taxes and reporting legally applicable to it; CryptiumPay does not provide tax advice.
8. Balances, settlement and asset handling
The console distinguishes available and reserved amounts. A confirmed payment and its balance update may occur at different stages, and a pending withdrawal may reserve funds. Report discrepancies and do not knowingly spend an erroneous credit. A displayed balance is not a representation of a bank deposit, interest entitlement or deposit insurance. The final agreement must explain who controls the relevant assets, how they are held and safeguarded, settlement timing and the merchant's rights if the operator becomes insolvent. This draft does not designate the service as custodial or non-custodial.
9. Withdrawal instructions
A withdrawal request must use an available balance, supported asset and network, a compatible destination address and the required security confirmation. Review the destination carefully; an executed blockchain transfer generally cannot be reversed by changing an account record. A request is not a guarantee of immediate execution. Network conditions, security checks, compliance requirements or technical faults may delay or prevent processing. Where lawful, the operator should explain unresolved requests and available next steps. Cancellation and recovery depend on the processing stage and technical feasibility.
10. Refunds and disputes about purchases
A customer seeking a refund for goods or services should first contact the merchant. CryptiumPay's role in a payment does not transfer the merchant's obligations to the platform. The Payments & Refunds Policy addresses payment exceptions and possible recovery separately from a merchant's commercial refund decision. A blockchain transfer has no built-in card chargeback mechanism, but this does not remove mandatory consumer rights or other lawful claims. No recovery or refund deadline is guaranteed by this draft.
11. Acceptable use and compliance requests
The Acceptable Use Policy and proposed AML / KYC Policy describe intended restrictions and verification requirements. Do not use the service for fraud, illegal goods, laundering proceeds, sanctions evasion, unauthorised access or concealment of the true merchant or beneficiary. Any final power to request information, restrict an account or hold a transaction must be exercised on a lawful basis and proportionately. Verification requirements and operational procedures must be established before these documents are made effective.
12. API integrations, webhooks and content
Protect integration credentials, authenticate notifications using the documented method and verify relevant payment status before performing irreversible fulfilment. Your systems should handle repeated notifications and temporary delivery failures. Only upload logos, product information and other content you are authorised to use. The proposed permission to use merchant content is limited to providing and displaying the service; ownership remains with the relevant rights holder. Third-party wallets, sign-in providers and blockchain networks have their own terms and risks.
13. Availability and crypto-asset risks
Network congestion, outages, maintenance, malicious activity and third-party failures can interrupt access or delay transactions. Crypto-assets may lose value; stablecoins can lose their reference value, and issuers may restrict transfers. Wallet errors, compromised credentials and unsupported transfers can cause permanent loss. There is no promise of uninterrupted access, fixed confirmation times, guaranteed recovery or investment returns. These statements do not exclude duties that applicable law imposes on the operator.
14. Restrictions, closure and remaining funds
The final terms should provide for proportionate suspension or termination for material breach, security risk, legal requirements or an inability to complete necessary verification. Where lawful, the operator should notify the merchant, explain available remedies and provide a route to resolve outstanding matters. Closing an account does not erase existing payment obligations or automatically transfer a remaining balance to the operator. Lawful withdrawal or return arrangements, retention duties and any continuing restrictions must be addressed explicitly in the final agreement.
15. Responsibility and mandatory rights
Each party's responsibility should reflect its role, conduct and applicable legal duties. No provision in these drafts is intended to exclude liability that cannot lawfully be excluded or to waive mandatory consumer, privacy or other statutory rights. Any proposed liability cap, exclusion of particular losses or indemnity must be separately reviewed in the chosen jurisdiction. This draft imposes no blanket waiver, automatic indemnity or arbitrary monetary liability limit.
16. Privacy, changes, complaints and governing law
Read the Privacy and Cookie Policies for information about data handling and browser storage. Contact support with a complaint, relevant invoice or withdrawal reference and a clear description of the issue; never include passwords, seed phrases or private keys. The final documents must state the complaint process, response periods, change-notification and acceptance process, governing law and competent dispute forum. These details are pending. Mandatory rights and access to legally available remedies must be preserved.
17. Details to complete before publication
Required details: operator identity and address; licensing position and supported jurisdictions; asset-control and safeguarding arrangements; agreed fees and settlement rules; complaint handling; enforceable liability provisions; governing law and dispute forum; policy version and effective date; and a reliable record of merchant acceptance. Obtain factual and legal review before presenting these drafts as operative terms.