Privacy policy

This policy describes which personal data is processed when you use KAI-Pay: the website kai-pay.net, the wallet at app.kai-pay.net, the point of sale at kasse.kai-pay.net, the payment pages kai-pay.net/@name and the Android apps “KAI-Pay” and “KAI-Pay Beta” (section 2.11).

The wallet does not require a KAI-Pay user account. It uses local storage and connects to external services as described below. This section does not cover the session cookie of the separate, authenticated checkout for KAI Oracle’s paid company access on kai-oracle.com; KAI Oracle’s privacy notice applies to it. Your recovery words are stored only in encrypted form on your device. For payments, however, the wallet connects directly to services of other providers, some of them on every start and without any action on your part; sections 2 and 6 list them. Section 4 explains what you can and cannot delete when you remove the wallet.

1. Controller and contact

The controller for our processing described below is:

Formsys GmbH
Grafenberger Allee 277–287
40237 Düsseldorf
Deutschland

Contact for privacy requests: kontakt@kai-pay.net

Cloudflare forwards messages to kontakt@kai-pay.net to us as an email forwarding service (section 6). In doing so, Cloudflare processes your sender address, the content of the message and the connection data of the delivery. Please do not send recovery words, private keys, passwords or active access tokens.

Some features rely on services of other providers that also process data themselves. Section 6 lists them, where available with a link to their own information.

2. What data we process and why

Your rights and contact options also apply where a connected service is involved. Statutory duties and permissions do not arise merely from accepting terms of use. For each processing activity we state the legal basis under Article 6(1) GDPR. “Point (b)” means the processing is necessary for the function you use under our terms of use. “Point (f)” means we rely on a legitimate interest, which we name in each case.

2.1 Visiting the website kai-pay.net

Data: IP address, time, requested address and the technical information your browser sends with every request, for example browser type and version.
Purpose: Delivering the pages, redirecting to an encrypted connection (HTTPS), forwarding our other domains (kai-pay.org, kai-pay.online, kai-pay.world and the www addresses) to kai-pay.net, protection against attacks.
Legal basis: Article 6(1)(f) GDPR. Our interest: providing the website securely and reliably.
Recipients: Cloudflare as processor (section 6).
Retention: We do not keep our own access logs; no log storage is switched on in our configuration. Cloudflare processes connection data for delivery and protection against attacks under its data processing addendum.

The website contains no JavaScript and loads no content from third-party servers.

2.2 Delivering the wallet and the point of sale

Data: Connection data as in 2.1 when you load the app files or the wallet contacts our server.
Purpose: Delivering the wallet (app.kai-pay.net) and the point of sale (kasse.kai-pay.net). After the first visit the wallet starts from your browser’s storage (section 3).
Legal basis: Article 6(1)(b) GDPR.
Recipients: Cloudflare as processor.
Retention: As in 2.1.

2.3 Payments, balance and wallet synchronisation

The wallet uses the Breez SDK with the Spark network. The SDK runs in your browser or in the app and connects directly, not via our server, to the services named below.

Some of these connections are made on every start of the wallet without any action on your part: the SDK signs the app in to Breez, synchronises the wallet with the Spark operators (repeating roughly every minute while the app is open), asks breez.tips for this wallet’s Lightning address (2.5) and signs in to Flashnet’s interface api.flashnet.xyz to ask for pending refunds of token conversions. The sign-in to Flashnet takes three steps: the wallet sends its public identity key and receives a challenge, signs it on your device with the identity key, and uses the access token it receives to ask for the transfers that can be reclaimed. This happens on every start, even if you never converted anything; the token is held in working memory only, so the wallet signs in anew each time. Flashnet receives the public key, the signature, your IP address and the time, but not your recovery words, your balance or Breez’s API key. KAI-Pay offers no token conversions; this query is built into the SDK, has no switch of its own, and could only be switched off together with all of the SDK’s background tasks, including the automatic receipt of payments.

Each request for a Bitcoin deposit address creates a new address; earlier ones remain valid. Deposits from different payers therefore do not go to a shared address.

Private mode. When connecting, the wallet switches on the Spark network’s private mode unless you have switched it off under “Settings” → “Privacy”. It hides your wallet’s balance and Bitcoin payments from public Spark indexers (such as Sparkscan). The Spark operators and Lightspark still see your payments; tokens are excluded, and anything on the Bitcoin blockchain remains public.

Data: Your wallet’s public identity key, when signing in to api.flashnet.xyz together with a signature created on your device; amounts, invoices (Lightning invoices) including any note entered, payment and transfer identifiers and times; your Bitcoin deposit addresses, Bitcoin addresses you withdraw to, and the related transactions; the private-mode setting; your IP address.
Purpose: Sending and receiving, showing balance and payment history, synchronising with the network, fee estimates and Bitcoin blockchain queries; at api.flashnet.xyz, the query built into the SDK.
Legal basis: Article 6(1)(b) GDPR. For the query at api.flashnet.xyz, Article 6(1)(f) GDPR; our interest: being able to run the SDK with its background tasks, including the automatic receipt of payments.
Recipients: The Spark operators Lightspark, Breez and Flashnet, which take part in transfers in the Spark network; Flashnet additionally via api.flashnet.xyz; the Spark service provider Lightspark for Lightning payments, for deposits and withdrawals via the Bitcoin blockchain and for the technical splitting of your balance; mempool.space for Bitcoin blockchain queries; Breez for signing the app in to its services, which uses the KAI-Pay API key.
Retention: On your device until you remove the data (sections 3 and 4). At the providers according to their information (section 6). Entries on the Bitcoin blockchain are permanently public (section 5).

2.4 Paying Lightning addresses and LNURL links

When you enter or scan an address of the form name@domain or an LNURL link, the wallet retrieves the payment details directly from the server of that domain as soon as it checks the input, that is before you confirm a payment and even if you do not do so afterwards. With the amount, it requests an invoice there. If the domain does not provide a Lightning address, the SDK uses Cloudflare’s DNS service (cloudflare-dns.com) to check whether the domain publishes a Bitcoin payment instruction for it (BIP 353). The DNS service receives the name queried. The recipient’s server receives the name, where applicable the amount and a comment, and with the web app the information that the request comes from app.kai-pay.net. Both receive your IP address. The recipient decides which server that is. If you refund a till payment from “Point of sale & closing” to a Lightning address or via an LNURL link, the wallet also sends this server the note “Refund for receipt …” with the receipt number (shortened if necessary), provided the server accepts notes. If a QR code contains the identifier of certain merchant payment systems (currently Pick n Pay and Bootleggers), the Breez SDK retrieves the payment details from the cryptoqr.net service.

Legal basis: Article 6(1)(b) GDPR.

2.5 Lightning address and payment page

In the wallet you can set up a Lightning address of the form name@breez.tips. The wallet checks with Breez’s LNURL server breez.tips whether the name is available and registers it there for your wallet. The address’s public description there is the neutral text “Pay to name@breez.tips”, which other wallets at breez.tips use as well; the wallet switches older addresses with the description “KAI-Pay” to this text once. Breez still recognises the app by its API key. The name is public: anyone who knows it can request invoices through it and send you payments.

Whether or not you set up an address, the SDK asks breez.tips for this wallet’s address on every start of the wallet. Breez receives the wallet’s public key, a signature created on your device, the time, KAI-Pay’s API key (as a header) and your IP address. This query cannot be switched off in the app; in the SDK it could only be switched off together with all Lightning-address functions.

