This SDK makes it easy to integrate your .NET application with Heartland’s Portico Gateway API, as well as other APIs such as MasterPass and PayPal Express Checkout. Additionally, this SDK also facilitates integration with Heartland Secure: Out-of-Scope devices, providing for simple semi- integrated EMV acceptance, enabling a true single point of integration for omni-channel developers.
Supported features include:
- Card Not Present (eCommerce and mobile)
- Card Present (Retail and Restaurant)
- Secure Submit single-use tokenization and multi-use tokenization
- Heartland Secure End-to-End Encryption (E3)
- Credit, Gift & Loyalty,and eCheck/ACH
- Recurring Payments
- Direct Communication with Heartland's Out of Scope devices such as PaxS300
| Data Security | API Reference | Testing & Certification |
API Keys | Links |
|---|---|---|---|---|
| Register an Account Partner with Heartland |
####Developer Support
You are not alone! If you have any questions while you are working through your development process, please feel free to reach out to our team for assistance!
Installing the SDK into your solution is usually be done by either using NuGet, or by adding the project to your solution and creating a project reference. The project is compiled using Visual Studio 2015+ and requires .Net version 4.5 or later due to PCI DSS TLS 1.1+ requirements.
To Install via Nuget Manager Console :
PM> Install-Package SecureSubmit
Attempting to gather dependency information for package 'SecureSubmit.2.5.2' with respect to project 'TestConsoleApplication1', targeting '.NETFramework,Version=v4.5.2'
Attempting to resolve dependencies for package 'SecureSubmit.2.5.2' with DependencyBehavior 'Lowest'
Resolving actions to install package 'SecureSubmit.2.5.2'
Resolved actions to install package 'SecureSubmit.2.5.2'
Adding package 'Newtonsoft.Json.6.0.3' to folder 'c:\visual studio 2015\Projects\TestConsoleApplication1\packages'
Added package 'Newtonsoft.Json.6.0.3' to folder 'c:\visual studio 2015\Projects\TestConsoleApplication1\packages'
Added package 'Newtonsoft.Json.6.0.3' to 'packages.config'
Executing script file 'c:\visual studio 2015\Projects\TestConsoleApplication1\packages\Newtonsoft.Json.6.0.3\tools\install.ps1'
Successfully installed 'Newtonsoft.Json 6.0.3' to TestConsoleApplication1
Adding package 'SecureSubmit.2.5.2' to folder 'c:\visual studio 2015\Projects\TestConsoleApplication1\packages'
Added package 'SecureSubmit.2.5.2' to folder 'c:\visual studio 2015\Projects\TestConsoleApplication1\packages'
Added package 'SecureSubmit.2.5.2' to 'packages.config'
Successfully installed 'SecureSubmit 2.5.2' to TestConsoleApplication1
To install via a Project Reference:
- Download and unzip or, using Git, clone the repository where our .NET SDK is located on Github.
C:\>git clone https://github.com/hps/heartland-dotnet.git
Cloning into 'heartland-dotnet'...
remote: Counting objects: 762, done.
rRemote: Total 762 (delta 0), reused 0 (delta 0), pack-reused 762eceiving object
Receiving objects: 100% (762/762), 3.79 MiB | 0 bytes/s, done.
Resolving deltas: 100% (457/457), done.
Checking connectivity... done.
Checking out files: 100% (230/230), done.
To begin creating test transactions you will need to obtain a set of public and private keys. These are easily obtained by creating an account on our developer portal. Your keys are located under your profile information.
You will use your public key when implementing card tokenization and your private key will be used when communicating with our Portico Gateway. More details can be found in our documentation.
Note: Multi-Use tokenization is not enabled by default when creating an account. You can contact Heartland's Specialty Products Team to have this enabled. This is also true if you wish to use Gift & Loyalty, ACH, and Debit.
-
Secure Submit for eCommerce web or mobile applications ("card-not-present"), which leverages single-use tokenization to prevent card data from passing through the merchant or integrator's webserver. It only requires a simple JavaScript inclusion and provides two options for payment field hosting:
-
Self-Hosted Fields - this approach relies upon the standard, appropriately named, HTML form controls on the integrator's served web page.
-
Heartland Hosted Fields - this approach combines the Secure Submit service with iframes to handle presentation of the form fields and collection of sensitive data on Heartland servers. Since PCI version 3.1 the PCI Council and many QSAs advocate the iframe-based approach as enabling a merchant to more readily achieve PCI compliance via the simplified SAQ A-EP form. Check out the CoalFire's whitepaper for more information.
-
Heartland Secure for card-present retailers, hospitality, and other "POS" applications, comprises three distinct security technologies working in concert:
-
End-to-End Encryption (E3) - combines symmetric and asymmetric cryptography to form an "Identity-Based Encryption" methodology which keeps cardholder data encrypted from the moment of the swipe.
-
Tokenization - replaces sensitive data values with non-sensitive representations which may be stored for recurring billing, future orders, etc.
-
EMV - though less about data security and more about fraud prevention, EMV or chip card technology guarantees the authenticity of the payment card and is thus an important concern for retailers.
Depending on your (or your customers') payment acceptance environment, you may need to support one or more of these technologies in addition to this SDK. This SDK also supports the ability to submit cleartext card numbers as input, but any developer who does so will be expected to demonstrate compliance with PA-DSS. Likewise any third party integrator who is planning on handling cleartext card data on behalf of other merchants will be expected to demonstrate their PCI DSS compliance as a Service Provider prior to completing certification with Heartland.
If you implement Secure Submit tokenization for your web or mobile application you will never have to deal with handling a card number - Heartland will take care of it for you and return a token to initiate the charge from your servers.
Similarly, if you implement Heartland Secure with E3 (for both swiped and keyed entry methods) then your POS application will be out-of-scope for PA-DSS. Heartland Secure certified devices will only ever return E3 encrypted data which can safely be passed through your systems as input to this SDK. Heartland Secure devices include many popular models manufactured by PAX and Ingenico.
To summarize, when you create a paymentMethod using this SDK you have the following options for securely avoiding interaction with sensitive cardholder data:
-
Card data (track or PAN) may be sent directly from a web browser to Heartland, returning a SecureSubmit single use token that is then sent to your server.
-
Encrypted card data (track or PAN) may be obtained directly from a Heartland Secure device and passed to the SDK
Quick Tip: The included test suite can be a great source of code samples for using the SDK!
Note that our SDK provides a Fluent Interface which allows you to replace a charge call that looks like this:
HpsCharge response = Charge(15.01m, "USD", card, null, true, null, false)With one that reads like this:
HpsCharge response = creditService.Charge(15.01m)
.WithCard(card)
.WithCurrency("USD")
.WithAllowDuplicates(true)
.WithRequestMultiUseToken(true)
.Execute();Between the two samples you can more easily read and understand what the code is doing in the second example than the first. That is a big advantage and helps speed development and reduce errors when using methods that allow a large number of parameters.
Quick Tip: You can get a head start on your certification by reviewing the certification tests in the included test suite.
####Test Card Data
The following card numbers are used by our Certification environment to verify that your tests worked. Note that while variations (such as 4111111111111111) will work for general testing the cards listed below are required to complete certification. For card present testing Heartland can provide you with EMV enabled test cards.
| Name | Number | Exp Month | Exp Year | CVV | Address | Zip |
|---|---|---|---|---|---|---|
| Visa | 4012002000060016 | 12 | 2025 | 123 | 6860 Dallas Pkwy | 750241234 |
| MasterCard | 5473500000000014 | 12 | 2025 | 123 | 6860 Dallas Pkwy | 75024 |
| Discover | 6011000990156527 | 12 | 2025 | 123 | 6860 | 750241234 |
| Amex | 372700699251018 | 12 | 2025 | 1234 | 6860 | 75024 |
| JCB | 3566007770007321 | 12 | 2025 | 123 | 6860 | 75024 |
####Testing Exceptions
During your integration you will want to test for specific issuer responses such as 'Card Declined'. Because our sandbox does not actually reach out to card brands for authorizations we have devised specific transaction amounts that will trigger issuer response codes and gateway response codes. Please contact Heartland for a complete listing of values you can charge to simulate AVS, CVV and Transaction declines, errors, and other responses that you can catch in your code:
try
{
HpsCharge response = creditService.Charge(5.00m)
.WithTrackData(trackData)
.WithRequestMultiUseToken(true)
.Execute();
}
catch (HpsInvalidRequestException $e)
{
// handle errors for invalid arguments such as a charge amount less than zero dollars
}
catch (HpsAuthenticationException $e)
{
// handle errors related to your HpsServiceConfig (username, pw, api keys etc.)
}
catch (HpsCreditException $e)
{
// handle card-related exceptions: card declined, processing error, etc
}More exceptions can be found here.
All our code is open sourced and we encourage fellow developers to contribute and help improve it!
- Fork it
- Create your feature branch (
git checkout -b my-new-feature) - Ensure SDK tests are passing
- Commit your changes (
git commit -am 'Add some feature') - Push to the branch (
git push origin my-new-feature) - Create new Pull Request
####Included Test Suite
The included test suite can help ensure your contribution doesn't cause unexpected errors and is a terrific resource of working examples that you can reference. As mentioned earlier, the certification folder contains tests that mirror the types of requirements you will encounter when you certify your integration for production.