Vowfolio by flipo — Privacy Notice

Prepared: 17 October 2026. Effective when first published on vowfolio.online. Version: 1.0, prepared 17 October 2026.

Website: https://vowfolio.online

1. Who is responsible and who this notice covers

בן יעקב אסף (Asaf Ben Yaakov), an Israeli sole trader operating as בן יעקב פתרונות טקסטיל (Ben Yaakov Textile Solutions) and offering Vowfolio by flipo, authorised dealer number 037017779, at הגורן 34, עתלית 3032434, ישראל (34 HaGoren Street, Atlit 3032434, Israel), operates this service. Contact info@flipo.co.il or write to that address about personal information. Support is at info@flipo.co.il. The responsible privacy contact is Asaf Ben Yaakov, reachable at the same address, at info@flipo.co.il, and by telephone +972547720142. Applicable jurisdiction-specific representative requirements are assessed before offering the service in a market that requires them.

This notice covers account holders, invited partners, guests whose information is entered by a couple, people using an invitation/RSVP link or submitting a greeting, and people contacting support. Depending on the context and applicable law, a couple may also be responsible for the information they collect and the people with whom they share it. This notice does not assume that every guest has an account or has agreed to the couple's own decisions.

2. Information we process and where it comes from

We do not ask for full payment-card numbers, CVVs, banking passwords or email passwords. Payment providers may collect payment information under their own notices. Never send those credentials to support. Importing contacts or enabling a picker is a deliberate user action; it does not give us continuous access to a phone's address book.

3. Purposes, choices and lawful grounds

We use necessary information to authenticate users, verify purchases, maintain the wedding workspace and its access rules, store and synchronise authorised records, handle reviewed sharing/exports, provide requested reminders and support, and prevent misuse and duplicate transactions.

Providing account/verification information is voluntary, but without the necessary information we cannot provide a verified account or paid access. Most planning content, guest notes, files, public sharing, push and offline storage are optional. Declining an optional feature does not require supplying the corresponding optional information, although that feature will not work.

Where relevant data-protection law requires a lawful basis, we rely as appropriate on performing our agreement with an account holder; complying with specific legal obligations; legitimate interests in secure, reliable service and requested guest communications after considering individuals' interests; and consent for processing that requires it. A guest's data is not automatically processed on a contractual basis merely because the couple purchased the service. The purpose/basis mapping is: account and purchased access - contract and necessary fraud prevention; optional reminders and sharing - the requested feature and any consent required; guest administration - the organiser’s valid authority and proportionate operational interests; sensitive notes - an applicable special-category condition, including explicit consent where required; security - proportionate legitimate interests and applicable duties; merchant records - the merchant’s contract and legal duties. We assess objections and do not treat one general acceptance as consent to every purpose.

Dietary or accessibility notes can reveal health, religion or other sensitive information. Keep them minimal and use non-sensitive practical instructions where possible. Before launch, the operator must establish the applicable special-category condition and guest notice/consent procedure where required. An account holder's general agreement is not treated as consent on behalf of every guest. Do not collect sensitive details without the required authority.

We do not use private planning content for advertising or for training general-purpose AI models. We do not sell private wedding content or use it for cross-context behavioural advertising. No third-party advertising pixels or session-replay tools are deployed on private or token-bearing routes under this policy. Any future optional analytics must be separately disclosed, assessed and configured consistently with applicable consent rules.

4. Sharing and recipients

Shared content is available to the authorised people permitted by the service's visibility controls. Ownership/side labels do not themselves provide privacy. A purchaser does not gain a general right to read a partner's private content.

We share only what is necessary with the configured service providers that host and secure the application, authenticate users, store files, process purchases, send requested communications or operate backups. The launch provider register is:

Support correspondence is handled through the operator’s business mailbox, including Zoho and forwarding to Gmail. Namecheap is the domain registrar supplied by the owner. Registrar/DNS administration is distinct from hosting the private wedding database; this does not state that Namecheap receives wedding content. The product domain is registered through Namecheap and served by Vercel. Cloudflare R2 is used for encrypted backups and does not require moving the domain’s DNS.

Public or invitation links and reviewed exports disclose selected information to their intended recipients. A person receiving a file, message, printout or link may keep or forward it. We may also disclose necessary information to comply with a valid legal obligation, protect legal rights or address security incidents, subject to applicable law. We do not give a general promise to notify someone where doing so is prohibited.

Lemon Squeezy may act independently for billing and related legal obligations. Each provider's role must be assessed rather than describing every provider as our processor. The couple's own suppliers or recipients are not automatically our subprocessors.

5. Guest forms and greetings

An invitation/RSVP token permits the intended guest operation, not access to the couple's planning workspace. The couple can rotate or revoke the link.

Guest greeting submissions are off by default and enabled deliberately for a household. The sender is shown the submission purpose and asked for the relevant consent. A plain-text submission is visible to the authorised couple for review; it does not immediately appear in the shared gallery. Rejected author/text content is removed from the submission, and unreviewed text expires after 30 days. Approved text becomes a greeting record and can be included in a deliberately selected keepsake export under the stated permission. Public greeting file uploads are disabled. Content-free retry-prevention records can remain as described in section 7.