For every such address, kai-pay.net/@name shows a payment page. When someone opens it, our server retrieves the payment details for this name from breez.tips. When the person enters an amount, our server requests an invoice for that amount there, with the note entered if any, and checks the payment status on request. Our server makes the request to breez.tips; it passes on no information about the person opening the page, including their IP address. Our server limits the number of page views and invoice requests per IP address (per /64 range for IPv6); the IP address serves only fleetingly as a counting key and is not stored.

Data: The chosen name; for the query on start, the wallet’s public key and the IP address. When a payment page is opened: connection data as in 2.1, amount, note, invoice and payment status.
Legal basis: For setting up the address and the query on start, Article 6(1)(b) GDPR. For people who open a payment page, Article 6(1)(f) GDPR; our interest: providing the payment page requested, retrieving the invoice requested and preventing abuse.
Recipients: Breez (breez.tips); Cloudflare as processor.
Retention: The payment page creates no records on our server. The name registration is held by Breez; its duration follows the provider’s information. The wallet does not currently offer deleting a registered address (section 4).

2.6 Contacts and synchronisation between your devices

The Breez SDK stores contacts (name and Lightning address) and additional payment details on your device. For every open wallet it automatically starts synchronisation through Breez’s synchronisation service (datasync.breez.technology), even if you use the wallet on one device only; this is how the details are synchronised with other devices on which the same wallet is open. The records are encrypted on your device beforehand; the key is derived from your wallet. Breez receives the encrypted records, your IP address and the time.

Legal basis: Article 6(1)(b) GDPR.
Recipients: Breez.
Retention: On your device until you remove the data (sections 3 and 4); at Breez according to its information.

2.7 Exchange rates in the wallet

To also show amounts in a reference currency of your choice, the wallet retrieves current rates from a Breez server through the Breez SDK – on every refresh of the display, also in the background, and additionally every 5 minutes while the wallet is visibly open; once per session also the list of available currencies. This happens regardless of whether you look at the conversion. The wallet no longer converts with rates older than 15 minutes. Your IP address and the time are transmitted. Legal basis: Article 6(1)(b) GDPR.

2.8 Passkey and fingerprint unlock

You can create a wallet with a passkey or unlock the app with your fingerprint (WebAuthn with the PRF extension). In the browser, “fingerprint” means that your device verifies you for the passkey (WebAuthn user verification). Depending on device and settings, your face or the PIN, pattern or password of your screen lock may be accepted instead of a fingerprint. The check takes place in your device or at your passkey provider; neither the app nor we receive biometric data. The app only receives a value derived from the passkey, which it uses to derive your wallet or decrypt the vault.

Depending on your device and settings, passkeys may be synchronised by your operating system’s or browser’s password manager; its terms apply. For a passkey wallet, the basis of your wallet then also resides with the synchronisation service, encrypted according to that service’s own information. Anyone with access to that account can open the wallet.

For passkey wallets, the Breez SDK uses Nostr relays to store the wallet’s label (“Default” by default) and retrieve it when the wallet is opened. The label is published as a public, unencrypted Nostr message under a key derived from your passkey. The relays used are one run by Breez (nr1.breez.technology) and public relays of other operators (relay.primal.net, relay.damus.io, relay.nostr.watch, relaypag.es, monitorlizard.nostr1.com). The SDK may also publish a list of the relays used there. The relays also receive your IP address. Their operators decide how long they keep messages.

Legal basis: Article 6(1)(b) GDPR.

2.9 Notifications of incoming payments and security alert

This processing only takes place if you switch on notifications in the wallet settings. This is possible in the web app, in the app “KAI-Pay” and, from version 0.4.1, in the app “KAI-Pay Beta”.

Data stored: On our server: your browser’s push subscription address (endpoint) or, in the app “KAI-Pay Beta”, the device’s FCM token, each with the related public keys (p256dh, auth), an identifier, the language of the notifications and whether notifications should show the amount. Our server derives the identifier from the endpoint or token and the keys, so that repeating the same registration does not create a second entry. It does not store the webhook secret but derives it for every check from the identifier and a server key of its own. Only entries of notifications switched on before this change in October 2026 still contain a random identifier and the webhook secret.
How it works: For this, your browser sets up a subscription with its push service. The wallet registers a webhook address of our server and the webhook secret with the Spark service provider Lightspark (2.3). For every incoming Lightning payment, Lightspark sends a message signed with this secret to that address. The message contains payment details, including the amount; our server thereby learns the time of incoming Lightning payments. If the security alert is switched on (default; can be switched off under “Also for sent payments (security alert)”), the wallet additionally registers a second webhook address of our server with Lightspark for outgoing Lightning payments. Lightspark sends a message signed in the same way to that address for every Lightning payment your wallet sends or tries to send, including from another device with the same recovery words. This message contains, among other things, the amount, the fee and the invoice; our server thereby also learns the time of outgoing Lightning payments. Whether a message concerns an incoming or a sent payment, it recognises from the webhook address, not from the content. It checks the signature and does not store the message. When unlocking, the wallet also checks whether webhook addresses of our server are still registered for it with Lightspark that no longer belong to a push entry, for example after a lost device or a failed unsubscribe. For this, it sends only the identifiers of these addresses to our server; the server answers which ones it does not know and stores nothing. The wallet removes such registrations only if a second check two minutes later gives the same result, so that a subscription just switched on on another device is not affected. If there are no such addresses, it does not ask. The app “KAI-Pay Beta” does not ask our server for this; it shows such registrations under Settings → Notifications, and you can remove them there yourself. It evaluates the amount only if “Show amount in notifications” is switched on, and for sent payments then also whether the send attempt failed. For newly switched-on notifications this option is off; the notification then only says “Payment received” or “Payment sent”. For notifications switched on before the option was introduced, it is on until you switch it off. Our server pads the notification to a fixed length, encrypts it for your browser (Web Push under RFC 8291) and delivers it through the push service of your browser’s maker. The push service receives the endpoint, the time and the message in encrypted form only. In the app “KAI-Pay Beta” (from version 0.4.1), a registration with Google’s Firebase Cloud Messaging (FCM) service takes the place of the browser subscription: the app creates its own key pair, whose private part never leaves the device (encrypted with a key in the Android Keystore), and sends our server the device’s FCM identifier (token) together with the public key. Our server encrypts every notification for this key as it does for browsers and delivers it through FCM as a data message; Google receives the token, the time and the message in encrypted form only. The app decrypts it on the device and shows it.
Short-lived markers: So that a message delivered more than once triggers only one notification, even if it arrives at different Cloudflare locations, our server keeps a marker made of the identifier and a checksum (hash) of the message for 24 hours in a Cloudflare storage that applies to all locations (Durable Object, one per identifier). So that a repeated identical registration is not stored again, it keeps a marker made of the identifier and a checksum of the push entry for 1 hour in Cloudflare’s cache at the location that receives the request. Both markers contain no content. To limit storage access, the server also keeps the push entry of an identifier in this cache for up to 60 seconds after a payment event. After unsubscribing, a notification may therefore still arrive via another location for about one to two minutes (cache plus propagation in Cloudflare’s storage).
Receipt confirmation: After a notification, your browser or the app reports to our server a random marker of the notification, whether an app window was open and whether the notification could be shown. This information is not stored.
Diagnostics: For subscription, test, delivery and the check of remaining registrations (there only the number of checked and of unknown identifiers), our server writes short event lines: type of event, time, the first four characters of the identifier, the server name of the push service, result, status code and number of delivery attempts, the random marker of the notification, whether it concerns an incoming or a sent payment, and whether an amount was recognised (not the amount). They contain no IP addresses, amounts or keys. The lines are only visible while someone is watching the server output live and are not stored; our server logs are switched off. Only if we temporarily switch on diagnostic storage to investigate an error are the events stored, for at most 3 days. An automated health check of our server (every 30 minutes, with its own access key) reads only a fixed probe entry and no user data.
Request limit: Wallet requests to subscribe, unsubscribe, test, check status (when unlocking, at most once an hour, with identifier and webhook secret, so that the wallet can re-subscribe automatically after our server changes its key; nothing is stored) and confirm receipt are limited per IP address, to 20 per minute and subscriptions to 3 per minute; for IPv6 the /64 range counts. The IP address serves only fleetingly as a counting key for the limit, which Cloudflare applies on our behalf; our server does not store it. In addition, our server allows at most 20 new subscriptions per connection and day. It counts under a key that it computes (pseudonymised: it can only be linked to an IP address with this server key) from your IPv4 address or IPv6 prefix (/56, additionally /48) and the date with a server key of its own; the counter is kept in Cloudflare’s cache until the end of the day (UTC), at most 24 hours. The same method also limits storage queries per connection and day. The IP address itself is not stored.
Legal basis: For notifications and the security alert, Article 6(1)(b) GDPR. For short-lived markers, receipt confirmation, diagnostics, request limit and daily counter, Article 6(1)(f) GDPR; our interest: checking delivery, avoiding duplicate notifications and entries, fixing errors and preventing abuse and overload.
Recipients: Cloudflare as processor; Lightspark; the push service of your browser’s maker or, in the app “KAI-Pay Beta”, Google Firebase Cloud Messaging (section 6).
Retention: The push entry is deleted 400 days after you switch notifications on, or earlier if you switch them off, remove the wallet from this device or the push service reports the subscription as invalid. When you switch notifications off, the wallet also removes its webhook registrations at Lightspark, and when you switch off only the security alert, the registration for sent payments; section 4 explains what applies if that fails. Duplicate markers expire after 24 hours, registration markers after 1 hour, daily counters at the end of the day (UTC), stored diagnostic events after 3 days.

