IntelliVision ivb.app

IntelliVision Business — Native Android Privacy Policy

Effective date: 30 October 2026

This notice covers IntelliVision Business, the native Android beta with package name com.intellivision.nativeapp, version 0.3.0-camera-beta. Its device label is IVB Business Beta. The app is published by Zaxx. Privacy and support contact: zaxx.im@gmail.com. Identify the native Android app when contacting us. Do not send passwords, pairing secrets, backup passphrases or unredacted customer records by email.

The IVB website, other IVB apps, independently operated shop hosts and services you choose may have different data practices. This native beta does not automatically import the IVB web app's records. The beta label does not mean all IVB web features are implemented or accepted for client operations.

Sample businesses

Explore sample businesses is available to every user without creating an account, making a payment or starting a trial. Choosing an industry creates or opens fictional records in a separate local sample profile, with two branches and public practice logins. The SAMPLE banner identifies this mode. Role changes use actual sample staff accounts and ordinary role permissions; protected workspaces still require the sample owner's password. The public password is shown in Sample controls. Do not use a sample to store real customer information, confidential records or a password used anywhere else.

Sample activity changes only that sample's local records. Samples cannot pair with a shared shop, sign in to cloud, upload, sync, import or export business data, activate a licence, start a trial, connect to a payment provider or send printer output. Sample receipts are marked SAMPLE - NO REAL PAYMENT and are not tax invoices. Recurring schedules can be drafted locally but cannot create consent links or provider collections. An unavailable action explains the restriction rather than reporting a successful external operation.

Reset this sample business removes only the selected registered sample's local records and creates fresh fictional data. Other samples and real local businesses remain. Leaving sample mode does not erase it; it is available again from the chooser. Sample profile identity is not included in customer backups, and sample records cannot be restored or synchronized as a real business. A normal local business and optional cloud account are separate choices with the data practices described below.

Information in a local business

When you create a local business, the app stores its name and business type, your local username and a protected password verifier. Business settings may include an address, VAT details and branches. Owners can create local staff logins, roles and branch assignments.

Records you choose to enter may include product names, SKUs, barcodes, prices, costs and quantities; customer or supplier names, email addresses, telephone numbers, addresses and notes; sales, refunds, purchases, cash shifts, stocktakes and branch transfers. The app keeps transaction references, dates, operator identifiers and audit records so the business can review its work. Reports are calculated from those records.

Recording a completed external card or EFT transaction stores the operator's confirmation and terminal or bank reference; it does not process or independently verify that payment. If the corresponding native sale or return cannot be posted, an authorized operator can preserve its reviewed command, amount, reference and explanatory note for owner reconciliation. Owner-reported reversals and links to matching existing native records are recorded separately without creating a payment or journal entry. This evidence remains part of the business's audit history and authorized backups or sync. Enter transaction references, not card numbers or security codes.

These records are stored in the app's private storage on your device. Local setup does not create a publisher cloud account or automatically upload the business to the publisher. You can choose to print receipts, export reports or create an encrypted backup; those actions send the selected output to your chosen destination as described below. Local records are not automatically merged with a paired shop's records.

The current beta has no advertising, attribution or analytics SDK and no automatic crash-report upload. It does not sell user data or use business records for targeted advertising.

Local accounts and device security

Local passwords are stored as salted password verifiers, not plaintext passwords. The business database uses Android app-private storage; it is not a separately encrypted database. Protect the device with an Android screen lock and control who can use it.

Owner, manager, cashier, waiter, kitchen and driver permissions restrict work within the app. Owners can disable staff access, change assignments and reset a staff password. Disabling a login retains historical transaction and audit references; it does not erase historical records. Local restaurant and specialist workspace states are encrypted with Android Keystore keys. Protected education, funeral, healthcare, legal-trust and recurring-collections workspaces additionally require an owner-unlocked Privacy Vault, which locks when leaving the workspace or the app.

Optional shared-shop connections

You may pair with a shop host using the address and pairing details supplied by its operator. Pairing sends a generated pairing-device identifier, the device name you provide and the pairing code to that host. The default device name may contain your Android model; you can change it before pairing. Staff sign-in sends your username and password to the selected host for authentication. Staff passwords and active staff sessions are not persistently saved by this native client. Saved pairing credentials and operation-recovery fingerprints are protected using Android Keystore encryption.

After pairing and sign-in, the app exchanges the records and commands needed for the selected workflow, subject to the shop's staff and branch permissions. Outgoing commands include the acting staff identity, operation reference and relevant form values. The shop receives and keeps submitted business records and activity needed for its transactions, permissions, audit and recovery. Authorized staff on that shop can view shared records according to their permissions.

