Camper BMS uses PCI DSS compliant payment providers to securely handle all cardholder data.
The following matrix outlines how responsibilities are divided between Camper BMS, campground operators (merchants), and payment providers. Each campground remains responsible for their own PCI DSS compliance as the merchant of record.
Many campground operators using Camper BMS may qualify for SAQ A due to the use of provider-hosted payment fields, however merchants are responsible for determining their own classification.
This document is provided to assist campgrounds in completing their own SAQ A attestation. Additional internal compliance documentation (including the Camper BMS PCI DSS Script Inventory and supporting security artefacts) is available on request under NDA for acquirers, QSAs, and enterprise customers conducting due diligence.
How to read this
Camper BMS - the software platform you log into. Provides the application, hosts the booking pages, enforces security controls (CSP, nonces, tamper detection), and integrates your chosen payment provider via their SDK.
Campground (Merchant) - your business. You are the merchant of record for every booking transaction. Your payment provider account is in your name, funds settle to your bank account, and you are responsible for your own PCI DSS attestation (typically SAQ A).
Payment Provider - Pin Payments, Square, eWay, ANZ Worldline, or Westpac OnlinePay. The third-party PCI DSS Level 1 Service Provider you have connected. They host the card input fields (in iframes served from their own domain), tokenise card data, and process and settle payments.
The matrix
Area | Camper BMS | Campground (Merchant) | Payment Provider (e.g. Pin Payments, Square, eWay, ANZ Worldline, Westpac OnlinePay) |
Merchant account ownership | ❌ | ✅ | ❌ |
Payment processing | ❌ | ❌ | ✅ |
Cardholder data collection | ❌ | ❌ | ✅ |
Cardholder data transmission | ❌ | ❌ | ✅ |
Cardholder data storage | ❌ | ❌ | ✅ |
Access to cardholder data | ❌ | ❌ | ✅ |
Payment page / UI hosting | ✅ (application pages) | ❌ | ✅ (card input fields via iframe) |
Card input fields | ❌ | ❌ | ✅ (hosted within provider-controlled iframes) |
Token handling / payment metadata | Receives and stores non-sensitive payment metadata (e.g. transaction IDs, tokens). Does not have access to cardholder data. | Uses payment data for business operations | Generates tokens and manages payment data |
PCI DSS compliance (overall) | Implements platform security controls; does not store, process, or transmit cardholder data | Responsible for PCI DSS compliance as merchant | PCI DSS Level 1 Service Provider (card data handling) |
Vulnerability scanning (ASV) | Performs quarterly external ASV scans against platform-hosted booking pages and shares pass results on request | Scans any externally-facing systems they host (e.g. their own marketing site, any off-platform checkout) | Maintains own ASV program for provider-hosted infrastructure (evidenced via their AOC) |
Infrastructure security | ✅ (AWS environment, application security) | ❌ | ❌ |
User authentication & access control | Provides platform authentication (login, session management, password policy) | Manages their own staff accounts within the platform | Manages provider-side access controls |
Application patching / security updates | Applies application and dependency security updates; relies on AWS for managed-service patching | Applies updates to any systems they host themselves | Maintains their own platforms and SDK releases |
Logging & monitoring | Logs application activity and CSP tamper-detection alerts; never logs cardholder data | Reviews transactions in their Camper BMS dashboard and their payment provider dashboard | Maintains full transaction and payment-system logs |
Customer website security (if applicable) | ❌ | ✅ | ❌ |
Payment provider account setup | ❌ | ✅ | ❌ |
Incident response (platform) | ✅ | ❌ | ❌ |
Incident response (payments) | ❌ | Participates for merchant account incidents | Responsible for payment system breaches and card data incidents |
What this means for your SAQ
If you are completing SAQ A for your campground business:
Your payment pages are hosted on Camper BMS, which serves card input fields inside iframes delivered directly by your chosen payment provider. This integration model is intended to support SAQ A eligibility criteria under PCI DSS v4.0.1, where all cardholder data is handled directly by PCI DSS compliant payment providers.
Camper BMS supports Requirement 6.4.3 (payment page script integrity) through nonce-based Content Security Policy controls, a documented script inventory, and governed change controls.
Camper BMS implements controls intended to support Requirement 11.6.1 (tamper detection on payment page headers and contents) through Content Security Policy (CSP) monitoring, violation reporting, and administrator alerting.
You remain responsible for the portions of SAQ A that relate to your own access controls, policies, staff practices, and any externally-facing systems you host yourself.
If your acquirer, card brand, QSA, or an enterprise customer requires additional evidence of Camper BMS's security posture, please contact support.
This document is provided for general guidance only and does not constitute legal or compliance advice. Each merchant is responsible for determining their own PCI DSS scope and requirements in consultation with their acquiring bank or payment provider.