Working draft · For review · Not yet search-indexed
Secure endpoint forwarding

Card-program / network service: secure endpoint forwarding

Atlas of Payments · Draft prepared November 12, 2026

The short answer

A merchant or platform can ask a vaulting provider to forward a request to an authorized authorized endpoint. In a supported implementation, a forward proxy replaces permitted token references with vaulted PCI-sensitive fields before transmission. The application need not receive those plaintext fields. The receiving operation determines the result.

The operating model

Card-program / network serviceToken references stay in the merchant or platform application. A vaulting provider resolves permitted fields in its controlled environment and forwards to an authorized endpoint. A filtered response returns for reconciliation. Dashed lines indicate setup or response, not raw data.ATLAS OF PAYMENTS / CONTROL THE DATA PATH01 Merchant / platformToken reference + operation + account contextTokenized request02 Vaulting providerCONTROLLED SENSITIVE-DATA ENVIRONMENTForward proxy + vaultResolve permitted fields. Keep credentials scoped.Setup: allowed host + path + fields + callerApproved payload · TLS03 Authorized endpointValidate operation, account and permission04 Filter response + reconcileReservation referenceToken ≠ plaintext. Forwarded ≠ completed. PCI duties remain.
Illustrative forward-proxy path. Secure card collection occurs directly with the vaulting provider before this request. Dashed outcome path carries a filtered response, not permission to return card data.

What your team needs to do

  1. Use a supported collection flow that sends card data to the vaulting provider and returns a token reference to the merchant or platform.
  2. Authorize the destination hostname, API path, method, fields and caller. Configure tenant isolation and destination credentials.
  3. Send the tokenized request. The supported forward proxy resolves only permitted fields and forwards the payload over TLS to the authorized endpoint.
  4. Filter sensitive response fields where required. Reconcile reservation reference against the original request; a forwarded request is not proof of success.

Before you build

  • A configured hostname is not a complete API integration. Validate operation, payload schema, authentication and commercial permission.
  • The vaulting provider, forward proxy and receiving environment still handle sensitive data. PCI scope reduction depends on the actual architecture and controls; have scope assessed. Never retain CVV after authorization.
  • Protect credentials, allowlist destinations, prevent arbitrary forwarding, separate tenants, redact logs and test timeouts and idempotency. Some workflows require batch delivery rather than an HTTP proxy.

Apply it to your operating model

Merchant workflow

Merchant workflowToken references stay in the merchant or platform application. A vaulting provider resolves permitted fields in its controlled environment and forwards to an authorized endpoint. A filtered response returns for reconciliation. Dashed lines indicate setup or response, not raw data.ATLAS OF PAYMENTS / CONTROL THE DATA PATH01 MerchantToken reference + operation + account contextTokenized request02 Vaulting providerCONTROLLED SENSITIVE-DATA ENVIRONMENTForward proxy + vaultResolve permitted fields. Keep credentials scoped.Setup: allowed host + path + fields + callerApproved payload · TLS03 Authorized endpointValidate operation, account and permission04 Filter response + reconcileReservation referenceToken ≠ plaintext. Forwarded ≠ completed. PCI duties remain.
Illustrative forward-proxy path. Secure card collection occurs directly with the vaulting provider before this request. Dashed outcome path carries a filtered response, not permission to return card data.

A merchant uses its vault reference for card-program / network service. The vaulting provider forwards only the approved fields to the authorized endpoint. The merchant records the reservation reference, not a generic “success” flag.

Evidence limit: Illustrative architecture. Current endpoint schema, legal permission and production compatibility require validation.

Platform workflow

Platform workflowToken references stay in the merchant or platform application. A vaulting provider resolves permitted fields in its controlled environment and forwards to an authorized endpoint. A filtered response returns for reconciliation. Dashed lines indicate setup or response, not raw data.ATLAS OF PAYMENTS / CONTROL THE DATA PATH01 PlatformToken reference + operation + account contextTokenized request02 Vaulting providerCONTROLLED SENSITIVE-DATA ENVIRONMENTForward proxy + vaultResolve permitted fields. Keep credentials scoped.Setup: allowed host + path + fields + callerApproved payload · TLS03 Authorized endpointValidate operation, account and permission04 Filter response + reconcileReservation referenceToken ≠ plaintext. Forwarded ≠ completed. PCI duties remain.
Illustrative forward-proxy path. Secure card collection occurs directly with the vaulting provider before this request. Dashed outcome path carries a filtered response, not permission to return card data.

A platform performs the same workflow for one merchant account. Merchant-specific credentials, token permissions and destination rules isolate the request. The platform reconciles the response to that merchant’s record.

Evidence limit: One merchant’s token or account permission does not authorize another merchant’s transaction.

Measure the right outcome

Correct, reconciled reservation reference results / eligible attempts. Keep delivery, business outcome and money movement separate.

Questions operators ask

Does a listed endpoint prove the workflow is ready?

No. Confirm the precise operation, payload schema, caller permission, destination credentials and commercial approval.

Does distribution remove PCI or authentication requirements?

No. Outsourcing card storage does not remove every PCI obligation, and distribution does not complete 3-D Secure or SCA.

Validation notes

These vendor-neutral drafts describe architectural patterns, not certified integrations. A forward proxy can resolve token references for permitted outbound requests; inbound capture typically uses a separate collection or reverse-proxy flow. Validate exact behavior, endpoint contracts and permission. Some workflows need asynchronous batch transfer rather than HTTP forwarding. Industry outlines still need jurisdiction-specific review.

Make the next decision concrete

Write down the business model, account owner, required operation, permitted data and proof of completion. Resolve those five points before comparing providers.

Compare another use case →