2.10 Point of sale

The point of sale at kasse.kai-pay.net holds no keys and cannot send money. It is set up with a link from the wallet. Lightning address, till name and receipt key are placed after the # sign of this link and therefore reach no server; the point of sale stores them in the browser of the point-of-sale device. For each payment it requests an invoice for the amount directly from the browser at the LNURL server breez.tips and checks its payment status: the invoice shown every 2 seconds until paid, cancelled invoices that have not yet expired every 10 seconds. For entry in a national currency (EUR, USD, GBP, CHF, CAD, AUD or JPY) it retrieves the current rates directly from mempool.space. These providers receive the IP address of the point-of-sale device.

Till note. The point of sale attaches to every invoice a note with device identifier, till name, receipt number, amount in national currency and rate – for points of sale set up via the wallet’s current point-of-sale link also the time of the rate and, when charging with articles, the lines (article identifier, quantity, unit price) –, so that the owner’s wallet can match the payment. If the point-of-sale link contains the wallet’s receipt key, the point of sale encrypts this note so that only this wallet can read it. Of the content, breez.tips then only sees roughly how long the note is (in steps of 64 bytes; notes with lines are usually one step longer, so breez.tips can tell that articles were charged, not which) and a constant short identifier of the wallet (4 bytes) that links all notes to the same wallet. Point-of-sale links without a receipt key, such as older links or links from an app version without this feature, send the note unencrypted; the point of sale then shows a notice. The point of sale never sends amounts in currencies other than euro or lines unencrypted; without a receipt key they are left out of the note.

Even with an encrypted note, breez.tips sees the merchant’s Lightning address, the invoice amount in sat, the times of the invoice, the status checks and the payment, and the IP address of the point-of-sale device. Encryption hides the content of the note, not the payment itself (section 5).

Legal basis: Article 6(1)(b) GDPR.
Recipients: Breez (breez.tips); mempool.space; Cloudflare as processor for delivery.
Retention: The point of sale creates no records on our server. Merchant address, receipt key, till, receipt counter, article catalogue and the chosen currency stay in the browser until you choose “Andere Adresse” (other address) or delete the site data. Of the recent invoices, the point of sale uses at most 20 from the past 7 days; it deletes older ones as soon as it saves something again, for example at the next sale.

2.11 Android apps

Distribution. The apps are currently provided only as a test version (pre-release) via GitHub, not via Google Play. When you download them, the respective provider processes your connection data and, where applicable, your account data under its own responsibility (section 6). We receive no information about you from this.

KAI-Pay (Trusted Web Activity). The app opens the wallet at app.kai-pay.net in Google Chrome without an address bar. Sections 2.2 to 2.9, 2.12, 2.13 and 3 apply unchanged. The wallet data is stored in Chrome’s site data and shares storage with the wallet when you open app.kai-pay.net in Chrome. Chrome processes data under Google’s terms. On Android 13 and later, the app asks at first start whether it may show notifications; this is only needed for notifications of incoming payments (2.9) and can be declined.

KAI-Pay Beta (Capacitor). The wallet’s program files are included in the app package and are not loaded from our server. The app connects directly to the services named in 2.3 to 2.8 as described there. It connects to our own servers only if you switch on notifications from version 0.4.1 (2.9): to subscribe and unsubscribe, for test notifications and delivery acknowledgements. Links to kai-pay.net and the point of sale open your browser (2.1, 2.2). This app does not offer creating passkey wallets (2.8). Notification registrations that exist for your wallet at Lightspark from a browser are shown under “Settings” → “Notifications”, and the app removes them at your request; in doing so it talks only to Lightspark (2.3). Usage and diagnostic statistics of the Android system WebView to Google are switched off in the app. The app receives new features of the web wallet with a new app version; the version you use is shown under “Settings” → “About”. Anything your app version does not yet contain does not take place in it.

Fingerprint unlock. Instead of a passkey (2.8), the app additionally encrypts your recovery words with a key that the Android key system (Android Keystore) generates and keeps in the device’s security hardware (StrongBox or Trusted Execution Environment). This key cannot leave the device. It is released only after Android has verified your fingerprint or another strong biometric method. The verification takes place solely in the operating system; neither the app nor we receive biometric data. If you add a new fingerprint on the device or remove the screen lock, Android makes the key unusable; the app then unlocks with the PIN only. For this reason the PIN always remains available as an unlock method in this app.

Camera. To scan QR codes, Android asks once for the camera permission. The image is analysed in the app and not transmitted. You can revoke the permission in the Android settings at any time.

Files. From Android 10, the app saves exports, the emergency package and the watch extract (2.13) and calendar files of standing orders (2.17) directly in the “Download/KAI-Pay” folder of your device and then tells you the folder and file name; on Android 7 to 9 through the “Save as” dialog at the location you choose. Other apps with file access can also read files in the Download folder. The app does not ask for a general storage permission.

Payment links. The app is registered for links of the form lightning: and bitcoin:. If you open such a link, Android passes its content to the app; it lands in “Send” and is paid only after your confirmation.

NFC. From version 0.5.0, the app accepts NFC tags with a payment link (lightning:, bitcoin:): if you hold the unlocked phone to such a tag, Android reads it and passes it to the app – even if it was closed. It is treated like a payment link and only paid after your confirmation; if a process is open, it stays unchanged, and the app only offers the new link to open. Reading sends nothing; the app ignores other content. Android does not ask for the “NFC” permission; NFC can be switched off in the Android settings.

NFC offering (phone to phone). If you tap “Offer via NFC” under “Receive”, the app hands out exactly the displayed payment link (invoice or Lightning address) via NFC for at most two minutes (host card emulation, only while the device is unlocked). During this time any device within NFC range can read it, also repeatedly. Only this link is transmitted – for an invoice with the details it contains (amount, note, recipient node, payment reference, expiry); no server is involved. Offering ends when you leave the app, with “Stop NFC” and, for an invoice, as soon as the payment arrives. While offering, the app does not read NFC links itself.