Depending on the workspaces your shop enables and the fields you complete, records can include:

The local restaurant and specialist tools can also store the workspace records described above. Protected local workspaces can include education, funeral, healthcare and legal-trust records entered by the business. Only enter information you are authorized to use. Allergy notes are staff-entered food-service instructions, not a diagnosis or a medical safety assessment. The app is not a medical device and does not diagnose, treat, cure or prevent a medical condition. Seek a qualified healthcare professional for medical advice. Protected shared-host workspaces remain restricted to the separately controlled host workstation; local vault access does not bypass a remote host's restrictions.

The shop operator controls its host, staff access, retention, backups, onward service integrations and deletion procedures. Ask that operator about those practices. Records sent to a shop are no longer stored only on your Android device. The publisher does not automatically receive a copy of an independently operated shop's records through the native client. If the publisher operates a demonstration or support shop that you choose to use, it is the recipient for that shop and should use synthetic test data.

Security of shared-shop transport

This version requires HTTPS for shared-shop connections. It validates the host certificate and address before sending shop requests. A publicly trusted HTTPS domain can use Android's trusted certificate authorities. A local host with a self-signed certificate requires its public-key fingerprint supplied through the trusted host screen; obtain that fingerprint directly from the shop operator. A fingerprint identifies the selected host; it does not establish that the operator is authorized to receive your business data.

Older saved HTTP connections must be upgraded to a secure host connection before this version sends staff credentials or business requests. A failed upgrade leaves the saved pairing and pending-operation references intact. HTTPS protects this app's connection to the host; it does not make the host unable to read its business records or guarantee the host's onward connections. Printer and file-output paths have separate security characteristics below.

Camera and barcode scanning

The app requests camera permission when you choose to scan a product barcode. Camera frames are decoded on the device and are not uploaded as photos or video by the current scanner. The decoded text is used as a product identifier; QR content is not automatically opened as a web link. You can decline permission and enter a barcode manually or use a compatible keyboard scanner.

Printers and device connections

Optional local security cameras and recorders (0.3.0 candidate)

If you configure CCTV, the app can discover ONVIF devices on your current Wi-Fi and connect directly to the private IPv4 camera/recorder you choose. It sends that device the camera account you provide, service/control requests and channel selections. Video is decoded locally for the foreground view and is not uploaded to IVB, included in business/cloud exports, or recorded to a video file by this module. Discovery does not send passwords. CCTV is separate from the phone barcode scanner.

Camera addresses and credentials are stored in a branch-scoped encrypted Android Keystore-backed file excluded from Android backup and IVB business backup/sync. Removing a device deletes its saved configuration from this installation, not recordings on the recorder. Owner/manager access follows the selected business/branch and Vision plan access; leaving the screen, changing scope or backgrounding stops playback. Configure other Android installations separately.

Local HTTP ONVIF, RTSP and DVRIP camera connections are not encrypted. Their use requires an explicit trusted-LAN acknowledgement. Use a secured camera network and actual authorized camera credentials. HTTPS camera endpoints use normal certificate validation or an explicit fingerprint obtained from the device. The app does not guess default passwords, recover camera accounts or sign into vendor P2P/cloud services. Optional PTZ commands move the selected camera; archive requests query only device-advertised services. No facial recognition, person detection or AI analysis is performed by this CCTV module.

You can select a compatible printer through Android printing, an already-paired Bluetooth connection, an authorized USB printer connection or a private-network printer address. Nearby-device or USB permission is requested where Android requires it. The selected service or printer receives the receipt or document you choose to print.

Receipt output includes business details, sale references and dates, operator username, item descriptions, quantities, amounts and available payment/tender/change details. The native receipt renderer does not add staff passwords, full customer contact records or restaurant allergy notes to those receipts.

Direct network ESC/POS printing uses raw TCP and is not encrypted by this app. Bluetooth, USB and Android print services have their own transport and device properties; this notice does not promise every print path is encrypted. Select a printer you control on an appropriately secured setup and inspect the output before sending it. A print service you select may use its own network or cloud service under its own terms. The shop's HTTPS connection does not encrypt a separate direct printer connection.

The app does not access the device's contacts list, microphone, SMS, call history or automatic precise location. Manually entered location and contact records are distinct from those Android permissions.

Backups, exports and destinations you choose

Native backup exports contain the selected local business's records, settings, staff assignments and protected password-verifier information. The archive is encrypted with a separate passphrase you choose. The publisher and document provider do not receive that passphrase through the app and cannot recover it for you. Keep it separate from the backup file.

