Privacy Policy
Who is responsible
Dr.-Ing. Stefan Hoppe, Merzstr. 7a, 92224 Amberg, Germany. Email: support@taptopayonphone.app.
This policy covers the App, its supporting service, and this website. It explains the information we process when providing the App. Stripe and Apple also process information to provide their respective services; their own privacy policies explain that processing in detail.
Connecting a Stripe account
Stripe handles account sign-in and authorization through Stripe Connect with read and write access. Our service exchanges the authorization code with Stripe and issues an App session token. Cloudflare D1 stores the connected Stripe account ID, the App token hash and token-generation material, creation time and App fee terms. We do not store your Stripe password or Stripe OAuth access token in D1. Our service retrieves the connected account from Stripe to check access and return its ID, country and stored App fee terms to the App; it does not copy the full profile or identity documents into D1. Connect access nevertheless allows our platform to access information made available by Stripe. The App caches its fee terms locally, separately for each connected account and payment mode, and clears this cache on logout.
A random App installation identifier is used for sign-in, team access and payment-notification routing. It is not an advertising identifier. Sign-in state is valid for thirty minutes, and the installation-bound exchange code for five minutes. D1 stores the state and installation ID, and the exchange-code hash with the account and installation IDs. Used states are removed during the callback; expired records are cleared on new sign-in starts and by a scheduled daily cleanup. Expiry prevents use but does not mean immediate physical deletion.
Team Access
The account owner creates a staff access name. Team members can scan the invitation QR code on the owner’s device, or the owner can send the invitation by email. Earlier app versions can share the link through the device share sheet. Invitation links contain the access name and invitation token. For email delivery, our service passes the recipient address and invitation message to Cloudflare Email Service. D1 stores the access name, Stripe account ID, status, invitation hash and generation material, activation and creation dates, and the active installation ID, session ID and session-token hash. Access names can contain personal information.
Each staff entry has one active session. An activated link can be used again on the same installation. To move access to a different installation, the owner deletes the entry and creates a new one with a new link. Links have no time-based expiry in the current implementation. The owner can view access names, status and the active installation identifier and delete an entry to revoke access. Team members can create, view, edit and delete customers on the connected Stripe account, accept payments, create and view payment links, select existing Terminal locations, and retrieve receipts for their own connection. Account-wide Payments and Payouts, link deactivation and Terminal-location changes are restricted to the owner. Stripe supplies the available account-wide payment, payout and reporting views.
Customers and Terminal locations
The App lets the owner and team members manage customer names, email addresses, telephone numbers and postal addresses. Customer descriptions can also be returned from Stripe, and the service accepts a description when creating a customer. These details pass through our Cloudflare Worker to and from Stripe, where the customer record is stored on the connected account. We do not maintain a customer database in D1. A selected customer ID can be attached to a payment. Deleting a customer sends a deletion request to Stripe; it does not erase existing payment records or all information Stripe must retain.
Terminal-location names and postal addresses also pass through the Worker and are stored at Stripe. Owners can create, edit and delete locations. Team members can select existing locations; the service returns their identifier, name and country without the full address. Default location selections are saved on the device.
Payments and payment links
The App sends the total amount including any tip, currency, base amount, tip amount, optional note and customer ID, and request, connection and installation identifiers to our service. The Worker creates payments on the connected Stripe account. Stripe stores the payment, App fee, note as a description, and routing and base/tip metadata. A connection ID can link a payment to a team member, and the installation ID identifies the initiating App installation. Stripe SDKs handle card entry, reader transactions and Tap to Pay. Our server does not receive full card numbers or security codes.
For payment links, the service sends Stripe the amount, currency, optional description and routing metadata. Links created by the App have no limit on the number of completed checkouts and remain reusable while active. The description can appear as the payment description and product name on Stripe-hosted Checkout. Customers enter their details on Stripe’s page, where collection of their name and email is enabled. Selecting a customer in the App can prefill the email recipient for a link. Stripe holds the link, Checkout and resulting payment records. Link URLs and locally generated QR codes can be shared with the recipient and service you choose.
The Worker processes requests and Stripe responses temporarily; D1 does not contain a separate customer or financial transaction history. It does hold the operational payment-notification records described below. Information stored at Stripe remains accessible to our platform through its Connect permissions. Stripe's own retention and processing are described in Stripe's Privacy Policy.
Payment history and receipts
The account owner can open Stripe’s embedded Payments and Payouts views in the App. Our service authenticates the App session and requests a short-lived Stripe AccountSession restricted to the connected account and the selected component. The App receives its client secret and Stripe publishable key to load the component. Our service does not store these AccountSession secrets in D1; JSON responses are marked not to be cached. Stripe handles the embedded account-wide information, authentication and management actions, including payment details, refunds, captures and disputes, or balances, payout history, payout schedules, external bank accounts and eligible standard payouts. These views can include activity created outside the App. The enabled actions remain subject to Stripe’s rules and account eligibility. Stripe processes the information you enter and any records or exports it makes available in these views under its own privacy policy. Team members cannot open these account-wide components.
Our service also retrieves payment-link details and receipts from Stripe for App features, including team members’ receipts for their own connection. Checkout-status checks and receipt responses can include amounts, currency, tips, descriptions, payment status and error details, customer information, card brand and last four digits, payment identifiers and receipt URLs. The App holds loaded data for display. D1 does not store a separate financial transaction history.
Stripe hosts successful-payment receipts. For confirmed declines, our service generates a receipt page when someone opens the encrypted link. The page can show the merchant, attempted amount, currency and date. People with the link can open it while the receipt remains available. Older app versions can generate and share a temporary decline PDF on the device.
If you send a payment link or receipt by email, our service gives Cloudflare Email Service the recipient address and the message containing the link. When a customer is selected, their saved address can be prefilled for you to review and change. D1 stores the merchant account, request and payload hashes, and timestamps to prevent duplicate sends. The table contains no plaintext recipient addresses or email bodies. Scheduled cleanup removes delivery records older than seven days.
Payment notifications
To localize payment notifications, newer App versions also send the App language and device formatting region. D1 stores this locale with the device registration; older registrations use English.
With notification permission, the App registers with Apple Push Notification service (APNs) and sends the device token and delivery environment to our service. D1 associates them with the installation, Stripe account and connection IDs and a registration timestamp. Stripe webhooks trigger separate success and failure notifications routed to the installation that initiated the payment or created the payment link. The Worker uses the payment's total amount, including any tip, and currency from Stripe.
Apple receives the APNs token and notification payload: result text including amount and currency, payment and event identifiers, event and payment creation times, installation ID and test/live mode. The payload also includes the amount in Stripe minor units and the currency code. It contains no customer name, email, full card details or payment note. Notifications can display the amount on the lock screen according to your iOS settings. Banners and sound are suppressed while the App is in the foreground.
D1 notification records contain payment, account, connection, installation and event identifiers, event type, timestamps and queue, delivery and claim state. They do not contain the amount or currency, customer contact details, card details or note. Cloudflare Queues holds payment and event IDs, notification type and test/live mode for delivery and retries. Pending notifications are eligible for delivery for twenty-four hours after the event; this delivery window is not a retention guarantee.
You can disable notifications in iOS settings. When the App next synchronizes registration with a valid signed-in session and network access, it attempts to remove the registration from our service. Local logout does not remove the server registration, so pending or later results for earlier payments or payment links may still arrive while that connection remains active.
Device storage and features
The App stores its session credential in the device Keychain using this-device-only protection after the first unlock. Updated App versions store the installation identifier and review-mode preference in local preferences alongside account ID and country, merchant/team role, team access name, reader and location selections, tip preferences and onboarding state. During an upgrade, the existing installation identifier is retained and older non-credential Keychain entries are removed after migration. The identifier survives logout; a fresh installation does not reuse an identifier or review preference left in the Keychain. Older App versions can keep those settings in the Keychain until updated. The current APNs token is held in App memory and registered with our service; it is not separately saved in App preferences.
The App does not retain unfinished form or checkout requests for automatic resubmission. It attempts to remove recovery records from earlier versions on startup. Historical service recovery records may remain until the merchant record is deleted; they contain request fingerprints, identifiers, processing state and timestamps, not full customer-form payloads or card details.
The App uses device and Stripe features for reader connections, Tap to Pay and card entry, including Bluetooth, the local network, location access and supported camera-based card scanning. Our service receives no Face ID biometric data or camera images. Authentication offered by iOS or a payment provider is handled by that provider. Stripe's payment components process payment information and product-interaction data for payment functionality and analytics. The Terminal SDK also declares approximate location data for payment functionality. Stripe uses device and payment information to provide and secure its services, including fraud prevention. Our Worker does not receive raw device-location coordinates. See Stripe's mobile SDK privacy details and Apple's Privacy Policy.
Website, diagnostics and support
The website and API run on Cloudflare Workers, with operational records in D1 and push jobs in Queues. Cloudflare processes connection and request information such as IP address, time, URL, browser or device information and security metadata. The service uses hashed session tokens for authenticated rate limiting and a hash derived from the IP address for anonymous team-invitation rate limiting. These are not anonymous when they can be linked to other records.
Worker observability logs and sampled traces are enabled in the service configuration. Explicit error logs include Stripe request IDs, error types or codes, error messages and, for unexpected failures, request method and path. Request URLs can contain OAuth codes, invitation tokens, access names or resource identifiers. The App also writes device diagnostic logs about authentication, readers and payment errors, sometimes including location IDs and error details. The App has no separate upload endpoint for those device logs; operating-system and SDK diagnostics are subject to their respective services.
We use operational information to deliver and secure the service and diagnose failures. Cloudflare log, trace, queue and backup retention is governed by the applicable service plan and configuration, separately from the database cleanup periods described below. Database cleanup does not guarantee immediate removal from logs or backups. See Cloudflare's Privacy Policy and Data Processing Addendum for its processing and transfer safeguards. These providers may process information outside your country, including outside the European Economic Area.
We set no website cookies of our own and load no advertising or website analytics scripts. Cloudflare security features may use necessary cookies where enabled. We do not use App or website data for advertising or cross-app tracking. If you contact support, we process your message and contact details to respond; the code does not define a fixed retention period for support correspondence.
Retention, logout and deletion
Scheduled cleanup targets D1 payment-notification rows older than seven days from row creation and device registrations older than ninety days from their last update. Invalid APNs tokens are also removed when Apple reports them as invalid. Cleanup depends on successful execution of the scheduled service; these are deletion thresholds, not guarantees about backups or exact deletion times.
Merchant and team records have no automatic age-based deletion in the code. Deleting a team entry removes that entry and its current connection's notification and device records. On a verified Stripe deauthorization webhook, the service checks that Stripe access is no longer available before deleting the merchant and cascading deletion to associated staff, exchange-code, device and notification records. This depends on successful webhook delivery and processing; it does not delete Stripe's payment or customer records, Apple records or already queued job identifiers.
Log Out removes the device's session credential, resets account and payment settings, clears displayed and pending notifications and the shared URL cache, and starts reader disconnection. It works locally without contacting Stripe to revoke access. It retains the installation identifier and some local lifecycle flags, and does not delete the merchant or staff entry, access link, server-side push registration, or Stripe history. Uninstalling the App likewise does not request server-side deletion. Contact us to request access, correction or deletion of information under our control; for customer and payment information managed by the merchant or independently held by Stripe or Apple, the relevant merchant or provider also handles those requests.
Legal basis and your rights
Where the GDPR applies, we process merchant connection, payment-request, customer-management and Team Access information to provide the service requested by the merchant (Article 6(1)(b) GDPR). We process operational security data and support correspondence for our legitimate interests in running and protecting the service and responding to enquiries (Article 6(1)(f) GDPR). Merchants determine which customer details they enter and how they use them for their business, and are responsible for the lawful basis and privacy information for their customers. Legal obligations may require additional retention or disclosure (Article 6(1)(c) GDPR).
Subject to applicable conditions, you may request access, correction, deletion, restriction, portability, or object to processing. You may complain to a data protection authority, including the Bavarian Data Protection Authority. Contact us at support@taptopayonphone.app. For data Stripe or Apple controls independently, use their privacy channels.