Location. From version 0.5.0, Android asks for your approximate location only for “Near me” under “Find merchants” (2.14) (Android 12 and later; on older devices the place search remains). The app does not request a precise location.

Screen protection. The app prevents screenshots, screen recordings and preview images in the recent-apps overview.

Legal basis: Article 6(1)(b) GDPR.

2.12 AI payment proposals

In the wallet you can set up sources that may propose payments to you, such as the Telegram bot KAI (Menu → “AI budget”; in the wallet, sources are called “assistants”). You set up a source by scanning its QR code or pasting or opening its code or setup link and comparing the fingerprint shown. In doing so you decide which recipients proposals may go to and which daily and monthly budget applies; the wallet does not accept invoices for proposals.

The source sends you proposals as a signed link or QR code. The content of a link is placed after the # sign; the wallet sends it to no server, including ours. The wallet checks the signature, validity, allowed recipients and budget on your device. A proposal only pre-fills the send screen; it does not replace your authorisation of the payment. Recipient, amount, unit and fees are shown and checked before every payment, and nothing is paid until you confirm. The wallet does not report to the source whether you pay a proposal; if the recipient belongs to the source itself, the source learns of it as the recipient of the payment.

We do not process proposals on any server. On your device the wallet stores the sources you have set up and a budget ledger (section 3). Whoever operates a source knows the recipient, amount and purpose of the proposals it creates; the source’s operator is responsible for this processing. For KAI, this information is kept in the Telegram chat history, which means Telegram receives it as well, and in the bot’s audit log.

Under “AI budget” you can also create an assistant yourself. The wallet generates a key pair for it and stores the private key only once you save the rules, and only on your device (section 3). You can use it to create proposals yourself or hand it to your own agent as an “access file for agents”. The file allows creating proposals but not triggering payments; every proposal goes through the same checks and your confirmation. You decide whom you give the file to; we are not responsible for the processing by that recipient.

Legal basis: Article 6(1)(b) GDPR.

2.13 Emergency package and exports

Under “Settings” → “Emergency exit” you can back up your wallet’s exit data as an emergency package. Exit data are prepared Bitcoin transactions for your balance that are needed for a unilateral exit without the Spark operators. The file also contains the wallet’s public identity key, your Lightning address (if any), the SDK version and the time. The wallet encrypts it on your device with a key derived from your 12 words (AES-256-GCM); it contains neither the words nor private keys. You decide where it is saved: in the browser, your browser downloads the file; the app “KAI-Pay Beta” saves it in the “Download/KAI-Pay” folder from Android 10, and on Android 7 to 9 you choose the location in the “Save as” dialog (2.11). The file does not reach us.

Also under “Emergency exit” you can save a watch extract. It is meant for a checker or watcher on your own Bitcoin node that should never see your 12 words. It contains the same exit data as the emergency package, plus the Bitcoin network, the SDK version, the time, whether the data was synchronised when saved, and your balance as shown by the wallet. It is deliberately not encrypted so that the checker can read it without your words. It contains no words and no private keys; nobody can use it to send money to others. Anyone who has the file can, however, force the unilateral exit of your balance to the Bitcoin blockchain at their own cost (for you, waiting time and fees; small amounts can be used up), and learns the amount and structure of your balance, your wallet’s public identity key and the related Bitcoin transactions. Do not pass the watch extract on, transfer it only to your own devices and then delete it from your phone. Neither KAI-Pay support nor any KAI-Pay checking tool asks for this file. It does not reach us.

Likewise, CSV exports of the activity list and of “Point of sale & closing”, PDF receipts, article catalogue files and calendar files of standing orders are created only on your device; they are not encrypted. You are responsible for files you save (section 4).

2.14 Find merchants (BTC Map)

Under “Find merchants”, the wallet shows places that accept bitcoin via Lightning according to BTC Map (btcmap.org, data from OpenStreetMap). An entry is not a contractual partnership with KAI-Pay. Data is only requested when you search, directly from the wallet or app at api.btcmap.org. BTC Map receives your IP address, the time, the identifier of your browser or the app (user agent, in the Android app including the device model) and, via the origin header, the information that the request comes from the KAI-Pay wallet.

Before use, the wallet shows what is sent to BTC Map in a note below the “Near me” button, with a link to this section. With “Near me”, the wallet asks for your location, in the app “KAI-Pay Beta” only for your approximate location. Only an area rounded to a 0.1-degree grid (in Germany about 11 × 7 km) goes to BTC Map, the same one during a session as long as you stay nearby; the wallet computes the exact distance on your device. Your exact location is neither transmitted nor stored. With the place search, BTC Map receives the search term and the chosen area. The wallet does not keep the results beyond the session, not even in the browser cache. “Report outdated”, “Add your own business”, “View in OpenStreetMap” and a place’s website only open in your browser when you click.

Legal basis: Article 6(1)(b) GDPR (function you requested); access to the location on the device under section 25(2) no. 2 TDDDG, because it is strictly necessary for the “Near me” search you expressly requested.

2.15 Donations

Under “Donate”, the wallet shows organisations recognised as charitable in their home country; KAI-Pay compiles the list itself, without any partnership with the organisations. A donation is a payment directly from your wallet to the organisation via the normal send flow (2.3, 2.4). KAI-Pay holds nothing and receives nothing from it; if the security alert is switched on, the notice about the payment (amount, invoice) reaches our push server as for every sent payment (2.9).

Before a Lightning donation, the wallet queries the organisation’s Lightning address on its server and checks – also in the send flow itself – that it matches the reviewed entry. This server receives your IP address, the time and the identifier of your browser or the app, and from the preview in the send flow on also the amount. Links to the donation page or register (IRS, German register of donation recipients) open in your browser. On your device, the wallet stores for each organisation the receiving details last seen and, after a donation, the receiving node, to alert you to changes (section 3). Only the organisation can issue a donation receipt; you provide the details needed for it yourself. A donation may reveal a political or philosophical view; the organisation or its payment service learns of it and – as with every payment – the payment service providers named in section 6.

Legal basis: Article 6(1)(b) GDPR (payment you initiate).

2.16 Paying L402 services

If you paste an L402 challenge under “Send” (content of the header “WWW-Authenticate: L402 macaroon=…, invoice=…”), the wallet only pays its invoice like any Lightning payment (2.3), and only if the invoice matches the access (macaroon). The wallet does not call the service itself and reports nothing back to it; the exception is the timestamp from KAI Oracle (2.21). So that the access proof can be shown again later, it stores the macaroon with the payment reference on this device (section 3); it does not leave the device.

Legal basis: Article 6(1)(b) GDPR.

2.17 Standing orders

Under “Standing orders” you can plan recurring payments: recipient (Lightning address or LNURL), amount in sat or in a national currency, and schedule. The wallet stores the plans and the list of executed, pending or skipped due dates only on your device (section 3); no server of ours knows your plans or pays for you.

When you create a plan, the wallet already checks the recipient (“Check and save”): the recipient’s server receives your IP address and the time, but no amount yet. When a payment is due, the wallet shows it when you open it; nothing is paid until you confirm, via the normal send flow (2.3, 2.4) – as with every payment to a Lightning address, the recipient’s server receives your IP address, the time and the amount. For amounts in a national currency, the wallet uses the rate it fetches anyway (2.7). For each execution it remembers the amount, the rate where applicable and the recipient’s server, so it can alert you to a rate jump or a change of server.

“Add to calendar” creates a calendar file (.ics) with name and amount, without the recipient, only on your device. The name may reveal the recipient if you choose it that way. What your calendar does with the file, such as syncing it via a cloud service, is up to you; the file is a copy – pausing or deleting in the wallet does not change your calendar.

