vaulted_token; Yuno replaces those references with the real card data inside its secure environment and forwards the request to the destination. The raw card number never touches your infrastructure, so your PCI scope does not change.
RequirementsThe PCI Proxy works with cards you have already stored with Yuno. Cards are stored when a customer saves a payment method during checkout, or when you enroll one through the Enroll Payment Method endpoint.
How it works
- Your server sends an HTTPS request to
https://api.y.uno/v1/pci-proxy, authenticated with your standard Yuno API credentials. - You put the full destination URL (including its path and query) in the
yuno-proxy-urlheader, and reference card data in the request body or headers using expressions such as{{vaulted_token.<TOKEN>.number}}. - Inside Yuno’s PCI environment, the proxy resolves each expression to the real card data, then forwards your request — same method, headers, and body — to the destination over TLS.
- The destination’s response is returned to you, along with diagnostic headers that tell you what the proxy did.
Card data in responses
If a destination echoes a full card number back in its response, returning it to you would put your systems back in PCI scope. To prevent that, the proxy scans each response for card numbers — the one it just injected, plus any other valid card number. By default the proxy redacts them, leaving only the last four digits, and reports how many in theyuno-proxy-response-redactions response header; a non-zero value is a sign your destination is returning card data you should not receive. Depending on your account’s configuration, the proxy may instead reject any response that contains card data with 502 RESPONSE_BLOCKED rather than redacting it.
Card data you can reference
| Expression | Resolves to |
|---|---|
{{vaulted_token.<TOKEN>.number}} | The card number (PAN) |
{{vaulted_token.<TOKEN>.expiration_month}} | Two-digit expiration month (MM) |
{{vaulted_token.<TOKEN>.expiration_year}} | Four-digit expiration year (YYYY) |
{{vaulted_token.<TOKEN>.holder_name}} | The cardholder name |
<TOKEN> must be a vaulted_token that belongs to your account. A token that does not exist or belongs to another account is rejected with EXPRESSION_RESOLUTION_FAILED, before any card data is read.
Security code (CVV) is not supportedCard networks do not allow the security code to be stored after a payment is authorized, so a stored payment method has no CVV to inject. The proxy does not support a
security_code field.Your PCI scope
When you use the PCI Proxy together with Yuno’s SDKs to collect cards, raw card data never enters your systems — it flows from the customer to Yuno, and from Yuno to the destination you choose. Most merchants operating this way qualify for the SAQ A self-assessment. See PCI Compliance for the complete picture of how Yuno reduces your PCI scope.Security controls
- HTTPS only. The proxy connects to destinations over TLS 1.2 or higher, on port 443 only. Destinations must be public DNS hostnames — IP addresses and internal networks are rejected.
- Credential isolation. Your Yuno API credentials and all
yuno-*headers are stripped before the request is forwarded. The destination only sees the headers you intend it to see. - No storage, no logging. The proxy holds card data in memory only for the lifetime of the request. Request and response bodies are excluded from logs and traces.
- Full audit trail. Every invocation produces an audit record (who, when, destination, outcome — never card data) and is returned to you with a unique
yuno-proxy-request-id.
Limits
| Limit | Value |
|---|---|
| Request and response body size | 1 MB |
| Distinct vaulted tokens per request | 20 |
| Destination timeout | 30 seconds by default, configurable up to 120 with the yuno-proxy-timeout header |
| Supported methods | GET, POST, PUT, PATCH, DELETE |