Card Issuing
Issuing a payment card to a consumer consists of three phases:
Collecting data about the prospective cardholder to perform required KYC checks
Requesting a new card from the issuing platform
Providing the card details to the user
Each step traditionally involves handling sensitive data. The first step requires collecting sensitive personally identifiable information about the cardholder and sending it to various sources of data. The second requires receiving and storing the card number from the issuing platform. For the last step, many innovative issuers want to display the card number to the cardholder within a website or mobile application so that it can be used immediately.
You can use VGS at every step of the way to handle sensitive data on your behalf, relieving yourself of the security considerations involved. Here’s how.
Collecting PII for KYC
Network proxies are the core of VGS’s functionality. Our reverse proxy intercepts your incoming traffic and replaces sensitive data with aliases. The real data lives inside VGS’s secure vault. Your network, code, and databases only ever interact with the aliases.
The following cUrl command represents a request to your API containing sensitive data, likely from a browser on your prospective cardholder’s machine containing information they typed into your website.
curl https://<API>/
-H "Content-type: application/json"
-d '{"ssn": "078-05-1120"}
Let’s configure VGS to store that social security number on your behalf. Inside the VGS dashboard, create an inbound route with your API URL as the upstream host. Then, add the following filter:
Three key things about this filter:
It applies to the request phase - i.e. the request from the browser to your API
It performs a redaction, meaning the proxy will store the desired data in the VGS vault, and replace it in the request with an alias
The JSON path expression designates the top level “ssn” field for redaction
To use this route, your client-side code, which is your API consumer, sends the request to the VGS proxy URL instead of your API URL. The representative cUrl command looks like this:
curl https://<VAULT_ID_NO_VALUE>.sandbox.verygoodproxy.com
-H "Content-type: application/json"
-d '{"ssn": "078-05-1120"}
VGS stores the SSN in your designated vault, rewrites the request body, and sends the result to your server.
{"ssn": “tok_abc"}
Sending PII to Third Parties for Data
Within your environment, you can use the VGS aliases in place of the real data. Your third parties, however, need the real data in order to send you the information you need. You can use the VGS forward proxy to send them the PII you collected in Step 1 while still not having to interact with sensitive data yourself.
Consider the example of obtaining the cardholder’s credit report. There are a few APIs that will send it to you in exchange for a social security number.
The following cUrl command is representative of a request your server would send to such an API
curl https://<CREDIT_REPORTING>/
-H "Content-type: application/json"
-d '{"ssn": "078-05-1120"}'
However, your server does not have that SSN - it has a VGS alias tied to the real value. To send the real SSN, you’ll need to configure the VGS forward proxy to reveal it to the credit reporting API.
Create an “outbound” route in the VGS dashboard like so:
Three key things to notice here:
Like our inbound filter, this one applies to the request phase. The request now, though, is from your system to the third-party API.
This filter performs a reveal operation. VGS will retrieve the real value from the vault and replace the alias in the request from your server with it.
As before, the JSON path expression designates the top-level “ssn” field for redaction
Here is a cURL representation of how your server can use this route:
curl https://<CREDIT_REPORTING>/
-H "Content-type: application/json"
-d '{"ssn": "tok_abc"}'
-x https://<CREDENTIALS>@<VAULT_ID_NO_VALUE>.SANDBOX.verygoodproxy.com:8443
The VGS proxy will replace “tok_abc” with the real SSN.
Note: The “-x” flag is how you route requests through a proxy while using cURL. In real life, you have many options for specifying a proxy - you can do it in code, as part of your network configuration, or in conjunction with other network proxies you’re already using.
Another thing to note is the different usage patterns between the reverse and forward proxies. As you will see in the following steps, the two proxies have identical functionality. The difference is in how you invoke them. The reverse proxy is intended for requests from outside your system to your server, which is why your API consumers use it by sending requests to its URL. On the other hand, the forward proxy is meant for requests originating within your system. That’s why it’s invoked as an authenticated network proxy - VGS ensures the requests are coming from you.
Obtain the Card Number from Your Issuing Platform
You decide that you have found a creditworthy individual to issue a card. The next step is to communicate with your issuing partner (such as Marqeta, I2C, or Galileo) to obtain the card details. These services will send the card number over HTTP, but you don’t want that data in your systems. The solution is to route your outbound requests to the issuing platform through the VGS forward proxy, so it can redact the card data in the responses.
The following cUrl command and response represent your server’s communication with the issuing platform without VGS:
curl https://<ISSUING_PLATFORM>/cardNumber
{"pan": “4111111111111111"}
To keep the card number out of your environment, add a second outbound route in your VGS dashboard. Create a filter like this:
Three key elements to this filter:
Phase is set to “response” because the sensitive data is in the response your server receives from the issuing platform.
The operation is a redaction, so the real card number will live inside the VGS vault
The filter operates on the “pan” field in the JSON object.
Your communications with the issuing platform now look like this:
curl https://<ISSUING_PLATFORM>/cardNumber
-x https://<CREDENTIALS>@<VAULT_ID_NO_VALUE>.SANDBOX.verygoodproxy.com:8443
{"pan": “tok_xyz"}Display the Card Number to the Cardholder
Finally, your website requests the card number from your server to display it to the cardholder. Without VGS, the following represents the communication between your cardholder’s browser and your server:
curl https://<API>/cardNumber{"pan": “4111111111111111"} Now that your server does not have the real card number, you’ll need VGS to send the real card number to your cardholder. The request originates from outside your system, so this is a job for the reverse proxy. Add a second filter to the inbound route you created in Step 1 like so:
Three key elements to this filter:
Phase is set to “response” because the sensitive data is in the response your server sends to the cardholder.
The “Operation” is configured to reveal the real card number
The filter operates on the “pan” field in the JSON object.
The request from the browser to your server looks like this:
curl https://<VAULT_ID_NO_VALUE>.sandbox.verygoodproxy.com/cardNumberThe response from your server looks like this:
{"pan": “tok_xyz"} The proxy rewrites this response, so what the browser gets is this:
{"pan": “4111111111111111"}Your cardholder is looking at a brand new card you issued them. However, thanks to VGS, you did not have to interact with any sensitive data at any step of the way.
Descope Your Client-Side Code with VGS Collect and VGS Show
VGS provides a set of UI components that isolate your website or mobile app from sensitive data. VGS Collect replaces your forms with VGS-controlled components, so that an attacker cannot steal data from the inputs by compromising your client-side code. VGS Show is required to keep your client-side code out of PCI scope if you are displaying card data in your website or mobile app. The library provides VGS-controlled components that retrieve data from your inbound routes so that your client-side code is not exposed to it.
Last updated