Legal basis: Article 6(1)(b) GDPR (payments you set up and confirm); storage on the device under Section 25(2) No. 2 TDDDG.

2.18 Buy bitcoin: external link to Strike

Under “Buy bitcoin”, KAI-Pay lets you open the external bitcoin purchase provider Strike. The purchase link function does not automatically transmit any wallet address, Lightning invoice, wallet keys or purchase orders to Strike. The link contains no KAI-Pay identifier and opens without a referrer in your browser; in the Android app possibly in Strike’s app, which can then tell that KAI-Pay launched it. Links to the ESMA register and to Strike’s cost, terms and privacy pages also open in your browser.

When the external website opens, your browser connects to Strike. In particular, your IP address and technical browser information may be processed. Strike is independently responsible under data protection law for account opening, identity checks and purchase processing there; according to Strike’s privacy policy, for users in the EU these are Zap (Strike) Europe Limited (Malta) and Zap Solutions Holdings, Inc. (USA) as joint controllers; for additional services another Strike group company (Zap Solutions Cayman Ltd.) may be added. Details, including transfers to third countries, can be found there.

If you enter a receiving address or Lightning invoice at Strike yourself, Strike can link this information to your customer account and your transaction. The purchase via Strike is therefore not anonymous. Never enter your recovery words (the 12 words) or private keys at the purchase provider; they are not needed for buying bitcoin or for payout. The receipt of the purchased bitcoin in your wallet is an ordinary payment (2.3).

Emergency switch: when you open “Buy bitcoin” and whenever you return to the app, the wallet asks app.kai-pay.net whether the link is currently switched on; without an answer it shows no link. This lets us switch the link off for all versions if the provider has a disruption, the link target changes or for security reasons. The request contains no wallet data, no cookies and no referrer. Like every request to our servers, Cloudflare processes it with the IP address, time, browser or app identifier and language (section 6) – and thus also the fact that “Buy bitcoin” was opened. We keep no logs of it.

Legal basis: Article 6(1)(b) GDPR (function you open); for the emergency switch Article 6(1)(f) GDPR (legitimate interest in not showing a disrupted or altered purchase link). Strike’s own legal bases apply to processing at Strike.

2.19 Notification to your shop (Connect a service)

Under “Connect a service” you can enter an internet address of your shop or system (https only). The wallet registers a webhook for it with the Spark service provider Lightspark (2.3). Lightspark then sends a notification to this address for every incoming Lightning payment to this wallet – including the amount, time, status, the proof of payment (preimage) and the wallet’s public Spark identity key, also for payments that have nothing to do with the shop. Every notification is signed with a secret that the wallet shows once during setup and does not store; Lightspark knows it because Lightspark signs the notifications, and receives your shop’s address for this.

Our server is not involved and does not receive the notifications. The operator of the server at the address you enter is responsible for its processing. The registration applies to the wallet (all devices with the same recovery words) and remains until you remove it under “Connect a service”; “Remove wallet from this device” does not remove it (section 4). The payment link and button under “Connect a service” lead to the payment page (2.5).

Legal basis: Article 6(1)(b) GDPR.

2.20 Reserve on BitBox

Under “Reserve (BitBox)” you can enter the public account key of a Bitcoin account on your BitBox (zpub or descriptor from the BitBoxApp, with root fingerprint and path). From it, the wallet calculates the addresses of this account on your device to check that destination addresses belong to your BitBox. The key, the check and your transfers to the reserve stay encrypted on your device (section 3); the wallet sends them to no one, including us. KAI-Pay does not connect to the BitBox.

A transfer to the reserve is a withdrawal via the Bitcoin blockchain: as with any withdrawal, the Spark operators and Lightspark receive the destination address, amount and fee (2.3), and the transaction is publicly visible on the Bitcoin blockchain (section 4). The SDK retrieves fee rates from mempool.space. The public account key cannot move money, but it reveals all addresses and movements of the account – do not share it.

Legal basis: Article 6(1)(b) GDPR.

2.21 Timestamps from KAI Oracle

With the “Timestamp” button, a company registered with KAI Oracle buys a timestamp for a file in the wallet. The file stays on your device; the wallet only calculates its fingerprint (SHA-256). For this function – unlike paying a pasted L402 challenge (2.16) – the wallet talks directly to KAI Oracle (kai-oracle.com, Formsys GmbH): when getting the offer it sends the fingerprint and your access code (as a header, never in the address), after payment the fingerprint with the payment’s access proof (macaroon and preimage), and when fetching status, proof and receipt only the access proof. KAI Oracle also sees your IP address. The wallet pays the invoice like any Lightning payment (2.3) and only to the confirmed KAI Oracle node. What KAI Oracle does with this data (order, receipt, exchange-rate record, retention) is governed by KAI Oracle’s framework agreement and privacy notice on kai-oracle.com.

The wallet stores the access code on this device, encrypted with a key derived from your words, and never shows it again. It also keeps the order with file name, fingerprint, status, proof (.ots) and receipt only on this device (section 3); KAI Oracle does not learn the file name.

Legal basis: Article 6(1)(b) GDPR.

3. Devices, permissions and connections

Wi-Fi and mobile networks transmit data; network operators may process connection data independently. KAI-Pay only uses location data if you tap “Near me” under “Find merchants” (2.14).

The wallet requests browser permissions only when you start the relevant function. Purpose, scope and alternative:

Camera: only for scanning QR codes. The image is analysed in your browser and not transmitted. Alternative: paste the payment request.
Clipboard: read only when you tap “Paste”. Alternative: enter it by hand.
Notifications: only if you switch on notifications (2.9). Alternative: check incoming payments in the open wallet.
Passkey and fingerprint: only if you create a passkey wallet or set up fingerprint unlock (2.8). Alternative: 12 words and PIN.
Files: saving and opening only through the dialog of your browser or operating system, when you start an export, the emergency package, the watch extract or the import of the emergency package (2.13).
Location: only if you tap “Near me” under “Find merchants”; only a rounded area goes to BTC Map (2.14). Alternative: place search.

In the app “KAI-Pay Beta”, Android asks for the camera permission, from version 0.5.0 for your approximate location with “Near me” and, if you switch on notifications, on Android 13 and later for the notification permission. In the app “KAI-Pay”, Chrome asks as it does for the web app; on Android 13 and later the app also asks for the notification permission (2.11).

An operating-system or browser permission does not automatically replace legally required privacy consent.

Storage on your device

We do not set cookies. The website kai-pay.net stores no information about you on your device; your browser may merely cache its files. The wallet and the point of sale store the following in your browser’s storage (localStorage, IndexedDB and cache storage):

