Skip to Main Content
Data Protection & Privacy

Privacy Policy

Last Updated: September 9, 2026

Current data practice

Rinkler stores account, business, customer, referral, voucher, reward, and loyalty records to provide the current web application. Rinkler does not currently sell customer or business records. Data is sent to the providers listed below when their related features are used.

01

Information Rinkler Handles

Customer and Program Records

  • Customer details: Name and mobile phone number entered to join a business program or claim an offer, confirmed email address and verification timestamp, and the account linked to those records. The phone number helps the business find a customer or voucher at the counter; entering it does not verify ownership of rewards.
  • Referral and voucher details: Business, location, and referrer links, referral and claim codes, claim status, issued program version and offer terms, friend discount, and claim, confirmation, and expiry timestamps.
  • Reward and loyalty details: Store-credit ledger amounts and statuses, redemption timestamps, punch counts, configured reward rules, and event history with location, program version, adjustments, reversals, reasons, and acting user when present. Rinkler records the configured friend discount when a visit is confirmed. It does not record the customer's full sale total.

Account and Business Records

  • Authentication: Supabase Auth handles email and password credentials, confirmation and recovery activity, and sessions for business accounts. For customer accounts, Supabase Auth handles the email address, one-time-code request, verification, and session, or the Google identity and profile data returned when Google sign-in is available and selected. Customers receive a code by email or use Google and do not create a Rinkler password. Previously confirmed phone identities can retain existing signed-in account access.
  • Customer account links: A private database link associates a signed-in Supabase account with business-specific customer records. New links use matching confirmed email records. Existing ownership links remain, including links from previously confirmed phone identities. An unverified contact email or phone number alone does not establish account ownership.
  • Business details: Owner account ID, business name, URL slug, onboarding state, record timestamps, locations, and referral, discount, reward, loyalty, and display settings.
  • Team access: Team account IDs, invitation email addresses, membership and invitation status, owner, manager, or staff role, assigned locations, and related timestamps.
  • Transactional messages: Destination email address, message type and content, related business, location, and customer, delivery attempts, provider message ID when returned, delivery state, error code, and timestamps. Historical SMS records can retain their destination phone number and message history.

Verification, Browser, and Request Data

  • Historical phone verification challenges: Purpose, HMAC fingerprints of the phone number, request IP, and business scope, a context digest, a random code salt, a derived code digest, attempt count, and created, expiry, and consumed timestamps. Rinkler does not store the submitted six-digit code in the challenge row. Current public flows do not issue these phone challenges.
  • Request controls: Customer account code requests and verification create service-only database rate-limit events containing the action, reservation state, HMAC fingerprints of the normalized email address and request IP, and timestamps. Historical events may contain phone fingerprints. The event row does not contain the raw email address, phone number, or IP address. Customer code verification also uses the request IP in a process-local rate-limit key as a secondary check. Account access forms use Cloudflare Turnstile, which receives the request IP, browser and device signals, and challenge response needed to assess automated traffic.
  • Browser data: Supabase session cookies connect signed-in accounts between requests. Print choices and onboarding-checklist progress may be stored in the current browser's local storage.
02

How the Current Product Uses Data

  • Account access: Business accounts use an email and password. Customer accounts use an emailed one-time code or Google sign-in when available, without a customer password. After confirming the customer email, Rinkler links matching verified business-specific customer records and provides a read-only account view. Previously confirmed phone sessions retain access to their linked rewards; email sign-in does not automatically transfer those rewards to a different account.
  • Customer access: Public enrollment, wallet lookup, and voucher claim flows require a signed-in account with a confirmed email. Authorized owners, managers, and staff can add or retrieve a customer through merchant tools without customer email or phone verification, subject to their role and location access.
  • Referral claims: Limit claims per business using the account, email address, and contact phone number, expire a pending claim at the expiration date set by its issuing offer, and block self-referrals using existing ownership links, verified email, and matching contact phone numbers.
  • Rewards: Add AVAILABLE entries to earned credit, subtract REDEEMED entries from the balance, and give CANCELLED entries no balance effect. A confirmed visit can also add configured loyalty punches.
  • Business reporting: Show current customer, claim, friend-discount, reward, and loyalty activity and prepare owner-requested CSV exports.
  • Messaging: Request customer account access codes through Supabase Auth email delivery. Rinkler can also email earned-credit, credit-redemption, and punch-reward redemption notices to the linked account's current confirmed email address, including the business, location, reward or credit used or earned, and remaining balance. A receipt without verified email ownership is suppressed. Other buttons open a draft in a device messaging or share app; the person using that app chooses whether to send it.
