Security & Compliance

Payments, scoped
to the smallest surface.

Merchant Line never stores card numbers. Every transaction is tokenized at the device, settled by Stripe, and audited end-to-end. This is how.

PCI · SAQ-A scope Stripe-backed SOC 2 in progress US-East · US-West
▍ At a glance
Card data storedNone — ever
Encryption in transitTLS 1.3
Encryption at restAES-256
MFARequired for all admins
Last auditQ1 2026
SC / 01

Scope.

Merchant Line is a thin operational layer over a regulated payment processor. We're responsible for the catalog, the cart, the receipt, the reconciliation, and the scan. We are not in the path of card numbers.

Cards are entered on a Stripe-certified device — Tap to Pay on iPhone, Stripe Terminal, or the Stripe.js card element — and tokenized before they ever reach our servers. We see a payment intent, a status, and the last four digits. That's it.

SC / 02

Payments.

Card present and card not present payments are processed by Stripe under their PCI DSS Level 1 service provider attestation. Merchant Line never sees, transmits, or persists primary account numbers (PAN), magnetic stripe data, or CVV.

Card data flow Stripe-bounded · we are out of scope after step 2
01 · device iPhone / Terminal Tap-to-Pay or chip read on Stripe-certified hardware.
02 · enclave Secure element PAN tokenized on-device. Never reaches our memory.
03 · stripe Stripe PaymentIntent created & authorized. PCI DSS L1.
04 · ml api Merchant Line We get an ID, status, and last 4. Receipt issued.
PCI cardholder data scope Merchant Line scope
PCI scope
SAQ-A — outsourced cardholder data environment
Processor
Stripe Payments — PCI DSS Level 1 Service Provider
Acceptance
Tap to Pay on iPhone · Stripe Terminal S700, WisePOS E · Stripe.js elements
3DS
Required for online ticket sales over $50
Disputes
Handled in-app via Stripe Radar with operator-facing evidence packets
SC / 03

Data & encryption.

What we do hold — operator profiles, catalogs, order metadata, ticket codes, scan logs, settlement reports — is encrypted in transit and at rest. Backups are encrypted with separate keys and stored cross-region.

TLS 1.3 in transit
All API traffic and admin sessions. HSTS preloaded; no plaintext fallback.
AES-256 at rest
Database volumes and object storage encrypted. Keys rotated quarterly.
Tickets signed, not stored
Ticket codes are signed JWTs. Validation is cryptographic; nothing to replay.
Tenant isolation
Per-operator schema isolation. Cross-tenant queries are enforced at the ORM and at row-level security.
PII minimization
Customer email is the only PII collected. Phone numbers and addresses are optional and per-event.
Backups
Daily encrypted snapshots, retained 35 days, replicated cross-region. Point-in-time restore to 5 min granularity.
SC / 04

Access control.

The blast radius of a stolen credential is small by design. Operator staff can only do what their role permits, on the station they're signed into, during the event window they're scheduled for.

Operator MFA
Required for all admin accounts. WebAuthn preferred; TOTP fallback.
Staff sign-in
Station-bound 4–6 digit PIN, scoped to a shift. Short-lived tokens; auto-revoked at end-of-shift.
Roles
owner · manager · cashier · scanner · support — each with explicit grants for sell, refund, void, comp, and report-export.
Audit log
Every refund, void, comp, and export is logged with operator, station, device, and reason.
SSO
SAML & OIDC for owner-tier accounts. SCIM provisioning on enterprise.
SC / 05

Infrastructure.

Built on managed AWS in two US regions, fronted by a global edge. Deploys are immutable, fully traced, and reversible in under 90 seconds. We aim for unglamorous infra — predictable, boring, well-understood.

Regions
us-east-1 primary · us-west-2 warm standby
Edge
Global CDN with terminating TLS 1.3. WAF in front of all admin and API surfaces.
Network isolation
Private VPC for application and database tiers. No public ingress to data layer.
Secrets
AWS KMS & Parameter Store. Application code has no plaintext secrets at rest.
Logs & tracing
Structured logs, OpenTelemetry traces, 90-day retention. No card data ever logged.
CI/CD
Signed builds, mandatory peer review, automated dependency scanning. Reverts in < 90s.
SC / 06

Offline mode.

The hardest part of payments at a remote venue is what happens when the network goes down. Our offline behavior is deliberate, audited, and documented — not a happy accident.

When connectivity drops, registers continue to read tickets and queue card-present authorizations locally. Each queued auth is signed by the device, encrypted to the tenant's key, and stored in an append-only log. When the network returns, the queue is replayed in order. Conflicts are surfaced to the operator before settlement.

Card-not-present (typed-in) transactions are never permitted in offline mode.

SC / 07

Incident response.

On-call is a real human with a phone, not a status page. We notify affected operators within four hours of confirming a security incident, with a written postmortem within fifteen days.

On-call
24×7, single-tier rotation. Median acknowledgement under 5 minutes during event windows.
Notification
Affected operators contacted within 4 hours of incident confirmation. Status posted at status.getmerchantline.com.
Postmortem
Public, written, blameless. Published within 15 days for any sev-1 or sev-2 incident.
Tabletop
Quarterly drills covering payment outage, ticket replay attack, lost device, and credential theft.
SC / 08

Responsible disclosure.

If you've found something, write us. We respond to every report within two business days and publish a credit (with your permission) on resolution.

security@getmerchantline.com

PGP-encrypted reports preferred. We'll respond on your channel of choice within two business days.

Open an email
Fingerprint9F2B 4A1C 8E7D 6532 0BCA 4419 2D3F E1A8 7C90 64DA
Key ID7C9064DA
Created2025-08-14
TypeEd25519
Download public key →
 Talk to us

Need a deeper
review?

We share our SOC 2 readiness report, pen test summary, and DPA on request under NDA. Reach out from a corporate domain.

Request docs General contact