6. Cookies, browser storage and offline access

Necessary cookies and related storage maintain authenticated sessions, installation access, request verification, preferences and security. The application uses HttpOnly secure vf_access and vf_refresh cookies with a seven-day cookie lifetime; the underlying access token can expire earlier and must be validated/refreshed. A registered installation uses vf_install and can be revoked by the server. Operators have a separate vf_operator cookie restricted to operator routes for ten minutes. Browser-local preferences, installation proof material, queued operation acknowledgements and optional IndexedDB/Cache Storage persist according to the feature, lease and local-clear controls. Hosting protection may set its own access cookie while this pre-launch deployment is protected. Clearing local data or signing out does not erase downloaded files held separately. These necessary mechanisms are not advertising consent.

Offline storage is optional. When enabled, the browser can retain the permitted planning subset, selected attachments and supported queued changes. Private collections and detailed financial information are not part of the general offline projection. The interface explains the supported scope and expiry. A locally chosen privacy code hides the interface; it does not encrypt the entire browser database.

You can sign out and use the provided local-cache controls, or clear the site's browser storage. Downloads, screenshots and operating-system backups may remain outside those controls. A device that is offline cannot reliably receive an immediate remote deletion or revocation instruction. Browser/OS eviction may remove cached information. Push permission can be changed in browser/system settings. Essential service communications and optional feature choices are distinct from marketing consent.

7. Retention and deletion

We keep information only for the stated purposes and justified operational/legal needs. Archiving preserves data and is not a deletion request. Account departure, private-record deletion and wedding deletion have different effects, described before confirmation; another authorised member may retain shared records where appropriate to the selected action.

Application retention rules are:

• Active planning content remains until the applicable deletion or service-closure process; it is not automatically erased just because the wedding date passes.
• Deleted production record content is scheduled for permanent purge after 30 days; any separate account/wedding recovery period must be clearly disclosed before that action. Deletion of physical objects can require a retry while the object remains inaccessible through normal service access.
• Temporary generated exports, pending upload data and completed request/acknowledgement content have short lifetimes, generally up to 24 hours under the relevant job rules.
• Rejected greeting text is removed; pending unreviewed greeting text expires after 30 days.
• Certain content-free operation identifiers/digests are retained for the workspace lifetime to prevent a replay from creating duplicate or deleted effects. These records are not represented as automatically anonymous.
• Relevant security/audit and delivery-event records generally use 90-day application retention rules, subject to specifically justified exceptions and the actual production log configuration.
• Production database/object backups expire under a seven-day managed database-backup window and seven daily encrypted offsite database/private-object recovery points. Controlled cleanup runs with the backup job and may pause during an incident rather than delete the last usable copy; such copies remain restricted to recovery and incident handling. A recovery must reapply deletion/revocation state before service reopens. We cannot promise immediate erasure from every backup.
• The merchant may retain invoices, tax and transaction information under its own legal obligations even after an app account is deleted.

A valid specific legal preservation need may require limited retention; access and reuse must remain restricted to that purpose.

8. International processing and rights

The operator and configured providers may process information in Israel; Germany and other EU locations for the configured application database and R2 backup residency; Ireland for the configured email sending region; and other provider support, edge, security and billing locations, including the United States and Singapore. We will identify the actual destinations and, where required, the appropriate transfer mechanism, such as an applicable adequacy decision or valid contractual safeguards. Merely accepting these terms does not replace a legally required transfer safeguard. Provider residency does not mean every operational datum remains in one country. The linked provider privacy/DPA resources identify their subprocessors and transfer terms, including standard contractual clauses where applicable. We maintain a transfer register and assess any additional representative or safeguard required for the markets actually served; availability will not be represented as legal clearance for every jurisdiction.

Depending on your location and applicable law, you may request access, correction, deletion, restriction, portability, information about recipients, or object to certain processing. Where processing relies on consent, you may withdraw it without affecting earlier lawful processing. These rights have conditions and exceptions; we do not promise that every right applies identically worldwide. You may complain to the competent data-protection authority, including the Israeli Privacy Protection Authority where applicable and an appropriate EEA/UK authority where relevant.

Contact info@flipo.co.il. A guest without an account can also contact us, identifying the relevant wedding or interaction without sending excessive personal information. We may need proportionate verification and coordination with the authorised couple, but an account is not an automatic prerequisite to raising a request. We will respond within applicable legal time limits. Asaf Ben Yaakov handles these requests through the privacy mailbox. We record the request date, verify identity proportionately, determine scope and any applicable exceptions, coordinate with the relevant authorised organiser/provider, and provide a decision and response within the applicable deadline. You may also complain to the Israeli Privacy Protection Authority or your competent local supervisory authority.

9. Security, incidents and updates

We use access controls, restricted database roles, encrypted transport where deployed, server-side secret handling and other measures appropriate to the service. No system is completely secure. Any legally required incident notifications will be handled under applicable law.

We will update this notice when relevant practices change, show the effective date and provide additional notice/consent where required. This draft does not authorise a new use of existing data. Contact the operator above for questions.