One major challenge with creating a custom E-commerce system is interfacing with the chosen payment gateway to process credit card payments, such as Authorize.Net, Moneris, etc. Each has their own API to interface to the service; however investing time developing to a single interface means becoming locked into that gateway provider. What happens down the road if the scenario arises for changing providers? What if this needs to be done quickly? What if support for multiple providers is needed? Each scenario would be hampered by the time and cost of developing code to interface with another provider plus testing time. On top of this is the risk of potential website disruptions or unforeseen bugs from these changes. In the world of 24/7 online retail, customers will ditch a broken merchant website in an instant to make their purchase from another and never look back.
Fortunately, there are payment processing solutions to address this, such a Braintree and PayFabric. For a reasonable monthly fee, these services offer a common simplified API interface that works with all the major payment gateway providers. They also provide for storing of credit cards and hosted payment entry pages for PCI DSS compliance.
Before continuing, it’s important to mention the significance PCI DSS. PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of rules that all companies, regardless of size, must follow when accepting credit card payments. Compliance comes in different levels based on how data is handled, and each carries a risk level and responsibility to perform certain tasks to ensure data security. Both Braintree and PayFabric have PCI Level 1 certification and make this certification document visible on their website. For a merchant website to reach the lowest tier of risk they must follow certain guidelines, the primary of which are:
- Credit card data is taken and transmitted in a secure manner (SSL and web security guidelines)
- Not storing credit card account numbers (last 4 digits is allowed only) or the 3-digit security codes on the back of the card. This data should only be held in memory long enough to perform the transaction.
- Any payment gateways or services used that handle credit card data must also be PCI compliant.
Not following PCI guidelines and having a security breach can result in significant fee increases or termination of payment gateway access. Documentation of PCI compliance is available on an official website.
Now let’s do a simple demonstration of how a common payment service can help make coding for payment processing easy and not lock you into using any particular payment gateway. For this blog post, we’ll be using the PayFabric API as an example. Developers can obtain a free Sand Box account. Once an account is created, payment gateway login information and devices can be setup. Devices each carry a unique device ID and password and to manage how payments are handled from different sources. The device ID and password should only be used in server side code, and ideally stored in a configuration file or database not accessible to the internet. For this example, a device id of 833a4856-d272-4efd-a0f5-9c4be9b251aa is used with the password “devicePassword”.
The PayFabric API uses JSON, a very simple hierarchy data structure. The PayFabric API documentation describes all the fields for a payment transaction and which are required or optional. At minimum, this is the card number, expiration data, customer name, and billing address. Using sample data, the JSON string to create transaction of $100 for a John Doe, whose customer number is 1234567890, and visa credit card number 4111 1111 1111 111 expiring on 5/20 is:
{
“Customer” = “1234567890”,
“Card”: {
“Customer” = “1234567890”,
“Account” = “4111111111111111”,
“CardName” = “Visa”,
“ExpDate” = “0520”,
“CVC” = “123”,
“CardHolder” : {
“FirstName”: “John”,
“LastName”: “Doe”
},
“Billto” : {
“Customer” = “1234567890”,
“Line1” = “123 South Street”,
“Line2” = “Suite A”,
“City” = “Sample City”,
“State” = “MD”,
“Zip” = “12345”
}
},
“Amount” = “100.00”,
“Currency” = “USD”
} This structure is then sent to PayFabric using a REST API web request. An example of this code in C# is below. To simply 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/v1/api/transaction/process")
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 payment transaction response JSON in response.Content
}
else
{
// Handle error with possible error string in response.Content
} PayFabric will respond with an HTTP status of OK if the request was processed successfully, i.e. the transaction 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 indicating the results of the payment transaction itself. If the HTTP status is not OK, then the HTTP response data will be an error string, if applicable to the error situation.
The JSON transaction response will look like below. This sample response indicates the transaction was approved along with the address verification results, and authorization/transaction numbers from the gateway.
{
"AVSAddressResponse":"Y",
"AVSZipResponse":"Y",
"AuthCode":"010010",
"CVV2Response":"Y",
"IAVSAddressResponse":"Y"
"Message":"APPROVED",
"OriginationID":"987220999",
"RespTrxTag":"",
"ResultCode":"0",
"Status":"Approved",
"TrxDate":"",
"TrxKey":"140500229001"
} With just a small amount of code, a basic framework to perform payments is now in place that doesn’t have to be changed should the payment gateway change in the future.
The next part of this series will cover how to use the PayFabric wallet functions to give customers the option of saving their credit card information for use future transactions in a secure PCI compliant manner. Part 3 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.
