For part 2 of this series, I will demonstrate how PayFabric’s wallet functions can be used to store the customer credit card information in a PCI compliant manner allowing customers to make future purchases quickly using a previously stored credit card.
Part 1 covered the rules and importance of PCI compliance for merchants, the primary of which is that merchant e-commerce sites should not be storing complete credit card numbers or security codes. The storing of such information is only allowed for payment processors that have met very high PCI certification requirements far above that of a merchant.
For merchant websites to offer this feature, they must utilize it through a payment processor or gateway to store the information. The security process works in that the entered credit card information to be stored is transmitted one time and a globally unique key (or token) is returned. The merchant can store this key which can be used to make future transactions against the store credit card. To help the customer reference a stored credit card and track expiration, the card type (Visa, MasterCard, etc.), expiration date, and the last four digits of the card number may be stored by the merchant. The key will only work with the merchant account that created it making them useless to any outside party as the keys cannot be used to perform transactions elsewhere. The storing of credit card information is a one-way process; there is no way to request the card information back from the key.
This process does not store the three digit CVC security code on the back of the card. Merchants can perform the CVC check once on the first customer transaction with the card before storing it, after which there are two options. They can require customers to re-enter the CVC code only on future transaction against the stored credit card key, or they accept future transactions against the card without CVC code verification.
Using PayFabric, the process of storing of a credit card to the wallet system is nearly identical to performing a payment as demonstrated back in part 1 in that it uses the “Card” structure of the JSON with one additional value indicating the type of tender. As with transactions, this process is completely independent of the chosen payment gateway. Using sample data, the JSON string to add a stored credit card for a John Doe, whose customer number is 1234567890, and visa credit card number 4111 1111 1111 111 expiring on 5/20 is:
{
“Tender”: “CreditCard”
“Customer”: “1234567890”,
“Account”: “4111111111111111”,
“CardName”: “Visa”,
“ExpDate”: “0520”,
“CardHolder” : {
“FirstName”: “John”,
“LastName”: “Doe”
},
“Billto” : {
“Customer”: “1234567890”,
“Line1”: “123 South Street”,
“Line2”: “Suite A”,
“City”: “Sample City”,
“State”: “MD”,
“Zip”: “12345”
}
} This structure is then sent to PayFabric using a REST API web request to the “wallet/create” URL in the exact same manner from Part 1. It uses a sample PayFabric device ID of 833a4856-d272-4efd-a0f5-9c4be9b251aa with the password of “devicePassword”. The example of this code in C# is below. To simplify this example, the RestSharp library is used which is available on NuGet. The “jsonTransaction” variable contains the above JSON data. Language classes can be used to model the JSON data and serialize it to a string. However, this must be done such that only the data fields being used are included in the JSON string as PayFabric will treat empty fields as submitted data. For C#, this can be done using the NewtonSoft JSON library which has the option to serialize C# classes to JSON skipping any NULL properties.
var client = new RestClient
("https://sandbox.payfabric.com/rest/v2/api/wallet/create");
var request = new RestRequest(Method.POST);
request.AddHeader("authorization",
"833a4856-d272-4efd-a0f5-9c4be9b251aa|devicePassword");
request.AddHeader("content-type", "application/json");
request.AddParameter("application/json",
jsonTransaction, ParameterType.RequestBody);
IRestResponse response = client.Execute(request);
if (response.StatusCode == HttpStatusCode.OK)
{
// Look at response JSON in response.Content for “Result” field.
}
else
{
// Handle error with error string in response.Content
} Like with transactions, PayFabric will respond with an HTTP status of OK if the request was processed successfully, i.e. the process completed without any errors from network connectivity, incorrect coding, invalid device id, password, etc. An HTTP status of ‘OK’ means everything is working correctly, and in this case, the HTTP response data will be a transaction response JSON data structure with the unique key for the stored credit card. If the HTTP status is not ‘OK,’ then the HTTP response data will be an error string, if applicable to the error situation.
A sample of the JSON transaction will look like is below with the “Result” value containing the unique key for the stored credit card information.
{
"Result": "1627aea5-8e0a-4371-9022-9b504344e724"
} PayFabric will only allow storing a particular credit card number and expiration date combination once. Attempting to store the same number and expiration again will return an error. Attempting to store an invalid credit card number will also return an error.
Updating any of the information for a prior stored credit card (other than the card number) can be done using the same JSON structure to the URL suffix “wallet/update”. A stored credit card can be deleted by calling the URL suffix “/v2/rest/api/wallet/delete/{id}” where {id} is the unique key to be deleted.
Once a key is made, payment transactions can be made in the exact same manner as demonstrated in Part 1. Except for this case, the “Card” structure will only contain one value, the ID field with the stored credit card key. An example the JSON structure to do the same $100 transaction demonstrated in part 1 using the stored credit card key is:
{
“Customer” = “1234567890”,
“Card”: {
“ID”: "1627aea5-8e0a-4371-9022-9b504344e724"
},
“Amount” = “100.00”,
“Currency” = “USD”
} If re-entry of the CVC security code is being required for stored cards than the “CVC” value should also be included in the “Card” structure along with the ID.
The next and final part of this series will show how to use PayFabric’s payment data hosting screens to have customers enter their credit card information in a popup window directly to PayFabric, reducing the coding time, and increasing PCI compliance to the lowest risk level currently attainable.
DAVID REED | .Net Developer
David joined KTL solutions in April 2016 and has quickly shifted into the development of custom website applications and eCommerce customizations for Dynamics GP integrations. Prior to KTL, he has over 20 years of professional experience working as a software development consultant in the railroad transportation sector, and in positions at fast paced startup companies, quickly adapting to different technologies and challenging environments. His development background includes web development in C#, T-SQL and Oracle database scripting, and development of complex C# and C++ based windows desktop applications and controls using various specialized APIs such as MAPI and DirectX. David has also worked on projects linking C# development with building automation hardware, electronic sensors, and device controls.
