PCI DSS

VINR is built so that raw cardholder data never touches your servers. By keeping payment details inside VINR's vault and exchanging them for tokens, most integrations qualify for the lightest self-assessment. This page explains what VINR carries for you, what stays your responsibility, and how to keep that boundary intact.

This page is informational and not legal advice; consult your compliance counsel for binding decisions.

VINR's PCI statusAskCopy

VINR operates as a PCI DSS Level 1 Service Provider — the highest assurance tier, covering the largest transaction volumes. We are assessed annually by a Qualified Security Assessor (QSA), undergo quarterly network scans by an Approved Scanning Vendor, and maintain a current Attestation of Compliance (AOC).

Because VINR stores, processes, and transmits cardholder data on your behalf, the heavy lifting — encrypted vaults, key rotation, segmented networks, intrusion monitoring — is ours. Your obligation is to ensure card data flows only through VINR's collection surfaces and never lands in your own systems, logs, or analytics.

Your scope by integration typeAskCopy

How much PCI scope you carry depends entirely on how card data is captured. The table below maps each VINR integration to the most likely Self-Assessment Questionnaire (SAQ) and the question count you face.

The pattern is simple: if the card number is tokenized before it reaches your backend, you stay in SAQ A territory. The moment a Primary Account Number (PAN) transits your servers, you fall into SAQ D and inherit dozens of additional controls.

Keeping card data off your serversAskCopy

The safe pattern collects the card on a VINR-hosted surface, receives back only a token, and uses that token for every subsequent call. Tokens carry no sensitive data and are safe to log and store.

import { Vinr } from '@vinr/sdk';

const vinr = new Vinr({ secretKey: process.env.VINR_SECRET_KEY });

// The browser (via Elements/Drop-in) returns a single-use token.
// Your server never sees the PAN, CVV, or expiry.
const payment = await vinr.payments.create({
  amount: 4999,                      // EUR 49.99 in minor units
  currency: 'eur',
  customer: 'cust_abc123',
  source: token,                     // "tok_..." from the client, NOT a card number
});

console.log(payment.id);             // "pay_..."

If you ever find yourself reading, transmitting, or persisting a 13-19 digit PAN in your own code, your integration has slipped out of SAQ A. Treat that as an incident.

Cardholder data handling rulesAskCopy

These rules apply regardless of integration type. Violating any one of them expands your scope or breaches the standard:

• Never store the full PAN in your database, files, or backups. Store VINR's pay_ / cust_ IDs and the returned card brand and last four instead.
• Never store the CVV/CVC after authorization — not even encrypted. PCI DSS prohibits it absolutely.
• Keep card data out of logs. Scrub request bodies before logging; never log the raw client token alongside other PII in a way that reconstructs a card.
• Use TLS everywhere. All VINR endpoints require TLS 1.2+; plaintext requests are refused.
• Display only safe fields. Show the brand and last four (returned on the payment object) when you need to reference a card to the customer.

Securing the integration boundaryAskCopy

The controls that remain yours center on the keys and callbacks that connect your systems to VINR.

const event = vinr.webhooks.verify(payload, signature); // throws if invalid
if (event.type === 'payment.completed') {
  // safe to act on
}

Annual requirementsAskCopy

Even on SAQ A, you have recurring obligations. Build these into your compliance calendar:

Next stepsAskCopy