VGS Migration Process
Overview
Data is never exposed outside of an approved content delivery environment (CDE). VGS works with secure environments like a SFTP server or to a secure drop box provided by a PCI compliant third party provider.
All files are encrypted with VGS’ public PGP key.
Encrypted files are downloaded only on hardened machines.
Decryption is automated with our private key and vaulted within a limited access VGS organization.
Decryption cannot happen outside of VGS’ CDE.
After migration and verification the original file is securely deleted from all locations (processor SFTP, if applicable, workstation, and VGS CDE).
Migrations
There are usually two flows for migrating tokens from a payment service provider (PSP).
CASE 1 (one migration). Process transactions in parallel with new customers on VGS while existing customers continue to use the original flow to your provider (i.e. Adyen, CyberSource, Stripe, etc.). After we migrate the tokens from your provider and you have imported it into your database, going forward you would transition customers to the latest version of your application in order to complete all transactions through VGS.
CASE 2 (multiple migrations). If you do two separate migrations you’ll need to tell the provider the list of customer/token ids you want to migrate in the first migration, and after that is completed provide the rest of the customer ids you wish to migrate over from the provider. We’re assuming these two migrations are happening because you are handling the processing on the backend to your existing provider and VGS in order to properly charge the customers — once the migrations are complete all transactions flow through VGS (basically no difference to the customers on the frontend of the application).
How VGS migrates Personal Account Numbers (PANs) and/or Card Holder Data (CHD)?
Part 1: Introduce PSP to VGS
Connect with the PSP support person/account manager who will help with the migration.
Inquire if PSP can set up a SFTP server for VGS to download the file from. For example, Stripe provides the VGS encrypted files held on a SFTP server they host. If the 3rd party is not able to provide, or there is a long wait time, VGS can provision a SFTP server on their behalf.
The VGS’ public PGP key. Required to encrypt the CSV file they upload.
Clarify the format of the import CSV file. Here's an example of a CSV file from Adyen:
1 - card - Static String
2 - MerchantAccount - String
3 - shopperemail - String
4 - shopperreference - String
5 - recurringdetailreference - (Adyen internal 16 digit reference)
6 - recurring contract type - 'RECURRING' else 'RECURRING,ONECLICK'
7 - expirymonth - 2 Digits
8 - expiryyear - 2 Digits
9 - holdername - String
10 - CARDNUMBER - digits\
Please specify the fields to be aliased/tokenized with VGS by confirming the VGS alias formats you require.
We recommended the use of the 'Generic - VGS Alias', or if last 4 of the card is required 'Payment Card - Prefixed, Luhn Valid, 19 Digits Fixed Length'.
Part 2: VGS migration
VGS support validates the SFTP Proxy within a sandbox vault with the expected file migration format and the expected VGS aliases.
VGS support downloads the encrypted file from the SFTP (or alternative CDE) provided by the PSP or by VGS.
VGS processes the decrypted file automatically via the SFTP Proxy on the customer's live vault.
VGS provides original file with the sensitive column(s) tokenized with a VGS alias onto a SFTP server (or alternative CDE) provided by the customer or by VGS.
Customer maps the file data into existing records within your database.
What's next?
Last updated