Outbound Connection
Our outbound connection uses an outbound/forward proxy.
What does it allow you to do?
Like the inbound connection, the outbound/forward proxy allows you to rewrite requests and responses on the fly.
Lets you operate on data outside of the scope of your backend systems.
Set/Change/Strip Headers - perform any operation on the payload.
Modify the payload, even if it's not a strict redaction/replacement.
Perform Edge Computing, as needed for computing outside of the scope of your system (enterprise plans)
Adds an additional layer of security requiring proxy-authorization credentials and a root certificate to be set.
Is used to integrate into third party services and allows for configurations that are processor specific as mentioned in the integrations page.
Our outbound/forward proxy also allows for IP Anonymization as an additional upgrade.
How does it work?
The outbound/forward proxy directs traffic between your server (outbound) traffic, the VGS vault (where sensitive data is stored), and your third party integration
Example:
BEFORE: server.foo.com → api.worldpay.com
AFTER: server.foo.com →
<VAULT_ID>
.<ENVIRONMENT>
.verygoodproxy.com → api.worldpay.com
To achieve that you should set your server to send traffic through our outbound/forward proxy and create routes, filters and operations for your different API endpoints.
TLS Certificates
The outbound/forward proxy requires a TLS certificate. We have a different server certificate for each environment, SANDBOX and LIVE. You can find these certificates within the 'Code snippets' section of your dashboard.
Try it out
Download and use TLS certificate in your application. The certificate is the same for all Sandbox Vaults.
-----BEGIN CERTIFICATE-----
MIID2TCCAsGgAwIBAgIHAN4Gs/LGhzANBgkqhkiG9w0BAQ0FADB5MSQwIgYDVQQD
DBsqLnNhbmRib3gudmVyeWdvb2Rwcm94eS5jb20xITAfBgNVBAoMGFZlcnkgR29v
ZCBTZWN1cml0eSwgSW5jLjEuMCwGA1UECwwlVmVyeSBHb29kIFNlY3VyaXR5IC0g
RW5naW5lZXJpbmcgVGVhbTAgFw0xNjAyMDkyMzUzMzZaGA8yMTE3MDExNTIzNTMz
NloweTEkMCIGA1UEAwwbKi5zYW5kYm94LnZlcnlnb29kcHJveHkuY29tMSEwHwYD
VQQKDBhWZXJ5IEdvb2QgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsMJVZlcnkgR29v
ZCBTZWN1cml0eSAtIEVuZ2luZWVyaW5nIFRlYW0wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDI3ukHpxIlDCvFjpqn4gAkrQVdWll/uI0Kv3wirwZ3Qrpg
BVeXjInJ+rV9r0ouBIoY8IgRLak5Hy/tSeV6nAVHv0t41B7VyoeTAsZYSWU11deR
DBSBXHWH9zKEvXkkPdy9tgHnvLIzui2H59OPljV7z3sCLguRIvIIw8djaV9z7FRm
KRsfmYHKOBlSO4TlpfXQg7jQ5ds65q8FFGvTB5qAgLXS8W8pvdk8jccmuzQXFUY+
ZtHgjThg7BHWWUn+7m6hQ6iHHCj34Qu69F8nLamd+KJ//14lukdyKs3AMrYsFaby
k+UGemM/s2q3B+39B6YKaHao0SRzSJC7qDwbWPy3AgMBAAGjZDBiMB0GA1UdDgQW
BBRWlIRrE2p2P018VTzTb6BaeOFhAzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQE
AwIBtjAjBgNVHSUEHDAaBggrBgEFBQcDAQYIKwYBBQUHAwIGBFUdJQAwDQYJKoZI
hvcNAQENBQADggEBAGWxLFlr0b9lWkOLcZtR9IDVxDL9z+UPFEk70D3NPaqXkoE/
TNNUkXgS6+VBA2G8nigq2Yj8qoIM+kTXPb8TzWv+lrcLm+i+4AShKVknpB15cC1C
/NJfyYGRW66s/w7HNS20RmrdN+bWS0PA4CVLXdGzUJn0PCsfsS+6Acn7RPAE+0A8
WB7JzXWi8x9mOJwiOhodp4j41mv+5eHM0reMh6ycuYbjquDNpiNnsLztk6MGsgAP
5C59drQWJU47738BcfbByuSTYFog6zNYCm7ACqbtiwvFTwjneNebOhsOlaEAHjup
d4QBqYVs7pzkhNNp9oUvv4wGf/KJcw5B9E6Tpfk=
-----END CERTIFICATE-----
Run this sample code snippet in your terminal to see an example of data revealing.
curl https://echo.apps.verygood.systems/post --cacert path/to/sandbox.pem \
-x https://USiyQvWcT7wcpy8gvFb1GVmz:2b48a642-615a-4b3c-8db5-e02a88147174@tntsfeqzp4a.sandbox.verygoodproxy.com:8443 \
-H "Content-type: application/json" \
-d '{"account_number": "tok_sandbox_w8CBfH8vyYL2xWSmMWe3Ds"}'
For Spring-based Java applications, you can use our vgs-proxy-spring library.
Example Use Case: You need to send a customer’s Social Security number (SSN) to the Acme Background Check Service. You:
have previously collected the social security number
exchanged it for a VGS token to store in your database.
Now you should:
Create an outbound route in your VGS dashboard
Set Acme’s endpoint as the upstream host
Add a reveal filter in the request phase to replace the tokenized SSN with the real value
Add the route to your network as a forward proxy
The outbound/forward proxy directs traffic between your server (outbound), the VGS vault (where sensitive data is stored), and your third-party integrations, as illustrated by the image below.

