Privacy Policy

Who we are, and the two roles we play

Pawikan (“Pawikan”, “we”, “us”) is a booking platform for joiner tour organizers in the Philippines. Pawikan is a product of SistemaPH (sistemaph.app) and is operated under the SistemaPH brand. “Pawikan” is used here as the product name and “SistemaPH” as the parent brand; the registered legal entity that operates them, its registered address, and a verified privacy contact are not yet published. That gap is a launch blocker and is recorded in the maintainer checklist.

The platform sits in two different data protection roles:

• Trip records — organizer is the controller, Pawikan is the processor. For booking, traveller, emergency contact, manifest, and payment record data, the organizer decides what is collected and why. The organizer is the personal information controller (PIC) and Pawikan is its personal information processor (PIP), processing on the organizer’s documented instructions.
• Platform accounts and security — Pawikan is the controller. For organizer and staff accounts, sign-in and sessions, invitations, support, and Pawikan’s own platform security, Pawikan is a separate PIC and decides how that data is used. Audit records that describe a tenant’s trip data — manifest views/exports and payment approvals or rejections — are part of the organizer’s trip records and are processed by Pawikan as PIP on the organizer’s behalf, not for a Pawikan controller purpose.

The organizational pages for a trip are governed by the organizer’s own privacy notice as controller. Where the organizer’s notice and this policy touch the same trip data, the organizer’s notice and the Data Processing Agreement inside our Terms of Service take precedence for that data.

What this policy covers

This policy covers personal data handled through the Pawikan platform, including:

• organizer and staff accounts, sign-in, invitations, and account settings;
• trip pages and the public booking flow;
• booking, traveller, emergency contact, and manifest records;
• payment proof records the booker submits for the organizer to review;
• notifications, support, audit, and security records.

It does not cover:

• the trip itself, or the organizer’s own handling of data after they receive it — the organizer’s privacy notice governs that;
• third-party websites, or the organizer’s GCash, Maya, bank, or other payment accounts, which are governed by those providers’ own terms and privacy notices;
• an organizer’s off-platform records, chats, and spreadsheets.

The data we handle

Depending on how the platform is used, we handle these categories:

• Account data: name, email address, password credential (stored as a hash or handled by the sign-in method), organization name and details, role, team invitations, and preferences.
• Session and security data: session identifiers, request metadata such as IP address and user agent, and audit records of manifest views/exports and payment approvals/rejections.
• Booking data: the booker’s name, mobile number, and optional email; each traveller’s full name, birthdate, optional sex, nationality, and optional mobile; and each traveller’s emergency contact name and number.
• Trip and organizer content: trip details, prices, policies, public page content, and free-text notes a booker writes to the organizer.
• Payment records: amounts, references, status, and the proof image or document a booker uploads (for example a receipt or screenshot).
• Manifests and exports: compiled rosters and the files an organizer downloads for a trip.
• Optional ID data: the data model supports government ID documents or numbers when an organizer opts in, but the current public booking form does not request them. See the government IDs section below.

Where the data comes from

• from the organizer, when they create an account, a trip, or public content;
• from the booker, who enters their own details and the details of the travellers and emergency contacts in their group;
• from travellers who complete or correct their own details;
• from payment proofs and receipts the booker uploads;
• automatically from the browser and the request, for sessions, security, and abuse prevention.

We do not buy personal data, and we do not scrape it from other services.

Why we handle it, and our legal bases

For Pawikan’s own account, sign-in, support, and platform-security processing, Pawikan is the controller and applies the bases in section 12 and, where relevant, section 13 of RA 10173: performance of the contract with the organizer where it applies; legitimate interests that are necessary and balanced, such as keeping accounts secure and the service available; and compliance with a legal obligation only where one actually applies. Consent is used only where no other basis fits. Section 11 sets out general data privacy principles; it is not itself a legal basis for processing.

For trip and booking data, the organizer determines the lawful basis as controller, and Pawikan processes only on the organizer’s documented instructions. The organizer must tell data subjects the basis in its own notice; Pawikan does not choose trip-data purposes.

For sensitive personal information, section 13 of RA 10173 applies and a specific exception is required. Contract and legitimate interest are not enough on their own — see the sensitive data section below.

We use personal data to:

• create and secure organizer and staff accounts, and send sign-in and recovery email;
• publish trip pages and take bookings, including temporary slot holds;
• compile trip manifests for the organizer and the people who need them;
• record payments so the organizer can review and approve or reject them;
• send booking, payment, balance, and trip-detail notifications;
• provide support and respond to requests;
• detect abuse, fraud, duplicate references, and security incidents;
• keep audit records and meet legal, tax, and accounting obligations.

We do not use booking or trip personal data for advertising, and we do not sell it.

Sensitive personal information

Before any sensitive data is collected, the organizer must establish and be able to document a valid section 13 basis, or obtain specific informed consent, and must give the notice required by the Act. This is the organizer’s responsibility as controller; Pawikan assists as processor.

The booking form includes an optional free-text “notes for the organizer” field. That field is not a medical record and should not be used to collect health information. If a health or accessibility need must be recorded for safety, it must have a documented lawful basis and be limited to the minimum necessary.

Pawikan does not currently scan free-text notes to detect sensitive information. This remains a manual responsibility and an open launch-review item.

What the organizer must do before collecting

As controller, the organizer is responsible for doing the following before collecting personal data through Pawikan:

• give the data subject the notice required by section 16 of RA 10173, including the identity of the controller, the purpose, the legal basis, the recipients, and the rights available;
• establish a lawful basis for each category, and for sensitive data a valid section 13 exception or specific informed consent;
• if a group booker supplies other travellers’ details, ensure the booker has the authority to do so and that those travellers have been given notice (or the organizer gives it);
• where a traveller is a minor, obtain the appropriate guardian’s consent and handle the data with the care the law and the child’s best interests require;
• tell emergency contacts that their name and number were supplied, and why, before or as soon as practicable.