Vault (wallet): Your recovery words, encrypted (AES-GCM, 256 bits) with a key from your PIN (PBKDF2 with 600,000 iterations) and/or from your passkey for fingerprint unlock. For passkey wallets only a marker with the passkey’s identifier, no words. Level of protection: the 6-digit PIN only protects against guessing in the app, which enforces growing waiting times after five failed attempts. Anyone with a copy of the site data or device storage can try out a PIN-protected vault outside the app within a short time. This guessing is ruled out only with fingerprint unlock without a PIN fallback (“Remove PIN fallback” in the web app). In the app “KAI-Pay Beta” the PIN remains mandatory; its app data is excluded from cloud and adb backups (below).
Check value of the words (wallet): A random value and a check value of your recovery words derived from it with PBKDF2 (SHA-256), so that when you set a new PIN (“Forgot your PIN?”) the wallet can check that the words entered belong to this wallet. Randomly generated words cannot be computed from the check value.
Previous vault (wallet): Only if you set a new PIN with words whose link to this wallet the device could not check: the previous encrypted vault, so that you can bring back the previous wallet with its old PIN.
Failed PIN attempts (wallet): Number of failed attempts and waiting time until the next attempt.
Settings (wallet): Language, unit, currency, appearance, whether you have confirmed the backup of your words and whether you have switched private mode off.
Contact changes (wallet): The last seen Lightning address per contact and the time of a change, so that the wallet warns about changed addresses for 24 hours.
Unresolved send attempts (wallet): Recipient, amount, fee, time, idempotency key and, where available, payment identifier of a payment whose outcome is not yet certain, so that the wallet warns before an accidental second payment. The entry disappears once the activity list shows the final state or you remove it after checking, at the latest after 7 days.
Refund notes (wallet): For a refunded till payment: its payment identifier, the receipt number, the amount, the time, the idempotency key of the refund attempt and – once known – the payment identifier of the refund, so that it is not refunded twice. If the refund attempt fails, the wallet removes the note automatically – immediately, or once the activity list shows an already linked refund as failed. Otherwise it remains until you remove the wallet from this device. You can also deliberately delete an open note (the outcome of the refund is unknown and no payment identifier of the refund is available) after checking the activity list.
Push entry (wallet): Only with notifications switched on: identifier, webhook secret, webhook identifier, whether notifications show the amount and, if you switched it off, that the security alert is off; where applicable, a marker that an unsubscribe still has to be completed. In addition, for a few minutes, the identifiers of remaining registrations the wallet has noted for the second check. In the app “KAI-Pay Beta”, the app’s storage additionally holds the key pair for notifications (the private part encrypted with a key in the Android Keystore); it is deleted when you switch notifications off.
Proposal sources (wallet): Name, public key and identifier of each payment-proposal source you have set up, the allowed recipients (Lightning addresses, domains, Bitcoin addresses), whether invoices are allowed, daily and monthly budget and the time of setup. They remain until you remove the source or the wallet from this device.
Budget ledger of payment proposals (wallet): For each confirmed proposal: its identifier, the source, amount including fee, time, idempotency key and whether the payment is booked. This serves the budget and prevents the same proposal from being paid twice on this device. The wallet deletes entries of failed payments immediately; otherwise it keeps at most the 2,000 newest entries until you remove the wallet from this device.
Keys of assistants you created (wallet): Identifier and private key of each assistant you created yourself under “AI budget”. They are deleted when you remove the assistant or the wallet from this device.
Reserve (wallet): Only if you set up a reserve (2.20): the public account key of your BitBox with fingerprint and path, the name you chose, the time of setup and of the check together with the address compared and its number, and for each transfer to the reserve the amount, fee, speed, destination address and its number, time, idempotency key, payment ID and outcome (at most the 200 most recent). All of it encrypted with a key derived from your words. Deleted when you remove the reserve or the wallet from this device.
Emergency package record (wallet): Time of the last export, whether saving was confirmed, whether the package is considered out of date, a check value of the exit data and a binding value that links the record to this wallet without storing its identifier. The wallet does not store the package itself.
Address update (wallet): The time of the last attempt to switch the description of an older Lightning address to the neutral text (2.5); deleted after success.
Wallet database (wallet): Breez SDK data such as payment history, contacts, wallet state and the exit data for a unilateral exit.
App files (wallet): Program files so that the wallet starts quickly and also without a network connection (service worker). They contain no information about you.
Merchant address (point of sale): The Lightning address for which payments are collected.
Receipt key (point of sale): The wallet’s public receipt key from the point-of-sale link, which the point of sale uses to encrypt till notes (2.10). It is not secret.
Till and receipt counter (point of sale): Random device identifier, till name and consecutive receipt number.
Recent invoices (point of sale): Amount, amount in national currency with currency, rate, rate source and rate time, for articles the lines (name, quantity, unit price, tax rate), merchant address, invoice and its payment reference (payment hash), verification identifier, receipt number, device identifier and till name, the note sent to breez.tips with the invoice (encrypted or, without a receipt key, in plain text), times and payment status of at most the 20 most recent invoices from the past 7 days, so that an open invoice can be resumed after reloading, a cancelled invoice that was paid after all is detected and a receipt can be created as PDF.
Article catalogue (point of sale): Name, price, price currency, category and tax rate of the articles you create in the point of sale or take over from a catalogue file.
Point-of-sale currency and note format (point of sale): The chosen currency for entry, only if it is not euro, and a marker from the point-of-sale link whether the wallet can read lines and other currencies in the till note.
Article catalogue (wallet): An article catalogue of the point of sale that you imported; the wallet only uses it to show the lines of a point-of-sale payment with names.
Donation receiving details (wallet): For each donation organisation, the Lightning address or donation page last seen, where applicable the time of a change and, after a donation, the receiving node (public key) – for the alert on a change (2.15).
L402 accesses (wallet): For each L402 payment, the service’s macaroon (access data with its conditions, such as scope and expiry), the payment reference (payment hash), where applicable the name of a known service and the time – so that the access proof can be shown again (2.16). At most the 200 newest entries.
Standing orders (wallet): For each plan the name, recipient, amount (sat or national currency), schedule, start and end, “not before” (day of creation or resumption) and whether it is paused; for each due date whether it is recorded, pending, paid (with payment ID and the paid invoice) or skipped, plus amount, rate where applicable and the recipient’s server – at most 2,000 entries (2.17).
KAI Oracle access (wallet): The access code of your company registration with KAI Oracle, encrypted (AES-GCM, 256 bits) with a key derived from your words; unreadable without an unlocked wallet (2.21).
Timestamp orders (wallet): For each order the payment reference (payment hash), the file’s fingerprint and name, the time, the status and KAI Oracle’s proof (.ots) and receipt – at most the 100 most recent orders (2.21).

The wallet keeps the receipt key and other keys derived from your words, such as that of the emergency package, only in memory while it is unlocked; they are not stored.

The legal basis for storing and reading this information is section 25(2) no. 2 TDDDG, because it is strictly necessary for the function you expressly requested; for further processing, Article 6(1)(b) GDPR. There is no non-essential access to your device; we therefore do not ask for consent.

Section 4 explains what “Remove wallet from this device” deletes. At the point of sale, “Andere Adresse” (other address) removes the merchant address, the receipt key, the till and receipt counter, the recent invoices, the article catalogue, the point-of-sale currency and the note-format marker.

In the app “KAI-Pay Beta”, the wallet data listed above is stored not in the browser but in the app data on your device. The app files (service worker) are not needed; in addition there is the Keystore key for fingerprint unlock (2.11). The app data is excluded from Android cloud backups, from adb backups and from transfer to a new device; your backup is the 12 words. You remove all app data via the Android settings (“Clear storage”) or by uninstalling the app. In the app “KAI-Pay” (Trusted Web Activity), the statements for the browser apply; deletion is via the site data of app.kai-pay.net in Chrome.

4. Removing the wallet completely

“Remove wallet from this device” (settings) acts on this device. What it deletes and what remains depends on where the data is held.

Local data on this device

Deleted are: the vault with the encrypted words or the passkey marker, a previous vault, the check value of the words, failed PIN attempts, unresolved send attempts, refund notes, contact changes, the push entry, proposal sources, keys of assistants you created and budget ledger, the emergency package record, the address update, the imported article catalogue, the standing orders with their execution records, the reserve, the KAI Oracle access code, the timestamp orders and the wallet database with payment history, contacts and exit data; in the app “KAI-Pay Beta” also the Keystore keys. The keys the app derives itself (receipt key, emergency package key) are overwritten in memory; the app releases the rest of the memory, such as the decrypted words and the keys inside the SDK, where the browser cannot guarantee overwriting. The device settings (language, unit, currency, appearance) and the app files remain; you remove them via your browser’s site data or “Clear storage” in Android.