03

Providers and Device Apps

Vercel

Hosts the web application and receives the web requests needed to deliver pages and server actions.

Supabase

Provides business email and password authentication, customer email-code and Google authentication, and session management. Customer account codes are requested through Supabase Auth. Email delivery depends on its separately configured SMTP provider. Supabase also stores application records.

Google

When Google sign-in is available and selected, Google authenticates the customer and returns identity and profile information to Supabase Auth. Rinkler uses the confirmed email and account identity for customer access.

Resend

Receives the destination email address, sender, subject, and message body for loyalty receipts. When configured as Supabase Auth's SMTP provider, Resend also processes sign-in and other account emails. Provider acceptance does not confirm inbox delivery. New customer codes and receipts are not sent by SMS.

Cloudflare Turnstile

Checks account access forms for automated traffic. Cloudflare receives the request IP, browser and device signals, and challenge response. Supabase Auth validates tokens for its protected account requests. Rinkler validates the customer code-verification token directly with Cloudflare before checking the submitted code. Rinkler also directly checks the token before starting Google sign-in.

Messaging and Share Apps

Receive the draft text, link, and any recipient selected on the device. Rinkler does not send a device-opened draft; the person using the device controls the send action.

04

Access and Retention

Database access: Direct browser access to the private customer-account-link and customer-auth-rate-limit tables and the customer, referral, reward, and phone-verification tables is disabled. Public customer flows use server actions and restricted database functions. Owners, managers, and staff sign in to access their business records according to their role and assigned locations. Owners control team access and CSV exports; manager and staff actions have role and location limits. The customer account view is read-only and returns business-specific records linked to the signed-in account.

Historical verification challenges: A legacy phone code expires after 10 minutes, is limited to five attempts, and can be used once. Challenge rows older than 24 hours are deleted when a new challenge is issued. Current public flows no longer issue these challenges, and the application has no scheduled challenge cleanup, so historical rows may remain until separately removed. Supabase Auth manages current email codes under its configured expiry and request limits.

Customer account request limits: A code request starts with a provisional quota reservation. A successful email-code request finalizes it, while a confirmed rejection releases its quota. An unfinished or uncertain provisional reservation stops counting after two minutes. Finalized request events and verification events count for 10 minutes. Rate-limit events older than 24 hours are deleted when another customer account rate-limit check runs. There is no scheduled cleanup, so an event can remain longer when no later check runs.

Program records: A pending voucher becomes unusable at the expiration date set by its issuing offer and shown on the voucher. The application can change its status to EXPIRED without deleting the record. Store credit remains specific to the business that issued it. The current application does not implement an automatic deletion schedule for Supabase Auth users, private customer account links, business, customer, referral, reward, or loyalty records.

05

Exports, Requests, and Contact

Business exports: A signed-in owner can export a CSV for the owner's business containing customer contact details and joining location, referral records and issued offer terms, current Rinkler credit and punch balances, and the loyalty event ledger. Referral rows include issuing and confirming locations, program and version IDs, discount, credit, bonus punches, currency, terms source, and expiration. Event rows include location, program version, recorded adjustments or reversals, reason, and acting user when present. Event and referral records are bounded by the export cutoff. Current balances are read during export and may include later activity.

Request tools: The current application has no self-service correction, record-deletion, account-deletion, or automated privacy-request portal. Questions or requests can be emailed to the address below. Do not include a password or verification code.

Privacy contact:

Email: hello@rinkler.app