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.

Every booking's card is entered in card fields served by Basis Theory, a certified PCI DSS Level 1 card vault, and goes directly to Basis Theory over TLS. No card number touches Stayker's servers. Stayker receives only a token, the card brand, and the last four digits, and never receives the CVV. On live-inventory bookings, the booking service fee is processed by Stripe within Stripe's PCI DSS Level 1 environment. Group housing carries no booking service fee.

An Attestation of Compliance and the supporting SAQ D are available to partners under NDA on request.

For a live booking, the guest enters their card in Basis Theory's embedded card fields on the secure Stayker checkout page. The card goes directly to Basis Theory's vault and is exchanged for a token at entry; it never touches Stayker's servers. Within the vault, the card number and expiry are sent over TLS to the hotel-distribution system to place the reservation — the CVV is never sent or stored. Stayker keeps only the token and the last four digits, for reference and display.

On live-inventory bookings, the booking service fee is charged separately through Stripe. A Stripe payment token is created from the same card inside Basis Theory's vault, so the card never reaches Stayker, and the charge is handled inside Stripe's PCI DSS Level 1 environment. Group housing carries no booking service fee.

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.

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 entered in Basis Theory's card fields and vaulted as a token, then 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.

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.