payment-pci-security
PCI Compliance & Secure Proxy
When this skill applies
Use this skill when:
- Building a payment connector that accepts credit cards, debit cards, or co-branded cards
- The connector needs to process card data or communicate with an acquirer
- Determining whether Secure Proxy is required for the hosting environment
- Auditing a connector for PCI DSS compliance (data storage, logging, transmission)
Do not use this skill for:
- PPP endpoint contracts and response shapes — use
payment-provider-protocol - Idempotency and duplicate prevention — use
payment-idempotency - Async payment flows (Boleto, Pix) and callbacks — use
payment-async-flow
Decision rules
- If the connector is hosted in a non-PCI environment (including all VTEX IO apps), it MUST use Secure Proxy.
- If the connector has PCI DSS certification (AOC signed by a QSA), it can call the acquirer directly with raw card data.
- Check for
secureProxyUrlin the Create Payment request — if present, Secure Proxy is active and MUST be used. secureProxyUrlis only present in the Create Payment (authorize) request. Cancel, capture, settle, and refund operations do not carry card data and do not receive this field. Post-authorization calls go directly to the PSP API using credentials andoutbound-accesspolicies — this does not reduce PCI compliance because no card data is involved in those operations.- Card tokens (
numberToken,holderToken,cscToken) are only valid when sent through thesecureProxyUrl— the proxy replaces them with real data before forwarding to the acquirer. - Only
card.bin(first 6 digits),card.numberLength, andcard.expirationmay be stored. Everything else is forbidden. - Card data must never appear in logs, databases, files, caches, error trackers, or APM tools — even in development.
Hard constraints
Constraint: MUST use secureProxyUrl for non-PCI environments
If the connector is hosted in a non-PCI environment (including all VTEX IO apps), it MUST use the secureProxyUrl from the Create Payment request to communicate with the acquirer. It MUST NOT call the acquirer directly with raw card data. If a secureProxyUrl field is present in the request, Secure Proxy is active and MUST be used.
Why this matters Non-PCI environments are not authorized to handle raw card data. Calling the acquirer directly bypasses the Gateway's secure data handling, violating PCI DSS. This can result in data breaches, massive fines ($100K+ per month), loss of card processing ability, and legal liability.
Detection
If the connector calls an acquirer endpoint directly (without going through secureProxyUrl) when secureProxyUrl is present in the request, STOP immediately. All acquirer communication must go through the Secure Proxy.
Correct
async function createPaymentHandler(req: Request, res: Response): Promise<void> {
const { paymentId, secureProxyUrl, card } = req.body;
if (secureProxyUrl) {
// Non-PCI: Route through Secure Proxy
const acquirerResponse = await fetch(secureProxyUrl, {
method: "POST",
headers: {
"Content-Type": "application/json",
"X-PROVIDER-Forward-To": "https://api.acquirer.com/v2/payments",
"X-PROVIDER-Forward-MerchantId": process.env.ACQUIRER_MERCHANT_ID!,
"X-PROVIDER-Forward-MerchantKey": process.env.ACQUIRER_MERCHANT_KEY!,
},
body: JSON.stringify({
orderId: paymentId,
payment: {
cardNumber: card.numberToken, // Token, not real number
holder: card.holderToken, // Token, not real name
securityCode: card.cscToken, // Token, not real CVV
expirationMonth: card.expiration.month,
expirationYear: card.expiration.year,
},
}),
});
const result = await acquirerResponse.json();
// Build and return PPP response...
}
}
Wrong
async function createPaymentHandler(req: Request, res: Response): Promise<void> {
const { paymentId, secureProxyUrl, card } = req.body;
// WRONG: Calling acquirer directly, bypassing Secure Proxy
// This connector is non-PCI but handles card data as if it were PCI-certified
const acquirerResponse = await fetch("https://api.acquirer.com/v2/payments", {
method: "POST",
headers: {
"Content-Type": "application/json",
"MerchantId": process.env.ACQUIRER_MERCHANT_ID!,
},
body: JSON.stringify({
orderId: paymentId,
payment: {
// These are tokens but sent directly to acquirer — acquirer can't read tokens!
// And if raw data were here, this would be a PCI violation
cardNumber: card.numberToken,
holder: card.holderToken,
securityCode: card.cscToken,
},
}),
});
// This request will fail: acquirer receives tokens instead of real card data
// And the Secure Proxy was completely bypassed
}
Constraint: Secure Proxy applies ONLY to card authorization — not to post-auth operations
The secureProxyUrl field is present only in the Create Payment request (card authorization). Cancel, capture (settle), and refund requests do not include secureProxyUrl because they do not involve card data — they reference the transaction by tid, authorizationId, or paymentId.
Post-authorization calls MUST go directly to the PSP API using an ExternalClient with API credentials, authorized via outbound-access policies in manifest.json.
Why this matters
Attempting to route cancel/capture/refund through Secure Proxy will fail because secureProxyUrl is undefined in those requests. Architecturally, there is no PCI concern — only the authorization carries sensitive card data. Agents and developers who assume all PSP communication must go through Secure Proxy waste significant time debugging undefined proxy URLs.
Detection
If cancel, capture, or refund handlers reference secureProxyUrl, use SecureExternalClient, or attempt to route through Secure Proxy, STOP. Use ExternalClient with direct API calls for post-auth operations.
Correct — two-client architecture
// Authorization (Create Payment) — via Secure Proxy
import { SecureExternalClient } from "@vtex/payment-provider";
export class PspSecureClient extends SecureExternalClient {
public async authorize(data: object, secureProxyUrl: string) {
return this.http.post("/payments", data, {
secureProxy: secureProxyUrl,
} as any)
}
}
// Cancel, Capture, Refund — direct API calls
import { ExternalClient } from "@vtex/api";
export class PspClient extends ExternalClient {
public async capture(tid: string, amount: number) {
return this.http.post(`/payments/${tid}/capture`, { amount }, {
headers: { "X-API-Key": "..." },
})
}
}
Wrong
// WRONG — trying to use SecureExternalClient for all operations
async settle(request: SettlementRequest) {
// secureProxyUrl does not exist on SettlementRequest — this is undefined
await this.secureClient.capture(request.tid, request.value, request.secureProxyUrl)
}
Constraint: MUST NOT store raw card data
The connector MUST NOT store the full card number (PAN), CVV/CSC, cardholder name, or any card token values in any persistent storage — database, file system, cache, session store, or any other durable medium. Card data must only exist in memory during the request lifecycle.
Why this matters Storing raw card data violates PCI DSS Requirement 3. A data breach exposes customers to fraud. Consequences include fines of $5,000–$100,000 per month from card networks, mandatory forensic investigation costs ($50K+), loss of ability to process cards, class-action lawsuits, and criminal liability in some jurisdictions.
Detection
If the code writes card number, CVV, cardholder name, or token values to a database, file, cache (Redis, VBase), or any persistent store, STOP immediately. Only card.bin (first 6 digits) and card.numberLength may be stored.
Correct
async function createPaymentHandler(req: Request, res: Response): Promise<void> {
const { paymentId, card, secureProxyUrl } = req.body;
// Only store non-sensitive card metadata
await paymentStore.save(paymentId, {
paymentId,
cardBin: card.bin, // First 6 digits — safe to store
cardNumberLength: card.numberLength, // Length — safe to store
cardExpMonth: card.expiration.month, // Expiration — safe to store
cardExpYear: card.expiration.year,
// DO NOT store: card.numberToken, card.holderToken, card.cscToken
});
// Use card tokens only in-memory for the Secure Proxy call
const acquirerResult = await callAcquirerViaProxy(secureProxyUrl, card);
// Return response — card data is now out of scope
res.status(200).json(buildResponse(paymentId, acquirerResult));
}
Wrong
async function createPaymentHandler(req: Request, res: Response): Promise<void> {
const { paymentId, card } = req.body;
// CRITICAL PCI VIOLATION: Storing full card data in database
await database.query(
`INSERT INTO payments (payment_id, card_number, cvv, holder_name)
VALUES ($1, $2, $3, $4)`,
[paymentId, card.number, card.csc, card.holder]
);
// This single line can result in:
// - $100K/month fines from card networks
// - Mandatory forensic audit ($50K+)
// - Loss of card processing ability
// - Criminal liability
}
Constraint: MUST NOT log sensitive card data
The connector MUST NOT log card numbers, CVV/CSC values, cardholder names, or token values to any logging system — console, file, monitoring service, error tracker, or APM tool. Even in debug mode. Even in development.
Why this matters Logs are typically stored in plaintext, retained for extended periods, and accessible to many team members. Card data in logs is a PCI DSS violation and a data breach. Log aggregation services (Datadog, Splunk, CloudWatch) may store data across multiple regions, amplifying the breach scope.
Detection
If the code contains console.log, console.error, logger.info, logger.debug, or any logging call that includes card.number, card.csc, card.holder, card.numberToken, card.holderToken, card.cscToken, or the full request body without redaction, STOP immediately. Redact or omit all sensitive fields before logging.
Correct
async function createPaymentHandler(req: Request, res: Response): Promise<void> {
const { paymentId, card, paymentMethod, value } = req.body;
// Safe logging — only non-sensitive fields
console.log("Processing payment", {
paymentId,
paymentMethod,
value,
cardBin: card?.bin, // First 6 digits only — safe
cardNumberLength: card?.numberLength, // Safe
});
// NEVER log the full request body for payment requests
// It contains card tokens or raw card data
}
function redactSensitiveFields(body: Record<string, unknown>): Record<string, unknown> {
const redacted = { ...body };
if (redacted.card && typeof redacted.card === "object") {
const card = redacted.card as Record<string, unknown>;
redacted.card = {
bin: card.bin,
numberLength: card.numberLength,
expiration: card.expiration,
// All other fields redacted
};
}
return redacted;
}
Wrong
async function createPaymentHandler(req: Request, res: Response): Promise<void> {
// CRITICAL PCI VIOLATION: Logging the entire request body
// This includes card number, CVV, holder name, and/or token values
console.log("Payment request received:", JSON.stringify(req.body));
// ALSO WRONG: Logging specific card fields
console.log("Card number:", req.body.card.number);
console.log("CVV:", req.body.card.csc);
console.log("Card holder:", req.body.card.holder);
// ALSO WRONG: Logging tokens (they reference real card data)
console.log("Card token:", req.body.card.numberToken);
}
Preferred pattern
Secure Proxy data flow:
1. Gateway → POST /payments (with secureProxyUrl + tokenized card data) → Connector
2. Connector → POST secureProxyUrl (tokens in body, X-PROVIDER-Forward-To: acquirer URL) → Gateway
3. Gateway replaces tokens with real card data → POST acquirer URL → Acquirer
4. Acquirer → response → Gateway → Connector
5. Connector → Create Payment response → Gateway
Post-authorization data flow (no Secure Proxy):
1. Gateway → POST /payments/{id}/settlements → Connector
2. Connector → POST acquirer API directly (tid + amount, no card data) → Acquirer
3. Acquirer → response → Connector
4. Connector → Settlement response → Gateway
Detect Secure Proxy mode:
interface CreatePaymentRequest {
paymentId: string;
value: number;
currency: string;
paymentMethod: string;
card?: {
holder?: string; // Raw (PCI) or absent (Secure Proxy)
holderToken?: string; // Token (Secure Proxy only)
number?: string; // Raw (PCI) or absent (Secure Proxy)
numberToken?: string; // Token (Secure Proxy only)
bin: string; // Always present — first 6 digits
numberLength: number; // Always present
csc?: string; // Raw (PCI) or absent (Secure Proxy)
cscToken?: string; // Token (Secure Proxy only)
expiration: { month: string; year: string };
};
secureProxyUrl?: string; // Present when Secure Proxy is active
secureProxyTokensURL?: string; // For custom token operations
callbackUrl: string;
miniCart: Record<string, unknown>;
}
function isSecureProxyActive(req: CreatePaymentRequest): boolean {
return !!req.secureProxyUrl;
}
Build acquirer request using tokens or raw values:
function buildAcquirerRequest(paymentReq: CreatePaymentRequest) {
const card = paymentReq.card!;
return {
merchantOrderId: paymentReq.paymentId,
payment: {
// Use tokens if Secure Proxy, raw values if PCI-certified
cardNumber: card.numberToken ?? card.number!,
holder: card.holderToken ?? card.holder!,
securityCode: card.cscToken ?? card.csc!,
expirationDate: `${card.expiration.month}/${card.expiration.year}`,
amount: paymentReq.value,
},
};
}
Call acquirer through Secure Proxy with proper headers:
async function callAcquirerViaProxy(
secureProxyUrl: string,
acquirerRequest: object
): Promise<AcquirerResponse> {
const response = await fetch(secureProxyUrl, {
method: "POST",
headers: {
"Accept": "application/json",
"Content-Type": "application/json",
// X-PROVIDER-Forward-To tells the proxy where to send the request
"X-PROVIDER-Forward-To": process.env.ACQUIRER_API_URL!,
// Custom headers for the acquirer — prefix is stripped by the proxy
"X-PROVIDER-Forward-MerchantId": process.env.ACQUIRER_MERCHANT_ID!,
"X-PROVIDER-Forward-MerchantKey": process.env.ACQUIRER_MERCHANT_KEY!,
},
body: JSON.stringify(acquirerRequest),
});
if (!response.ok) {
const errorText = await response.text();
throw new Error(`Secure Proxy call failed: ${response.status} ${errorText}`);
}
return response.json() as Promise<AcquirerResponse>;
}
// For PCI-certified environments, call acquirer directly
async function callAcquirerDirect(acquirerRequest: object): Promise<AcquirerResponse> {
const response = await fetch(process.env.ACQUIRER_API_URL!, {
method: "POST",
headers: {
"Accept": "application/json",
"Content-Type": "application/json",
"MerchantId": process.env.ACQUIRER_MERCHANT_ID!,
"MerchantKey": process.env.ACQUIRER_MERCHANT_KEY!,
},
body: JSON.stringify(acquirerRequest),
});
return response.json() as Promise<AcquirerResponse>;
}
Safe logging utility:
function safePaymentLog(label: string, body: Record<string, unknown>): void {
const safe = {
paymentId: body.paymentId,
paymentMethod: body.paymentMethod,
value: body.value,
currency: body.currency,
orderId: body.orderId,
hasCard: !!body.card,
hasSecureProxy: !!body.secureProxyUrl,
cardBin: (body.card as Record<string, unknown>)?.bin,
// Everything else is intentionally omitted
};
console.log(label, JSON.stringify(safe));
}
Common failure modes
- Direct card handling in non-PCI environment — Calling the acquirer API directly without using the Secure Proxy. The acquirer receives tokens (e.g.,
#vtex#token#d799bae#number#) instead of real card numbers and rejects the transaction. Even if raw data were available, transmitting it from a non-PCI environment is a PCI DSS violation. - Using Secure Proxy for cancel/capture/refund — These operations do not receive
secureProxyUrland do not carry card data. Attempting to route them through Secure Proxy fails because the URL isundefined. UseExternalClientwith direct API calls for post-auth operations. - Storing full card numbers (PANs) — Persisting the full card number in a database for "reference" or "reconciliation". A single breach of this data can result in $100K/month fines, mandatory forensic audits, and permanent loss of card processing ability.
- Logging card details for debugging — Adding
console.log(req.body)orconsole.log(card)to troubleshoot payment issues and forgetting to remove it. Card data ends up in log files, monitoring dashboards, and log aggregation services. This is a PCI violation even in development. - Stripping X-PROVIDER-Forward headers — Sending requests to the Secure Proxy without the
X-PROVIDER-Forward-Toheader. The proxy does not know where to forward the request and returns an error. - Storing token values — Writing
card.numberToken,card.holderToken, orcard.cscTokento a database or cache, treating them as "safe" because they are tokens. Tokens reference real card data and must not be persisted.
Review checklist
- Does the connector use
secureProxyUrlwhen it is present in the Create Payment request? - Is
SecureExternalClientused only for Create Payment (authorize), not for cancel/capture/refund? - Do post-auth operations (cancel, capture, refund) use
ExternalClientwith direct API calls? - Is
X-PROVIDER-Forward-Toset to the acquirer's API URL in Secure Proxy calls? - Are custom acquirer headers prefixed with
X-PROVIDER-Forward-when going through the proxy? - Is only
card.bin,card.numberLength, andcard.expirationstored in the database? - Are card numbers, CVV, holder names, and token values excluded from all log statements?
- Is there a redaction utility for safely logging payment request data?
- Does the connector support both Secure Proxy (non-PCI) and direct (PCI-certified) modes?
- Are error responses logged without including the acquirer request body (which contains tokens)?
Related skills
payment-provider-framework— PPF IO wiring, two-client pattern (SecureExternalClient+ExternalClient), andoutbound-accesspoliciespayment-provider-protocol— Endpoint contracts and response shapespayment-idempotency—paymentId/requestIdidempotency and state machinepayment-async-flow— Async payment methods, callbacks, and the 7-day retry window
Reference
- Secure Proxy — Complete Secure Proxy documentation including flow diagrams, request/response examples, custom tokens, and supported JsonLogic operators
- PCI DSS Compliance — PCI certification requirements, AOC submission process, and when Secure Proxy is mandatory
- Implementing a Payment Provider — Endpoint implementation guide including Create Payment request body with secureProxyUrl and tokenized card fields
- Payment Provider Protocol (Help Center) — Protocol overview including PCI prerequisites and Secure Proxy requirements
- Payment Provider Framework — VTEX IO framework for payment connectors (Secure Proxy mandatory for all IO apps)
- PCI Security Standards Council — Official PCI DSS requirements and compliance documentation