Use this command for testing the setup to simulate your back end (using cURL)
`simulate-backend-integration`
How to implement?
We have several examples of API Call specific outbound implementations here.
`forward-implementation-example`
For many languages, setting the proxy as an environmental variable enables the outbound/forward proxy to be used at a framework or library level.
HTTP Basic Authentication
This enables a password of your VGS vault, so that only your application can reveal and access sensitive data. You must provide the username and password via the following URL format. https://<USERNAME>:<PASSWORD>@<VAULT_ID>.<ENVIRONMENT>.verygoodproxy.com:8443
Note: Some backend languages require you to access this url by passing auth in a different manner.
VGS outbound/forward proxy reveal operations require HTTP Basic Authentication using the username and password provided in the VGS dashboard.
It is up to you to protect these credentials; treat them like an API key. Please refer Basic Authentication for more information.
Tips on storing HTTP Basic Authentication Secrets Securely
Do not embed secrets directly in code.
Do not store secrets in files inside your application, including the application’s source tree.
If you do accidentally commit secrets to version control, revoke it immediately and generate a new one.
Ensure secrets do not appear in URLs or anywhere they can be captured in web server logs.
Review your code carefully and ensure it doesn’t contain secrets or any other private information before publicly releasing it.
Put the configuration file containing the secrets in the revision control ignore. This prevents committing them by mistake in the future.
Limit the usage of secrets
Restrict your secrets to be used by only the IP addresses, referrer URLs, and mobile apps that need them. Don't share your secrets with different applications. If more than one application uses the same API, register each application so you get a new set of secrets and update the secrets.
Delete unneeded secrets.
Update (Regenerate) your secrets periodically.
References:
Encrypted Communication
VGS supports encryption to protect communications between VGS and your web application. VGS supports the TLS cryptographic protocol. Support for anything less than TLS1.2 is officially deprecated.
For more information regarding TLS:
Alternative Using Reverse Proxy
If your server making outbound requests is already behind a proxy, it can be cumbersome to add a second, chained proxy. You can instead set up a VGS reverse proxy between your server and external services. This is simpler to implement, and suitable for testing, development, and building proof of concepts.
To implement, follow these steps:
If you already have an inbound route configured (which you likely do in order to securely collect PII), create a custom hostname for this route. For this example, suppose your custom hostname is backgroundcheck.yourcompany.com
Create an inbound route in your VGS dashboard
Set Acme’s endpoint as the upstream host
Set the route to allow requests to your custom hostname
Add a reveal filter in the request phase to replace the tokenized SSN with the real value
Modify your back end code to send the background check request to the custom hostname.
The data flow now looks like this.

To test the setup using cURL to simulate your back end, run this cURL command.
curl https://backgroundcheck.yourcompany.com/post -k \
-x https://tntsfeqzp4a.sandbox.verygoodproxy.com \
-X POST \
-H "Content-type: application/json" \
-d '{"ssn": "$VGS_TOKEN"}'
If you need any help setting up outbound connections, please contact us on site chat or at [email protected].
Last updated