If your browser cannot list its databases, the deletion of the wallet database cannot be checked; the app then says so and recommends deleting the site data. The app deletes leftover wallet databases on the next start without a wallet, provided the browser can list them.

Without your 12 words, or for a passkey wallet alternatively the passkey, the balance is then no longer accessible. If the Spark operators fail, only an emergency package saved beforehand helps (2.13).

Data on servers

Push entry on our server. On removal, the wallet unsubscribes from notifications; our server deletes the push entry in the process. If that fails, for example without a connection, the wallet unsubscribes the entry directly with our server. If that fails too, it asks whether you want to try again or remove anyway. If you remove anyway, the entry remains until it is unsubscribed or expires after at most 400 days, earlier if the push service reports the subscription as invalid. Until then our server may receive notices of payments of this wallet (incoming and, with the security alert, sent) and, depending on the amount option, evaluate them. On request via kontakt@kai-pay.net we delete entries we can attribute to you; because we store no names or contact details, this is usually not possible without the entry’s identifier.

Webhook at Lightspark. The webhook registrations are held by Lightspark and belong to your wallet. Only the wallet itself can remove them, when unsubscribing from notifications; we have no access to them. If they remain, Lightspark keeps sending notices of payments to our server; without a push entry, our server rejects them without evaluating them. If you open the same wallet again later in the web app or the app “KAI-Pay”, it removes such remaining registrations itself when unlocking (2.9). In the app “KAI-Pay Beta” you can remove such registrations yourself under Settings → Notifications.

At other providers. The registration of your Lightning address at breez.tips, the encrypted records at Breez’s synchronisation service, the data of your transfers at the Spark operators and Lightspark including the private-mode setting, for passkey wallets the label on the Nostr relays, and your passkey at your passkey provider remain. Notifications to your shop (2.19) likewise remain registered at Lightspark until you remove them in a wallet with the same words. This data is held by the respective providers (section 6); we cannot delete it. The wallet does not currently offer deleting the Lightning address. You can request erasure and access from these providers under their terms.

Elsewhere at our end. We store no further data about your wallet: payment pages and the point of sale create no records on our server, and short-lived markers and daily counters expire after at most 24 hours.

Backups

The app does not delete what you have backed up yourself: emergency package files, watch extracts, CSV exports, words you wrote down and your own photos of them. These backups are in your hands; destroy them yourself when you no longer need them. Backups made by your operating system or browser, such as a backup of your computer or of the browser profile, may contain a copy of the wallet data, including the encrypted vault. A PIN-protected vault can be attacked there outside the app (section 3). The app cannot reach such backups. In the app “KAI-Pay Beta”, the app data is excluded from Android cloud backups, adb backups and transfer to a new device.

Public blockchain traces

Deposits and withdrawals via the Bitcoin blockchain, that is deposits to your Bitcoin addresses, withdrawals to Bitcoin addresses and a unilateral exit, are permanently public. Nobody can delete them, including us. Lightning and Spark payments are not recorded on the Bitcoin blockchain; they remain stored at the providers and counterparties involved. With private mode switched off, public Spark indexers may show your wallet’s balance and Bitcoin payments.

5. Wallet and network data, encryption and anonymity

We do not transmit seeds (recovery words) or private keys to our servers. Public addresses, transaction identifiers and metadata may still be personal data. Public blockchain records are ordinarily persistently accessible to third parties and cannot technically be erased by us. This does not remove duties to minimise data, assess lawful processing or erase data within our control.

Do not place names, contact details or confidential content in public transaction fields, invoice notes or the name of your Lightning address.

The Spark operators take part in transfers in the Spark network and process the data listed in 2.3 for this purpose.

Encryption is not anonymity. Where KAI-Pay encrypts – vault, till note, synchronisation, notifications, emergency package – this protects the content. The watch extract is deliberately unencrypted (2.13). The fact that a payment was made, its amount, its time and the counterparties involved remain visible to those involved in a payment: to payer and recipient, the Spark operators and Lightspark, for Lightning addresses the LNURL server such as breez.tips, and for payments via the Bitcoin blockchain to everyone. The services contacted see the IP address and time of your connections. Private mode (2.3) only hides your wallet from public Spark indexers.

Tor. You can hide your IP address by routing the connections through the Tor network, for example with Tor Browser or, on Android, with Orbot in VPN mode; we have not yet checked this in detail for the apps. We do not block connections from the Tor network; we check this weekly for kai-pay.net. We do not run an .onion address of our own. Cloudflare may on its own offer Tor Browser users a connection via the onion network; the setting for this is switched on for our domains, but we have not verified whether Cloudflare actually offers it. Tor hides your IP address, not what the services involved see about your payments.

Who sees what? The page “Who sees what?” in the wallet (“Settings” → “Privacy”) shows for each service involved when it sees what, what it does not see and what happens if it fails. It summarises the information in this policy.

6. Recipients, international transfers and sources

The overview below identifies each recipient’s task, data categories, processing country and legal basis, and its provider and role where these are established. Processors act under contractual instructions; independent providers issue their own information. EU hosting alone does not exclude third-country access.

Cloudflare

Provider: Cloudflare, Inc., USA.
Task: Hosting and delivery of kai-pay.net, app.kai-pay.net, kasse.kai-pay.net and the forwarding domains; running our server programs; storage for push entries and, where applicable, diagnostic events; cache for short-lived markers and daily counters; request limiting; email forwarding for messages to our contact address (section 1).
Data categories: Connection data (2.1, 2.2), payment page requests (2.5), push entries, webhook messages, short-lived markers, daily counters and diagnostic events (2.9).
Role: Processor under Cloudflare’s data processing addendum.
Country and safeguards: USA and a worldwide server network. Cloudflare states that it is certified under the EU-U.S. Data Privacy Framework, for which an adequacy decision of the European Commission exists. For transfers not covered by it, Cloudflare’s data processing addendum provides for EU standard contractual clauses; it is publicly available. You can also obtain a copy of the safeguards via kontakt@kai-pay.net.
Legal basis: Depending on the purpose, see 2.1, 2.2, 2.5, 2.9 and 2.10.
Information: Cloudflare privacy policy, Cloudflare sub-processors.

Breez

Provider: Breez, provider of the Breez SDK.
Task: Spark operator; signing the app in to Breez services; exchange rates; synchronisation of contacts and payment details; LNURL server breez.tips for Lightning addresses (including the query on every wallet start), invoices and payment status (wallet, point of sale, payment page); Nostr relay for passkey wallets.
Data categories: IP address and time; data of transfers in the Spark network (2.3); the wallet’s public key (2.5); encrypted synchronisation data (2.6); name and description of the Lightning address, amounts, notes, till notes encrypted or in plain text, invoices and payment status (2.5, 2.10); label of passkey wallets (2.8).
Role: As a Spark operator, Breez acts independently. Breez provides the other services as provider of the SDK.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR; when payers open a payment page, Article 6(1)(f) GDPR (2.5).
Information: Breez privacy notice.

Lightspark

Provider: Lightspark Group, Inc.; headquartered in the USA according to its own information.
Task: Spark operator; Spark service provider for Lightning payments, deposits and withdrawals via the Bitcoin blockchain and the technical splitting of the balance (2.3); sending messages about incoming and, with the security alert, sent payments if you use notifications; sending notifications to your shop if you set them up (2.19).
Data categories: IP address and time; data of transfers, Lightning payments, deposits and withdrawals (2.3); the webhook addresses of our server registered for your wallet and the related webhook secret (2.9); for notifications to your shop, its address and the related secret (2.19).
Role: As a Spark operator, Lightspark acts independently. Lightspark provides the other services as their provider.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR.
Information: Lightspark privacy policy.

