Micalpays

1. What we do not collect

To operate a client account we neither request nor store:

• Personal data of our clients' end users: no names, emails, identity documents or bank details. For each payment we only receive the blockchain address it must be sent to.
• Card or bank account details of anyone.
• Client passwords: the API and the client portal authenticate with a key we generate (plus the business's public identifier). The only passwords in the system belong to the staff who operate the admin panel.
• Device location, advertising identifiers or behavioral analytics, neither on the website nor in the panel.

How each client identifies its own users is exclusively that client's business and happens in its systems, not ours.

2. What we do store and why

• Client name. The name identifying your application or business. It can be any text; we do not verify that it matches a registered company.
• Business identifier. A random public identifier (UUID) generated when the account is created. It is the "username" for the client portal and reveals nothing about you.
• API key. Generated when the account is created and shown exactly once. We do not store the key itself: we store a SHA-256 hash and its first characters, used to identify it in logs without exposing it. It is also your client portal password.
• Deposit addresses and collections. For every deposit address you request: the label you identify it with, the address, its private key encrypted with a dedicated key (never in the clear), the expected amount, the expiry and the metadata you decide to attach; and for every collection received: network, asset, amount, sender address, transaction hash, confirmations and status, plus the sweep that moved it. All of it is public chain data or yours; the label and the metadata are yours and we recommend not putting your users' personal data in them.
• Webhook configuration. Your server's URL for outbound payment notifications, an optional URL for future funds-received notifications, the secret we use to sign each notification (HMAC-SHA256) and how many on-chain confirmations you want us to wait for before sending it.
• Destination address for your funds. The blockchain address you declare to receive funds owed to you. It is public on-chain data, not personal data.
• Acceptance of the Terms. The date and time you accepted these documents when registering, and the version (effective date) you accepted, as a record of the agreement.
• Account status, limits and capabilities. Whether the account is pending, active or suspended; the per-transaction and daily caps for each asset, and which features it has enabled.
• Payment requests. For each payment: its external reference, network, asset, amount, destination address, status, transaction hash and timestamps. We keep them to execute the payment, guarantee idempotency, notify you and audit the operation. On-chain data is already public on the blockchain.
• Webhook deliveries. Which notifications we sent, when, and with what response, so we can retry failed ones and resend them on request.
• Client's Safe (optional). If you register it in the portal, the public address of your multisig Safe and, for each network where it is deployed, a copy of its owners and signature threshold as published by the chain, to check that none of our keys is an owner and to be able to propose replenishments. They are public chain data, not personal data, and you can remove them whenever you want.
• Treasury replenishments. A local record of every replenishment proposed from the client's Safe to its operational wallet, with its on-chain hash, who proposed it, who executed it and the gas it cost, as an audit trail and to charge that gas.
• Operational wallet. Each client has a hot wallet of its own. Its public address and its private key, encrypted at rest with a dedicated key distinct from the application key, are stored in our database; the private key is only decrypted at signing time and is never displayed, exported or logged. Micalpays does not hand recovery phrases or private keys to its clients, nor does it accept those of a client's wallet. The client's Safe keys are never on our servers.
• Operations email (optional). If you set one in the portal, an email address to which we send only the funding alerts of your operational wallet (how much is missing and when to top up) and the notice that your destination wallet changed. We use it for nothing else and you can remove it at any time.
• Contact form. If you write to us from the website, we receive the name, email, subject and message you enter, solely to reply to you.

3. Technical security data

Like any internet service, our infrastructure records IP addresses in the server access logs to detect abuse, attacks and errors. Application logs identify each API call by the prefix of the key used, never by the full key. These logs are rotated periodically and are not used to build profiles. The API limits the number of requests per minute for each client; that counter is temporary and is not retained.

4. Cookies

The website, the client portal and the admin panel use a single, strictly necessary session cookie, together with the token that protects forms against request forgery. On the public website it only stores the language you chose; in the client portal and the admin panel it keeps you signed in. It expires after two hours of inactivity. We do not use tracking, advertising or third-party cookies. The API does not use cookies.

5. Who the data is shared with

We do not sell data or share it with advertisers or data brokers. We only use providers that are necessary to operate the service:

• Hosting provider — the servers and database the Service runs on.
• Blockchain node providers — they receive only addresses and on-chain transactions, which are already public.
• Safe (multisig infrastructure) — it receives the replenishment proposals to the operational wallet and reports their status; they are on-chain transactions plus the public address of the client's Safe.
• Email provider — for internal operational alerts and to reply to the contact form.
• Your own server — if you configure a webhook, we send your payment data to the URL you specify.

We may also disclose data when a valid law or court order requires us to.

6. The blockchain is public

The transactions Micalpays executes are recorded on public blockchains. They are permanent, visible to anyone and cannot be modified or deleted, neither by us nor by you. Any right to erasure refers only to the copy we keep in our systems, never to the chain.

7. Retention and deletion

• Account data (name, key hash, webhook, limits): for as long as the account exists. When the key is rotated, the previous hash is discarded immediately. When the account is closed, the key is invalidated and the webhook URL and secret are deleted.
• Payment and replenishment history: for as long as the account exists and, afterwards, for the period required by applicable accounting and tax regulations, as an audit record. On-chain data remains public.
• Webhook delivery log: together with the payment it belongs to.
• Session cookie: two hours of inactivity.
• Technical access logs: rotated periodically.
• Contact form messages: until the inquiry is closed.

8. Your rights

Depending on your jurisdiction, you may have the right to access the data we hold about your account, correct it, request its deletion or object to certain processing. Access is exercised directly in the client portal: the Configuration tab shows everything we hold about the account (name, identifier, key prefix, status, features, limits, webhooks, destination wallet, creation date and acceptance of these documents), together with the payout and webhook delivery history, and from there you can correct your configuration. For anything else (correcting the name, deleting the account, objecting to processing), write to support@micalpays.sbs. Since we do not store the identity of the people behind an account, we will ask you to prove control of the account, for example by signing a request with your API key.

9. Minors

The Service is aimed at businesses and applications, not consumers, and is not directed at anyone under 18. We do not knowingly collect data from minors.

10. International transfers

Our providers may process data on servers outside your country. All of them apply industry-standard security measures and encryption in transit.

11. Changes to this policy

If we change this policy, we will update the effective date on this page and announce it in the client portal, which shows the current version next to the last one each account accepted. Since, for data minimization, we keep no contact details for clients, the portal and this page are the notification channel: if a change expands the data we collect, the notice is published before it takes effect.

12. Contact

For any privacy question: support@micalpays.sbs.

13. Data controller and second-factor data

The controller of the data described in this Policy is the operating entity (to be defined; it will be published on this page before agreements with third parties are signed), with its address at the address published on this page (to be defined) and email support@micalpays.sbs, under the laws of the jurisdiction of the operator's domicile (to be defined).

If you enable the second factor we store the TOTP secret encrypted at rest, the hashes (not the codes) of your recovery codes and a security log (event, result, IP and date) of second-factor sign-ins, enablings, disablings, rotations and recoveries, visible to you in the portal. They are kept while the account exists.

Sandbox data (test accounts, addresses, collections and payouts) is fictitious, can be wiped from the portal and is deleted automatically after the retention period published in the documentation.