Organizers must also collect only what the trip actually needs, keep it accurate, and not use it for unrelated purposes.

Government IDs and ID documents

The current public booking form does not request government ID numbers or ID document uploads. The data model contains opt-in support for organizers who need them (for example if a boat operator or a local government unit requires them), but that collection flow is not active and no purge job is running.

Required vs optional information

Fields marked required on the booking form are needed to create and hold the booking and to produce a usable manifest. If a required field is not provided, the booking cannot be completed. Optional fields can be left blank without losing the booking; they may simply limit what the organizer can include in the manifest or use to reach the group.

When submitting a payment proof, do not upload credentials, one-time passwords, full banking details, card numbers, or unrelated sensitive documents. A proof should show only what is needed to match the payment, such as the amount, date, reference number, and sender. Avoid putting unnecessary sensitive information in the notes field.

Who can see it, and who we share it with

Personal data is shared only as needed, and under role-based controls:

• Organizer staff can see booking and payment data according to their role.
• Guides see a limited, “guide-safe” roster of names and ages for their assigned departures, not phone numbers or emergency contacts. Organizers remain responsible for any separate sharing outside this roster.
• Organizers can view and export manifests and booking details, and may share them with boat operators, local government units, or other providers where necessary and lawful. The organizer is responsible for sharing only what is needed and for giving lawful instructions.
• Pawikan staff may need access for support, security, and legal compliance. Role-based authorization limits access today. A general access-audit trail for Pawikan staff is a proposed control, not an implemented one, and is on the launch-review checklist.

The service providers currently planned to process data for us are:

• Supabase — hosted Postgres database and file storage.
• Resend — transactional email delivery.
• Vercel — the documented target hosting platform.

Better Auth is a software library that runs inside our own application. It is not a separate hosted data recipient.

We do not sell personal data, do not let recipients use it for their own marketing, do not reuse it across organizations, and do not use it to train AI models.

Public pages vs private records

An organizer’s marketing content — logo, cover image, trip descriptions, public page — is public by design and visible to anyone with the link. Booking details, payment proofs, ID files, and manifests are private and access-controlled.

We use the cookies and session technology necessary to keep organizers signed in and to secure requests. We do not claim that the service is free of advertising or analytics cookies; whether any are present requires a technical audit and is a launch-review item.

Automated processing

Some steps are automated:

• temporary slot holds, including their expiry;
• booking status changes when a payment is approved or rejected by the organizer;
• a check that rejects a payment reference number already used by a non-rejected payment in the same organization and method;
• manifest compilation and export;
• scheduled and triggered notification email.

Payment verification itself is manual: the organizer reviews the proof and approves or rejects it. We do not currently connect to a payment gateway or verify payments automatically. The duplicate-reference check is a hard block — the booker must correct the reference or contact the organizer before the proof can be submitted — but it is a validation rule, not a determination that a payment happened. Whether the hold-expiry and duplicate-reference rules amount to automated processing that triggers additional obligations (for example under NPC rules on automated decision-making, or NPC registration requirements) has not been reviewed and is flagged on the launch-review checklist.

How we protect it

Controls we can currently describe as implemented include:

• organization-scoped authorization plus row-level security on tenant tables;
• a private storage bucket for payment proofs, reached only through short-lived signed URLs of five minutes or less (no ID document upload flow is active today);
• audit logging of manifest views/exports and of payment approvals/rejections;
• role-based limits on who can see what.

How long we keep it

Under section 11, personal data must be kept no longer than necessary for its declared purpose or a lawful retention ground. The proposed schedule must distinguish account data needed during an active account; booking and manifest data needed for a trip; payment records needed for reconciliation; and audit/security records needed for accountability. Any later tax, accounting, or legal-claims retention must be justified and time-limited, not indefinite retention for possible future use.

Your rights as a data subject

Under RA 10173 you have the right to:

• be informed that your personal data will be, is being, or was processed;
• object to processing, including for direct marketing;
• withdraw consent at any time where processing is based on consent. Withdrawal does not affect processing already carried out, or processing that has another lawful basis;
• reasonable access to the data held about you;
• have inaccurate or outdated data corrected;
• erasure or blocking of data in the cases the law allows;
• claim damages if your rights are violated;
• data portability, where the law provides for it;
• complain to the National Privacy Commission (NPC).

For trip and booking data, the organizer is the controller and holds the records — start with the organizer. For your organizer or staff account and platform security data, contact Pawikan. Because Pawikan processes trip data only as a processor, forwarding a request to the organizer does not dismiss your rights; Pawikan assists the organizer as the law requires. Before acting on a request we may ask for the minimum information needed to confirm identity, and nothing more. Erasure or blocking may be limited where the law requires us or the organizer to keep data — for example tax, accounting, or legal-claims retention — and we will explain the specific exception that applies.

NPC references: data subject rights and contact the NPC.

Changes to this policy

We may update this policy as the service, the law, and the guidance from the NPC change. Material changes must be communicated in a way the law and the Data Processing Agreement require, and we must have a lawful basis for any new purpose. We will not treat continued use of the service as blanket consent to retroactive purposes that lack a lawful basis.

Primary sources for this draft are the Data Privacy Act of 2012 (RA 10173) and its Implementing Rules and Regulations. Other NPC issuances may apply and have not all been reviewed.

Contact and complaints

Until a verified contact is published, the NPC is the independent authority for complaints and questions about the Data Privacy Act. Its contact page is privacy.gov.ph/contactus, and its guide to data subject rights is privacy.gov.ph/data-subject-rights.