Provider
Marketmagnet Communications PTE.LTD. · 230 Victoria Street #15-01 Bugis Junction Towers Singapore (188024) · UEN 202410422G
Terms
Working draft of merchant terms with a separate DPA draft annex and conditional references to Swiss law. Details and schedules remain incomplete; not legal advice or a concluded agreement.
Marketmagnet Communications PTE.LTD. · 230 Victoria Street #15-01 Bugis Junction Towers Singapore (188024) · UEN 202410422G
This working draft governs access to Finasca by reviewed business customers only. It is not an offer to consumers. A buyer or debtor does not become a party to these merchant terms merely by opening an invoice page, paying, uploading evidence, or disputing an invoice.
A company application is used to review the business and its authorised representative. The applicant must be authorised to act for the business and provide accurate information. An application, project creation or plan selection does not activate a paid subscription or create a right to activation. Merchants, projects and required evidence are reviewed before activation; missing approvals can prevent access. A paid merchant contract and its charges are accepted separately. The Privacy Notice explains how application data is used; it is not blanket consent.
Finasca provides software for hosted invoice forms, one-time and recurring invoices, payment status, reminder workflows, evidence, disputes, documents, bookkeeping views, and integration events. The exact scope depends on the agreed plan and features actually approved for use.
Finasca does not acquire claims, decide whether a claim is legally valid, provide legal advice, or independently perform debt-collection services. It does not commence court, debt-enforcement, execution, or other authority proceedings and does not promise payment, recovery, or a legal outcome.
Finasca does not process, receive, hold, or transfer customer funds and does not store payment-card details. Buyers pay directly to the account specified by the merchant. The merchant reconciles receipts and remains responsible for fulfilment, price, tax, invoicing, refunds, and customer communication.
The merchant must be entitled to provide the underlying service and pursue the claim. It must keep company, contact, product, price, tax, due-date, bank, privacy, cancellation, and support details accurate and current. It must configure and continually review its automated workflows, including source data, recipient rules, templates, languages, legal bases, and payment-status logic.
Finasca may be used only for lawful, evidenced, and approved transactions. False or misleading invoices, fraud, threats, review circumvention, unnecessary sensitive data, and unlawful goods or services are prohibited. Adult-content and pornography merchant flows are not supported in the MVP.
The merchant instructs invoice communications only through its lawful, documented settings. It keeps recipient details current and promptly records payments, credits and disputes. Interest, fees and further steps need a basis for the particular claim; these merchant terms do not impose additional buyer fees. Misleading demands and unrelated unsolicited advertising are prohibited. A recorded dispute blocks unsafe reminders and escalation; the merchant reviews the claim before permitted follow-up resumes.
Finasca may organize existing evidence and prepare documents for possible later handling. Any export or handoff requires a separate manual review and an actually approved workflow. Finasca does not legally assess the claim or conduct recovery itself.
For hosted invoice purchases, rules-based checks may allow the invoice option, limit it, require phone verification, or hide it. The merchant must not circumvent these controls. Authorized roles may change a decision only with a recorded reason; the privacy notice separately describes the data-protection aspects.
The separately accepted order states the plan, currency, charges, applicable taxes, billing start and interval, term, renewal and cancellation. Price changes follow only the process agreed in that order. This draft sets no new prices, minimum terms or notice periods. Recurring customer invoices are separate: they are not card charges and require a documented, lawful customer agreement; price, interval, term, cancellation and contact details remain the merchant’s responsibility.
Both parties comply with applicable data-protection law. The merchant supplies only necessary, lawfully obtained information and informs its customers about its processing. Processing on documented merchant instructions requires a separately agreed data-processing agreement. The clearly labelled DPA draft annex below prepares that agreement; missing details and schedules must be completed and agreed. Reading this page does not conclude a DPA.
The merchant protects accounts and API credentials, assigns only necessary roles and reports suspected misuse through the agreed support contact. It follows the documented signature, retry and status contracts. An API acceptance confirms only the processing step it describes. An email provider’s acceptance or delivery event proves neither that the recipient read the message nor that it was legally received. The merchant must not infer fulfilment authority from unconfirmed events.
Finasca may use approved service providers for technical operations. Maintenance, security measures, network failures, or provider incidents can temporarily restrict features. No particular uptime, delivery, response time, or fitness for a special purpose applies unless expressly agreed in writing.
The merchant retains its rights in submitted content and permits processing as needed for the agreed service. Rights in software, branding and documentation remain with their respective owners; the permitted use follows the agreed contract. Both parties protect the other’s confidential information and restrict access to people and providers who need it and are bound to confidentiality.
Access may be proportionately restricted for security risks, missing approval, false information, misuse, legal breaches, or due platform fees. Notice periods, termination, data export, and deletion must be set in the final agreement; legal duties, active disputes, and evidence requirements may require further retention.
This working draft deliberately contains no binding liability cap. Mandatory liability, including for intent, gross negligence, and other liability that cannot legally be excluded, remains unaffected. Qualified counsel and the final agreement must define any cap, indirect-loss treatment, warranties, and country-specific exceptions.
Governing law, venue, document precedence, amendment procedure, and effective date have not been selected. They must not be inferred from the operator's location or the website language and must be legally reviewed and stated expressly before contract acceptance.
Working draft with conditional references to Swiss law for further preparation and later legal review, not legal advice or an already agreed contract. The DPA annex is also a draft. The provider details above, countries served, commercial terms and open schedules must be reviewed and completed against actual operations before binding use. This page activates neither merchant access nor a paid contract.
This separately labelled annex proposes an agreement between the merchant named in the merchant contract as controller and the Finasca operator identified above as processor. It has not been concluded and does not replace an existing agreed DPA. The following clauses and three schedules must be completed before binding use; viewing the page or submitting a company application does not agree them.
Proposed clause: Finasca processes the data in Schedule 1 only for agreed merchant workflows and documented instructions, including authorised configurations and API requests. If Finasca considers an instruction unlawful, it informs the merchant for clarification. Access is limited to people who need it and are bound to confidentiality. Finasca’s own purposes remain separate from this processing and are described in the Privacy Notice.
Proposed clause: Finasca maintains the technical and organisational measures documented in Schedule 2 and appropriate to the risks. Changes must maintain appropriate protection. Finasca supplies suitable evidence and permits proportionate verification that protects other merchants’ data and system security. Scope, procedure and responsibility remain to be agreed in Schedule 2; no certification or completed audit is asserted here.
Proposed clause: The merchant authorises the subprocessors named in the completed Schedule 3. Under general authorisation, additions or replacements are notified in advance with an opportunity to object on data-protection grounds. The notice period, resolution process and consequences of an unresolved objection remain open. Finasca binds subprocessors to corresponding obligations. Countries and operative transfer safeguards must be documented for each processing activity; mentioning standard clauses does not replace putting them in force.
Proposed clause: Finasca assists the merchant with individual requests, required risk assessments and supervisory enquiries within the agreed scope. Upon learning of a data security breach affecting merchant data, Finasca informs the merchant as soon as possible about known circumstances, consequences and measures, and supplies updates. The merchant assesses its own reporting duties. Working incident contacts, responsibilities and procedures remain to be entered.
Proposed clause: At the end of the contract, merchant data is returned or deleted under the agreed instructions and timetable in Schedule 1, except where legal retention is required. Retained information remains protected and restricted to the retention purpose. Export format and window, deletion confirmation, backups and technically immutable evidence must be expressly addressed. This draft does not promise that complete automatic deletion already exists.
The subject is the invoicing, communication, payment-status, dispute and evidence workflows actually agreed. People concerned are customers, debtors and merchant contacts; data can include identity, contact details, language, address, order, invoice/PDF, payment status, communications, consent and dispute evidence. Unnecessary sensitive personal data is excluded. Still to enter: exact workflows and fields, authorised instructors, start and duration, category-specific retention, legal exceptions, export and deletion including backups.
The source implements roles and merchant boundaries, protected sessions, signed API requests, private PDF read controls and audit events. These observations do not verify every production setting. Still to evidence and agree: actual personnel access, transport and storage protection, backups and recovery, security reviews, incident handling, verification procedures and responsible people. No ISO, SOC or other certification is promised.
The binding list has not been completed. Each provider actually used needs verified entries for its legal entity, function, data categories, storage and remote-access countries, subprocessors, authorisation, agreement and operative transfer safeguards. Until completed, this draft makes no claim about exclusive storage in Switzerland or already authorised providers.
Use the contact form for questions about these terms and billing.
Open contact formNo final version configured yet.
Temporary working draft, not legal advice, and not approved for public production use. Replace it or have it expressly approved by qualified counsel. Still unresolved: final lawyer-approved legal content in the deployed source, lawyer review and approval, authorized representative, another required item, terms version, privacy notice version.