Overview

Many merchants currently perform payment transactions over the internet. In order to carry out this operation, merchants must store customer payment information (credit card, debit card, and ACH) on their internal systems. The storage of customer payment data on internal systems creates a liability which manifests into high audit costs (PCI and/or NACHA), IT costs, and lost opportunity costs.

Tangible Payments Secured Storage (“Secure Storage”) is a hosted solution for merchants to diminish this liability. Specifically, merchants can store all customer payment data in Secure Storage, a Tier 1 PCI DSS system for storing, querying, and retrieving customer payment data, as well as processing customer payments. Once payment data is stored, a token (which looks and behaves like a credit card number) is returned to the merchant. This token can be used to retrieve the stored payment data or even make a payment.

Tangible Payments Secured Storage integrated directly with Tangible Payments Gateway. Payment data stored within Secured Storage can be processed as a regular payment, without the need for the merchant to directly access the customer’s personal payment information (e.g., the real credit card number).

Secure Storage Functionality

The following section provides more details about the Tangible Payments Secure Storage solution.

Available Actions

Merchants can perform the following actions via our web API and web portal:

• Store payment data
• Retrieve stored payment data (using token)
• Query stored payment data
• Make a payment using stored payment data (using token)
• Make a payment and store in the same API

Store Payment Data

Merchants can store all types of payment data to Secure Storage, including:

• Credit card
• Debit card
• ACH

Upon successful storage of payment data within Secure Storage, a token is returned which can be used for additional actions. This token is described in further detail in sections below.

Retrieve Stored Payment Data (using Token)

Once payment data is stored within Secured Storage, it can be retrieved by using the token obtained from the initial storage of payment data.

Query Stored Payment Data

There are specific cases where merchants may wish to query stored data, instead of using the original token. For example, merchants may wish to query all payment data for a particular customer. All payment data can be queried, as well as all custom code fields (detailed below).

Make a Payment Using Stored Payment Data (Using Token)

Once payment data is stored within Secure Storage, payments can be processed simply by using the original token. Payments are processed through Tangible Payments Gateway (a Tier 1 PCI DSS system), which allows merchants to process payment transactions with any bank or acquirer.

Make a Payment and Store in the same API

Merchants can also combine the first payment processed with the storage of the payment information for future use. This action allows merchants to decrease the number of API calls to the Secure Storage system. In addition, it guarantees that the payment information is valid, as only authorized payments will be stored within Secure Storage.

Token

Upon storage of payment data, a token is returned to the merchant. This token looks and acts like a credit card number (even for ACH payments). Specifically, the token is a 16 digit number (even for AMEX cards) with a MOD10 check.

The following describes the token in detail:

• 10 digits: random. (Random sequence is unique per merchant.)
• 4 digits: last 4 digits of card
• 1 digit: card/account type (3=AMEX, 4=Visa, 5=MAST, 6=DISC, 9=ACH)
• 1 digit: MOD10

Custom Code Fields

In addition to storing payment data, the Secure Storage API (and portal) accepts 10 custom code fields. These fields can be used to store internal merchant fields (e.g., customer id, or invoice number), or any 100‐character field.

In addition to being useful when querying stored payment data, these custom code fields will be sent to the Tangible Payments Gateway during the processing of a payment (they can also be overwritten) so that merchants can link data to their internal system throughout the complete payment lifecycle.

Secure Storage Process Flow

The following section provides more details about the process flow of Secure Storage.

Existing Merchant Scenario / Process Flow

Most merchants are hosting their own portal and/or payment collection system. Within this system, merchants are storing customer data, personal credit card data, and payment results.

The following depicts the flow of data through a typical merchant setup:

Figure 1: Sample Existing Merchant Setup

1. Customer logs into the merchant portal or system and registers for a new account.
2. Customer store personal payment data (e.g., credit card) within the merchant portal. The portal stores the payment data within a merchant database for future lookup.
3. Merchant system performs authorization and settlement via a merchant processor (acquirer or ACH processor) and obtains a result.
4. Result from authorization/settlement is stored within the merchant database.

Tangible Secure Storage

Tangible Secure Storage allows merchants to outsource the storing of the credit card data (as well as make payments) via a hosted online web API and portal. There are several different scenarios in which a merchant can use Secure Storage.

• Secure Storage (Merchant Initiated Payment)
• Secure Storage (End‐To‐End)

Secure Storage (Merchant Initiated Payment)

In this scenario, the merchant wants to outsource the storage of customers’ private payment data, but still use their existing infrastructure for payment processing.

The following depicts the flow of data using Secure Storage as a storage option only:

1. Customer logs into the merchant portal or system and registers for a new account.
2. No private payment data is stored within the merchant’s database.
3. Private payment data is sent to Tangible Payments Secure Storage. In response, a token that looks and acts like a credit card number (16 digit number) is returned. In the future, the token is used to retrieve the private payment data whenever a merchant wishes to perform a transaction.
4. The token returned from Secure Storage is stored to the merchant database, as this links the customer to his/her private payment data (e.g., credit card number).
5. The private payment data (customer entered, or retrieved from Secure Storage) is sent to the payment processor as before.
6. The result of the payment processing is stored as before.

Secure Storage (End­-To­-End)

In this scenario, the merchant wants to outsource the majority of the payment flow. Specifically, the merchant wants to outsource the storage and payment processing to a third party system. Tangible Payments Secure Storage provides this end‐to‐end solution.

The following depicts the flow of data using Secure Storage as an end‐to‐end solution for payments:

1. Customer logs into the merchant portal or system and registers for a new account.
2. No private payment data is stored within the merchant’s database.
3. Private payment data is sent to Tangible Payments Secure Storage.
4. The payment is processed in real‐time (for credit card and debit card) and the results are stored within the payment system. If the payment is successful, the payment information is stored in Secure Storage. If the payment is not successful, the payment is not stored in Secure Storage. Payment data and Secure Storage Token are returned to the merchant system.
   • In addition, once the customer’s private payment data is stored within Secure Storage, the token can also be used to initiate payments against the payment data.
5. The token returned from Secure Storage is stored to the merchant database, as this links the customer to his/her private payment data (e.g., credit card number). In addition, a transaction ID (and transaction status) is also returned which links the custom to the payment. Both the token and the transaction ID are stored in the merchant database.
6. Finally, a lockbox file is sent to the customer with information regarding updates to transactions due to settlement process (for the ACH process). This lockbox will contain a list of transaction IDs and their latest status.