CSV reports, PDF output and receipts are not encrypted native backups. CSV report exports contain the displayed report's business/branch references, dates and financial totals. You decide where to save or print the output through Android's document picker, printing interface or the selected printer. A document or print provider you choose may send or store it in its own cloud service under its own privacy terms. Check the destination before saving business records.

Automatic Android app backup and automatic device-transfer backup are disabled for this beta. Restoring a native backup creates a separate local business; it does not merge existing web or host records. Exported files remain subject to the destination's access, retention and deletion controls.

Optional IVB cloud backups and device sync

Cloud is optional. Local business work does not require signing in to cloud. If you activate or sign in to an IVB cloud account, the app sends your account email and a password-derived authentication proof over HTTPS to https://ivb.app/api/cloud-backup. The service stores an account identifier, a protected verifier, hashed sessions and invitation records. The cloud password and business decryption keys remain in memory on the device while that cloud session is unlocked; closing its workspace or leaving the app clears them. Recurring collections can use a separately opened session with the same cloud account.

An owner can explicitly upload an encrypted native archive. It includes business records, branches, staff password verifiers and specialist records included in the export. The app encrypts it before transmission with a password-derived key. The hosting service receives encrypted bytes, archive identifiers, version numbers, integrity hashes, sizes and times. It does not receive the archive decryption key. Native and web archives use separate formats and namespaces. Restoring a native archive creates a separate local business.

Device sync is a separate, optional action. It exchanges encrypted native business replicas using stable business identities. Another device signed in to the same cloud account can join a replica and then authenticate using its local business credentials. Authorized users of that device can view records according to their roles. Changes to the same record on different devices stop for reconciliation rather than silently replacing either copy. Sync is manually requested; this version does not continuously upload in the background. It does not merge native records with the web app's different data format.

The device keeps an encrypted merge baseline and pending operation information in private storage so a lost response can be recovered without duplicating a sync. Native sync keeps its latest three full encrypted revisions per business; older sync ciphertext is removed after a newer revision commits. Compact original-operation receipts remain until account deletion so a device retaining its pending request can recover the exact result. Manual backup history is separate. Retained encrypted snapshots consume the account's storage allowance. Account email and archive metadata are visible to the hosting service even though business contents are encrypted. Choose a strong cloud password and keep it safely; we cannot recover encrypted business contents without it.

Subscription licences contain the business and installation identifiers, plan, device limits, expiry and issuer signature. The app stores a verified licence and a protected time/replay guard locally. Importing a licence does not charge a card or send business records to the billing provider. Installation identifiers and licence guards are not included in business backups or sync.

If an organisation has already supplied access, its owner can choose Organisation-supplied licence and sign in with an existing IVB cloud account. Cloud authentication uses the same hosted service. The app then sends the authenticated session, business and branch identifiers and Android installation identifier over HTTPS to https://ivb.app/api/native-license. The private service checks the organisation's account and business allowance before asking the IVB licence issuer for a signed, device-bound complimentary lease. This action does not purchase a subscription, start a trial or record payment. Business contents and the cloud password are not sent to the licence issuer.

The organisation service keeps its account identifier, business and installation assignments, grant/revocation requests, timestamps and audit references. The app keeps the signed lease locally; cloud credentials stay in memory and are cleared when leaving or backgrounding the licence screen. Renewal requires that screen's signed-in session. An already-issued offline lease can remain usable for up to 24 hours after revocation; hosted access is checked against current authorisation. Supplied Sandbox access cannot be changed to a live payment merchant. Account closure must confirm revocation before it reports completion; contact support if that step cannot be confirmed. Administrative grant and revocation audit records may remain for access-security and dispute review, even after account-linked access is removed.

If the owner chooses the free five-day local Medium trial, the app records its start, expiry and chosen business in device-protected storage. The trial does not create a paid subscription, collect money or supply a paid server licence. When it ends, paid local tools pause and the existing business records remain. Provider-backed services still require their own verified authorization.

Optional recurring collections and provider records

An owner can prepare a recurring-payment schedule offline. Drafts contain the customer name and email, contract or membership reference, description, amount, cadence, next collection date and customer terms. Drafts, pending submission references and cached statements are stored in the encrypted, owner-private local workspace. They may be included in an owner-authorized encrypted backup or sync replica. Preparing a draft does not authorize or take payment.

When you sign in to hosted collections and submit information, the app connects over HTTPS to https://ivb.app/api/recurring. It sends the cloud bearer session and the selected business and branch identifiers. Registration, merchant setup, schedule submission and customer consent-link creation also send the signed subscription proof and installation identifier so the server can verify authorization. A free local trial is not that proof. Existing statement access and cancellation do not require a new paid licence.