Flashnet

Task: Spark operator; interface api.flashnet.xyz for token conversions, to which the SDK signs in on every wallet start in order to reconcile token conversions that can be reclaimed. KAI-Pay offers no conversions; the sign-in cannot be switched off in the SDK (2.3).
Data categories: IP address and time; data of transfers in the Spark network (2.3); at api.flashnet.xyz, the wallet’s public identity key with a signature over a sign-in challenge.
Role: Independent controller.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR; for the query at api.flashnet.xyz, Article 6(1)(f) GDPR (2.3).
Information: Flashnet privacy policy.

mempool.space

Task: Bitcoin blockchain queries for the wallet (deposit addresses, transactions, fee estimates); exchange rates for the point of sale.
Data categories: IP address and time; Bitcoin addresses and transactions queried. Using IP address and time, the service can link the addresses your wallet queries to each other.
Role: Independent controller.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR.
Information: mempool.space privacy policy.

Cloudflare DNS service

Provider: Cloudflare, Inc., public DNS service 1.1.1.1.
Task: DNS lookup of Bitcoin payment instructions (BIP 353) when checking addresses of the form name@domain (2.4).
Data categories: IP address, name queried and time.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR.
Information: Privacy commitments for the 1.1.1.1 DNS service.

BTC Map

Task: Directory of places that accept bitcoin (data from OpenStreetMap), for “Find merchants” (2.14).
Data categories: IP address, time, user agent, origin; with “Near me” a rounded area, with the place search the search term.
Provider and country: BTC Map (btcmap.org), a community project. BTC Map does not name its operator, seat or server location; a transfer to a third country therefore cannot be ruled out.
Legal basis: Article 6(1)(b) GDPR.

Donation organisations

Task: Querying the Lightning address before a donation and receiving the donation (2.15).
Data categories: IP address, time, user agent, origin; from the preview in the send flow on, the amount.
Provider and country: The organisation you choose or its payment service; country according to the entry in the list (e.g. USA).
Legal basis: Article 6(1)(b) GDPR.

Strike (external purchase provider)

Task: Only if you open the link under “Buy bitcoin”: Strike’s website or app with account, identity check, purchase and payout (2.18). Strike is independently responsible; we transmit nothing to Strike.
Data categories: When opened, IP address, time, browser or app identifier; everything else you give Strike yourself.
Provider and country: Zap (Strike) Europe Limited, Malta (EU), jointly with Zap Solutions Holdings, Inc., USA; for additional services possibly Zap Solutions Cayman Ltd. Strike is responsible for transfers to third countries.
Legal basis: For opening the link Article 6(1)(b) GDPR; for processing at Strike its own legal bases.

Payment recipients’ servers

Task: Payment details and invoices for Lightning addresses and LNURL links of other providers; payment details for QR codes of certain merchant payment systems via cryptoqr.net (2.4).
Data categories: IP address, time, address queried, amount and, where applicable, a comment, with the web app the origin app.kai-pay.net; for a refund, where applicable, the note “Refund for receipt …” with the receipt number.
Provider and country: Determined by the payment recipient.
Legal basis: Article 6(1)(b) GDPR.

Push services of browser makers

Provider: Google, Mozilla, Apple or Microsoft, depending on your browser; in the app “KAI-Pay Beta”, Google (Firebase Cloud Messaging).
Task: Setting up the push subscription by your browser or the FCM registration by the app, and delivering notifications (2.9).
Data categories: Endpoint or FCM token, time and the encrypted message padded to a fixed length; during setup, the connection data of your browser or device. The delivery time mirrors when payments arrive.
Role: Independent controller.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR.
Information: Google, Mozilla, Apple, Microsoft.

Nostr relays

Provider: Breez (nr1.breez.technology) and the operators of the public relays relay.primal.net, relay.damus.io, relay.nostr.watch, relaypag.es and monitorlizard.nostr1.com.
Task: Storing and retrieving the label of passkey wallets (2.8).
Data categories: Public Nostr message containing the label, where applicable a list of the relays used, the public key derived from your passkey, IP address and time.
Country: Processing may also take place outside the EU.
Legal basis: Article 6(1)(b) GDPR.

Proposal sources

Provider: Whoever operates the source you set up in the wallet, such as the Telegram bot KAI.
Task: Creating payment proposals (2.12).
Data categories: Recipient, amount and purpose of the proposals the source itself creates. It receives nothing from your wallet.
Role: The source’s operator is responsible for the processing by the source.

KAI Oracle (Formsys GmbH)

Provider: Formsys GmbH, operator of KAI Oracle (kai-oracle.com).
Task: Timestamps for registered companies: offer, acceptance after payment, status, proof and receipt (2.21).
Data categories: The file’s fingerprint, access code, the payment’s access proof (macaroon and preimage), IP address.
Role: KAI Oracle’s framework agreement and privacy notice govern processing at KAI Oracle.
Country: Germany; the connection to kai-oracle.com runs via Cloudflare, which processes connection data such as the IP address.
Legal basis: Article 6(1)(b) GDPR.

Your shop

Provider: Whoever operates the server at the address you enter under “Connect a service” – usually you yourself or your shop provider.
Task: Receiving the notifications about incoming Lightning payments to the wallet (2.19).
Data categories: Lightspark’s notifications about every incoming Lightning payment to the wallet (2.19).
Role: The operator of this server is responsible for its processing.

GitHub

Provider: GitHub, Inc. (a Microsoft company), USA.
Task: Providing the test versions of the Android apps for download (2.11).
Data categories: Connection data when downloading; for signed-in users, their GitHub account.
Role: Independent controller.
Country: USA.
Information: GitHub privacy statement.

Google (Chrome, Android, Google Play)

Provider: Google Ireland Limited, Ireland, and Google LLC, USA.
Task: Google Chrome as the runtime of the app “KAI-Pay”; Android system WebView and biometric dialog; distribution and updates of the apps via Google Play once they are published there (2.11).
Role: Independent controller.
Country: Processing outside the EU possible.
Information: Google privacy policy.

Sources

We receive data from third parties in two cases only: messages from the Spark service provider Lightspark about incoming and, with the security alert, sent payments (2.9), and invoices and payment status from breez.tips for the payment page (2.5). Payment proposals (2.12) and till notes (2.10) do not pass through our servers.

7. Your rights and complaints

Subject to statutory conditions, you may request access, rectification, erasure, restriction and portability. Consent may be withdrawn for the future without affecting previous lawfulness. You may object to legitimate-interest processing on grounds relating to your situation, and to direct marketing at any time. Contact: kontakt@kai-pay.net.

You may complain to a supervisory authority, particularly where you live, work or consider a breach occurred. Our competent authority is Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), Postfach 20 04 44, 40102 Düsseldorf, www.ldi.nrw.de.

Identity checks request only necessary and proportionate information, never a seed (your recovery words).

8. Required data, automation and changes

KAI-Pay requires no account, and you do not have to provide your name or email address. A function cannot operate without necessary connectivity or payment data. Lightning address, contacts, notifications, passkey, fingerprint, AI payment proposals, the emergency package, find merchants, donations, L402 payments, timestamps and NFC are optional; the wallet can be used without them. You can switch private mode off.

We make no solely automated decision with legal or similarly significant effects. Checking payment proposals against your rules (2.12) takes place on your device and only prepares a payment that you confirm yourself. If profiling or blocking with such effects is introduced, we will first add the legal basis, understandable logic, effects and required safeguards. Material processing changes are communicated before they begin; fresh consent is obtained where needed.