SwiftPay Privacy Policy

Last updated: September 29, 2026

Plain English: The merchant controls the local ledger: card numbers, PIN hashes, balances, transactions, staff accounts, reports, and backups remain on the merchant's device. Limited online services support licensing, password recovery, application delivery, and customer Pocket Card links. SwiftPay does not operate a cloud transaction ledger.

1. Store Records Kept on the Merchant Device

SwiftPay stores the store profile, staff accounts, card numbers, PIN hashes, balances, transactions, audit records, receipt settings, agreement acceptance evidence, and backup history in the browser database on the merchant's device. These records are not intentionally sent to SwiftPay's licensing database.

Trial activity is stored locally in a test ledger separate from the paid production ledger. After paid activation, trial cards and related test records remain permanently quarantined on the merchant device and cannot be converted into production cards. SwiftPay's licensing service may know that a trial exists, but it does not receive the trial card numbers, PIN data, balances, or transaction details.

2. Licensing and Verification Information

To prevent repeated trials, the merchant provides and verifies a business email address. An Owner may also verify a store-controlled recovery email for self-service password recovery. SwiftPay's licensing service may process the email address or a protected one-way representation of it, Install ID, installation credential, application version, licensing request, trial or license status, license dates, recovery-code delivery and verification attempts, and ordinary technical metadata such as IP address, browser headers, request time, and service logs. Email recovery codes are one-time, expire after ten minutes, and are stored by the service only as protected hashes. Card balances and transaction records are not required for licensing or password recovery.

3. Service Providers

SwiftPay currently uses the following service providers for limited operational purposes:

• Supabase provides the licensing database, authentication, trial verification, activation, renewal, and related server functions.
• Resend delivers business-email verification and authentication messages.
• Netlify hosts and delivers the SwiftPay web application and its static files.
• Cloudflare hosts and delivers the customer Pocket Card page and provides DNS, routing, security, and related network services.

These providers may process ordinary connection, security, delivery, and diagnostic information under their own terms and privacy policies. SwiftPay configures these services for licensing and application delivery, not as a remote card-balance or transaction ledger.

4. No Transaction Backend

SwiftPay does not intentionally upload card numbers, PIN hashes, balances, issuance or redemption transactions, staff accounts, receipts, encrypted backups, or reports to Supabase, Resend, Netlify, Cloudflare, or another SwiftPay transaction backend. The licensing service does not give SwiftPay remote access to the merchant's local ledger.

A new Pocket Card link contains the actual 16-digit gift-card number, its PIN-required status, Store/Brand Name, supplied Legal Business Name, merchant contact details, optional merchant logo, and trial status. Older links may contain a separate Wallet ID that the issuing store resolves locally. The link does not contain a balance, cardholder PIN, PIN hash, transaction history, staff account, or backup. These card details are carried in the URL fragment, rather than uploaded as a transaction to the hosting service. Printed Pocket Card QR codes use this full link. When the merchant uses Copy Link or Share, SwiftPay 4.0.8 encrypts these details on the merchant device with a new random key (AES-256-GCM) and uploads only the encrypted data to the Pocket Card host, which returns a random link identifier. The key stays in the part of the link after “#k=”, which browsers do not send to servers, so Cloudflare and SwiftPay cannot read the card number, PIN status or store details in a short link. Short links remain valid for seven years from creation, measured on the server; opening a link does not extend it. The store Owner can replace or revoke a short link at any time. An expired, revoked or older-format short link shows only: “This Pocket Card link has expired. Please ask the issuing store for a new link.” The Pocket Card page never uploads card details. Browser history, clipboard, messages, screenshots, and recipients may still retain or share them. Anyone receiving a PIN-free card or its link may present that identifier for redemption at the issuing store without an additional card PIN. Keep it secure and share it only with its intended holder.

When the merchant enables signed local activity, new Pocket Card links also contain an opaque merchant activity scope, public verification key, and its fingerprint. The private signing key stays on the licensed terminal and is included only inside authenticated encrypted backups. A separate activity QR carries that card's signed transaction description, date/time, amount, resulting balance, sequence, and transaction/reversal references. The customer explicitly scans it; signature verification and the personal activity copy remain on that customer's device. SwiftPay and Cloudflare do not receive the scanned activity. The merchant ledger remains official. Shared card links and saved card images do not include this locally saved activity history. Clearing customer browser data can erase the personal copy. A replacement signing identity requires in-store re-pairing; this offline design cannot remotely revoke copies or keys already distributed.

5. Agreement Acceptance Evidence

The application keeps the merchant's acceptance evidence locally, including the legal business name, store name, signer name, title, email, account role, acceptance time, Install ID, application version, Agreement version, Agreement fingerprint, and the separate confirmations selected by the signer. The merchant can download an acceptance receipt with an exact copy of the accepted Agreement and should retain it with its business records.

6. Camera Permission

Camera access is requested only after the user chooses to scan. Camera frames are processed in the browser to read a barcode and are not intentionally recorded or uploaded by SwiftPay.

7. PINs, Backups, and Device Access

Cardholder PINs are stored as salted password-derived hashes, not readable PINs. SwiftPay backup files are encrypted using the backup password selected by the merchant. New backups also include a separate Recovery Kit that can unlock that backup if its password is forgotten. SwiftPay does not receive or retain either credential and cannot recreate a lost password or Recovery Kit. When a card requires a PIN, the PIN prints only on the customer copy of the issue receipt, never on the merchant copy; that receipt should be kept like cash. SwiftPay does not lock automatically after inactivity: sessions stay signed in until Lock, sign-out or app close, so a signed-in terminal must not be left unattended. SwiftPay signs users out whenever the application reloads; however, local browser roles cannot protect records from someone who controls the device operating system, browser profile, developer tools, or IndexedDB. The merchant must use a store-controlled account or kiosk profile, block unauthorized administrative access, and protect staff passwords, unused card numbers, PIN handoffs, printed recovery records, backup files, and Recovery Kits.

8. Retention and Deletion

The merchant controls the local records and is responsible for retaining them for the current calendar year plus the five preceding full calendar years, or longer when applicable law, contract, tax rules, investigations, or holds require it. Clearing browser storage, resetting or losing the device, changing browser profiles, or uninstalling the app may permanently remove local records unless a current backup exists. Licensing and provider logs are retained only as reasonably needed for licensing, security, fraud prevention, service delivery, legal obligations, and dispute resolution.

9. Contact

For privacy questions, email SwiftPay Support at support@swiftpay-solution.com. Never send a cardholder PIN, backup password, Recovery Kit, unencrypted backup, or complete card number through SMS, WhatsApp, or ordinary email.