The collections service receives and stores the business name and support email; customer schedule details and terms; submission and provider-operation references; consent evidence; and provider-verified payment and allocation records. A merchant connection includes the business's Payfast merchant ID, merchant key, security passphrase and selected Live or Sandbox mode. Merchant secrets are encrypted in private server storage and are available to the service when it authenticates provider requests. They are not saved by the native app. Cloud passwords are not sent to Payfast.

Collections records are operational server records, not end-to-end encrypted backup archives. The hosted service can read the schedule and payment information needed to display customer consent, communicate with Payfast and maintain its ledger. It stores provider payment references, amounts, dates, status, allocation evidence and audit events in its private database. The archive decryption protection described above does not prevent the collections service from processing information you separately submit to it.

Creating a consent link does not give consent for the customer. The customer opens the hosted link, reviews the amount, recurrence and terms, and explicitly approves continuing to Payfast. The native app does not request or store card numbers or security codes. Card entry and processing take place on Payfast's hosted pages under that provider's terms and privacy practices. In Live mode the initial customer-approved checkout and subsequent authorized schedule can collect real money. Sandbox mode is explicitly labelled for testing.

A return page, timeout or unconfirmed operation does not establish payment or cancellation. The service records payment only after checking provider evidence. Provider receipts and cached statements remain separate from bank settlement, tax invoices and local customer-account postings. An offline cached statement shows when it was last retrieved and may no longer reflect current provider status.

The merchant remains responsible for its customer consent, contract terms, support, cancellation instructions and authorized use of customer information. Signing out, uninstalling the app or deleting a local draft does not cancel a provider subscription. Use the confirmed cancellation controls and resolve uncertain operations before closing the associated cloud account.

Retention and removing information

Normal local business records remain until the app's storage is removed. This beta does not have a full in-app deletion control for real businesses; the sample reset control applies only to registered fictional samples. Android's app settings offer Clear storage, and uninstalling removes the app's local storage. These actions permanently remove local businesses and logins; make any backup you need first. They do not remove exported files, printer output, provider-held backups or records sent to a shop host.

Forget this shared shop removes this device's saved pairing after the host confirms sign-out or revocation and outstanding operations have been resolved. It does not delete the host's account, transaction history or business records. Sign-out and disabling a staff login are also not record deletion.

The cloud screen offers Delete cloud account after a fresh cloud-password check and explicit confirmation. When closure is allowed, this deletes the account's hosted web backups, native backups and sync replicas, and revokes its sessions. It does not delete local businesses on any device, exported files or independently operated shop-host records. The service retries interrupted ciphertext-file erasure using an account-scoped deletion queue. Deleting a cloud account prevents other devices linked to it from continuing that cloud connection. Make any local backup you need before choosing this action.

An empty collections registration with no merchant connection, schedule or history can be removed with the account. A merchant connection or retained collections record blocks immediate cloud-account deletion so an active consent link, unresolved payment or provider subscription is not left without owner access. The app displays closure instructions and keeps the account available for reviewing and cancelling schedules and exporting statements. Contact zaxx.im@gmail.com to request collections closure and deletion review after resolving those obligations. No provider subscription is cancelled silently and no retained financial record is described as erased. The operator will explain any transaction, consent or audit evidence that must be retained for applicable obligations or disputes and arrange removal of information that no longer needs to be kept. If the service cannot verify the collections state, deletion stops rather than assuming closure is safe.

For shared-shop records or staff accounts, contact the shop operator. It may retain transaction or audit records for its business or legal obligations and should explain its retention. Remove exported files from their chosen destinations and follow that provider's deletion controls.

For information you send directly to the publisher for support, or use in a publisher-operated demonstration shop, contact zaxx.im@gmail.com to request access, correction or deletion. We may need enough information to confirm that the request belongs to you and may retain information needed for legal obligations or resolving the support matter. We cannot remotely erase records stored only on your device or an independently controlled shop host.

You can also request cloud-account deletion by emailing zaxx.im@gmail.com, even if you cannot access the app. Use the subject "IntelliVision Business account deletion", identify the cloud account email and say whether you want the account closed or specific publisher-held information deleted. Send the request from that account's email if possible so ownership can be checked. Do not send your password or backup passphrase. Any unresolved provider obligations and retained transaction, consent or audit evidence will be explained during the closure review; uninstalling is not required to make a request.

Intended users and policy changes

This app is designed for adult business owners and staff. It is not a children's service and has no public social-network or advertising feature. Operators should limit access to authorized staff and enter only data needed for their work.

If native app data practices change, this notice will be updated with a new effective date. Features supplied by a shop host or another service may require additional information and controls before use. Privacy and support contact: zaxx.im@gmail.com.