How Stayker protects payment and guest data.

Stayker is the travel platform behind the event. Partners and their clients run official event hotel programs through their own branded portals; Stayker provides the booking infrastructure, payments, and hotel fulfillment, while the partner keeps the brand and the guest relationship. Guests can create a persistent account that saves their profile and payment method for faster rebooking; saved card data is held only as a token — never touched or stored in the clear by Stayker. The platform runs on managed, secure cloud infrastructure.

Two products are in scope for this document: live-inventory booking (real-time hotel availability and individual reservations for an event's official hotels) and group housing (managed room blocks with attendee sub-blocks, approval workflows, and rooming-list delivery to hotels).

Stayker completed a PCI DSS SAQ D self-assessment in October 2025 and renews it annually; the current assessment is on cycle for renewal in October 2026. SAQ D is the most comprehensive self-assessment questionnaire under the PCI DSS — Stayker assesses against the full control set rather than relying on a narrower questionnaire.

Today, a live booking's card is transmitted over TLS directly to the hotel-distribution system to complete the reservation. Stayker does not store the full card number — only the last four digits are retained for reference — and never stores the CVV. Because the platform transmits cardholder data during a booking, it assesses against the full SAQ D control set. The booking service fee is processed by Stripe within Stripe's PCI DSS Level 1 environment.

Scope reduction in progress. Stayker is deploying tokenization — capturing cards in a certified PCI DSS Level 1 provider's embedded element so the full card no longer transits Stayker's systems — currently in a staging environment and scheduled to go live by September 1, 2026. An Attestation of Compliance and the supporting SAQ D are available to partners under NDA on request.

For a live booking today, the guest enters their card on a secure Stayker checkout page, and the card is transmitted over TLS directly to the hotel-distribution system to place the reservation. Stayker does not persist the full card number — only the last four digits are stored, for reference and display — and the CVV is never stored.

The booking service fee is charged separately through Stripe's hosted payment fields, so that transaction is handled inside Stripe's PCI DSS Level 1 environment.

When a guest saves a payment method to a persistent account, the card is stored only as a token held by a certified PCI DSS Level 1 provider — Stayker never touches or stores the underlying card.

Tokenization (rolling out). For live bookings, Stayker is moving card capture into an embedded element served by a certified PCI DSS Level 1 provider, so the card is exchanged for a token at entry and no longer transits Stayker's systems. This is in staging today and scheduled to go live by September 1, 2026.

Data Stayker never stores

This distinction is central to understanding Stayker's payment obligations and is consistent across every booking path:

Because Stayker is never the merchant for the room charge, the stay transaction does not settle through Stayker; the guest's card is used only to place the reservation, and Stayker does not store the full card number.

In group housing, the attendee's card is collected for the reservation and provided to the hotel through the rooming-list process — into the hotel's own PCI-compliant card-handling environment for guarantee and check-in. Stayker does not store the full card number, and there is no hotel-facing plaintext "reveal" of the card on a Stayker-controlled screen.

Under the tokenization model rolling out for September 1, vaulted card tokens carry an expiration timestamp; once it passes, the token is automatically purged and is no longer retrievable. Tokens are purged once they are no longer operationally needed.

• Role-based access control. Every user holds one or more explicit roles — administrator, partner administrator, client administrator, event manager, and customer/guest. Role assignments are the system's source of truth for authorization (held in a dedicated assignment table, not a free-text attribute), and are enforced at the route and middleware layer on every request rather than only hidden in the interface.
• Multi-tenant data isolation. Access is scoped to a partner's own organization. Dedicated middleware enforces partner and client boundaries so that one partner — and its events, reservations, and guest data — is not visible to another. A partner's data is walled off from every other partner on the platform.
• Authentication. Sessions and API access use signed, expiring access tokens; enterprise partners can authenticate via single sign-on (SSO), so access follows the partner's own identity provider and de-provisioning.
• Card-activity audit log. Card-related actions — bookings and saved-payment-method changes — are written to an immutable audit log by reference and actor. The full card number is never written to the log.
• Least privilege. Management-level provider keys are never deployed to the runtime environment; only the minimum public/private application keys required for the flow are present, sourced from Secret Manager.

• Code review on every change. All code changes are peer-reviewed before release; no change reaches production without review.
• Controlled, staged deployments. Changes are validated in a staging environment before promotion to production.
• Vulnerability scanning. Stayker's platform and external attack surface are scanned regularly using a third-party automated vulnerability-scanning service; findings are triaged and remediated on a risk-prioritized basis.
• Site-security certification. Customer booking pages carry a third-party site-security certification seal.
• Responsible disclosure. Suspected vulnerabilities can be reported to security@stayker.com; Stayker does not pursue good-faith security researchers.

Stayker maintains processes to detect, investigate, and respond to security incidents. Card-related actions are traceable through the audit log described in §07, which records booking and payment-method activity by reference and actor — never the full card number.

In the event of a confirmed security incident affecting a partner's data, Stayker will notify the affected partner without undue delay and coordinate on containment and remediation. Because Stayker does not store full card numbers — only the last four digits are retained — its data stores are not a repository of usable cardholder card numbers.

Retention follows Stayker's published Privacy Policy. Booking personal data (name, email, phone) is retained for six months after checkout and then deleted; anonymized, aggregated booking records are kept up to seven years for tax and accounting. Card data is never stored (§03); card tokens carry an expiration and are purged automatically. Guests and partners may request deletion of personal data.

Stayker's platform is hosted in the United States; guest and reservation data is processed and stored in-region.

International data protection. Stayker's Privacy Policy addresses the EU/UK GDPR and California's CCPA/CPRA — including the legal bases for processing, data-subject rights (access, correction, deletion, and objection), and international data transfers. Where personal data of EU/UK residents is transferred to the United States, it is handled under appropriate safeguards such as Standard Contractual Clauses (SCCs). Data-subject and deletion requests can be made through the contacts in the Privacy Policy.

Stayker works with a limited set of vetted subprocessors, described below by function. Those that handle cardholder data are certified PCI DSS Level 1 providers. A full, named list is available to partners under NDA on request.

• Security & compliance. Amy Barker, Founder & CEO — amy@stayker.com
• Report a security concern. security@stayker.com
• Documents. SAQ D and Attestation of Compliance available to partners under NDA on request.

CONFIDENTIAL — prepared for partner and procurement due diligence; not for public distribution. © 2026 WPF Holdings, LLC d/b/a Stayker.