Integration Methods

The AuricVault® tokenization API supports three integration methods:

  • Server-Side from any programming language capable of generating JSON and HTTPS POST calls.

  • Browser-Side JavaScript.

  • Custom iFrame.

Server-Side

Server-side integration allows both modern servers and legacy systems to integrate with the AuricVault® service. The integration method is a simple HTTPS POST call using JSON-RPC. Any current programming language can easily integrate with the service.

Server-side integration API calls include:

  • encrypt

  • decrypt

  • delete_token

  • token_info

  • touch_token

  • get_encrypt_session

  • get_decrypt_session

  • payment

  • store_token

  • generate_token

  • retrieve_token

  • update_token

NOTE: The get_encrypt_session and get_decrypt_session calls are a direct connectivity method, but only useful in conjunction with the browser-side JavaScript session_encrypt and session_decrypt calls.

Browser-Side Integration

Browser-side integration is typically JavaScript based, but you can use any browser-side programming technology. Browser-side API calls include:

  • session_encrypt

  • session_decrypt

Before using the session_encrypt and session_decrypt methods, your server must first make a server-side API call (get_encrypt_session or get_decrypt_session) to the AuricVault® service and obtain a sessionId.

When you make the get_xxx_session call, you pass your credentials to the AuricVault® service and receive back a sessionId. This sessionId is associated your credentials. The sessionId acts as your credentials for the session-based encrypt and decrypt calls.

NOTE: The sessionId can only be used once and must be used within ten (10) minutes of being created.

The browser-side token integration is an open API using industry-standard AJAX calls. It does not require a custom script from Auric. This gives you complete flexibility in how you design your form and how you store the sessionId needed by the session_encrypt or session_decrypt call.

Prudent Browser-Side Practice

Some browser-based tokenization services show an example input form such as this:

<form action="./submit/" method="POST">
    <label for="fullname">Full Name</label>
    <input type="text" name="fullname"> <br>

    <label for="ccnum">Credit Card Number</label>
    <input type="text" name="ccnum"><br>

    <input type="submit" value="Pay Now">
</form>

A JavaScript function is then attached to the Submit event. This function copies the credit card number, tokenizes it, and then either clear the credit card number field and replaces it with a token, or deletes the credit card field and inserts a new token field.

But what if your JavaScript is broken? What if a network failure caused a script load failure, or a browser update breaks your JavaScript on this page? Suddenly, the JavaScript no longer overrides the submit button’s default behavior and a credit card number is submitted to your server when the user clicks on the button – breaking your PCI compliance.

The AuricVault® service’s approach is to break the data entry form into multiple pieces and then have the JavaScript put the pieces back together. For example.

<form id="ccnum-form">
    <label for="ccnum">Credit Card Number</label>
    <input type="text" name="ccnum"><br>
</form>


<form id="main" action="./submit/" method="POST">
    <label for="fullname">Full Name</label>
    <input type="text" name="fullname"> <br>

    <input type="submit" value="Pay Now">
</form>

Note

The form for entering your credit card number does not have a submit button. The JavaScript triggered by your submit button can find the ccnum field in the ccnum-form form, tokenize it, add a token field to the main field, and ensure that only the token is ever submitted to your server. In this example, a credit card number can never be sent to your server in the case where your JavaScript is broken or failed to load.