Heartland iOS SDK

This SDK makes it easy to integrate your iOS apps with Heartland's Portico Gateway API. 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

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!

Requirements

Adding this pod will also include the XMLDictionary, and Masonry cocoapod as a dependency.

Installation

Heartland-iOS-SDK is available through CocoaPods. To install it, simply add the following line to your Podfile and run "pod update":

pod 'Heartland-iOS-SDK'

For iOS 9 only: Whitelist heartlandportico.com

If you compile your app with iOS SDK 9.0 or above, you will be affected by App Transport Security. Currently, you will need to whitelist heartlandportico.com in your app by adding the following to your application's plist:

<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
    <dict>
        <key>heartlandportico.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSTemporaryExceptionMinimumTLSVersion</key>
            <string>1.2</string>
            <key>NSTemporaryExceptionRequiresForwardSecrecy</key>
            <false/>
        </dict>
    </dict>
</dict>

API Keys

Integrations that use card not present transactions, such as eCommerce web applications, will use API keys to authenticate. There are exceptions, such as card present POS integrations. For these projects please contact us for more information.

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.

Data Security

If your app stores, processes, or transmits cardholder data in cleartext then it is in-scope for PA-DSS. If your app is hosted, or the data in question otherwise comes into your organization, then the app and your entire company are in-scope for PCI DSS (either as a merchant or a service provider). Heartland offers a suite of solutions to help keep integrators' applications and/or environments shielded from cardholder data, whether it motion or at rest.

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

Documentation and Examples

You can find the latest SDK documentation along with code examples on our Developer Portal. In addition you can find a working example in the SDK itself under the example folder. To run the example project, clone the repo, and run pod install from the Example directory first.

Using Swift

In the pod file make sure use_frameworks! is in the top area:

platform :ios, '8.0'
use_frameworks!
pod ‘Heartland-iOS-SDK’

Swift Token Service

Below is an example of all that is required to convert sensitive card information into a single-use token. The request is asynchronous so you can safely run this code on the UI thread.

import Heartland_iOS_SDK

let tokenService: HpsTokenService = HpsTokenService(publicKey:"skapi_cert_Mc-xxxxxxxxxxxxxxxxxxxxxx");

tokenService.getTokenWithCardNumber("XXXXXXXXXXXXX",
                               cvc: "123",
                               expMonth: "12",
                               expYear: "2016") { (tokenData) in

    //use token
    tokenData.tokenValue
    //Call method after execution to continue.

}

Objective-C Token Service

Below is an example of all that is required to convert sensitive card information into a single-use token. The request is asynchronous so you can safely run this code on the UI thread.

HpsTokenService *service = [[HpsTokenService alloc] initWithPublicKey:@"YOUR PUBLIC KEY GOES HERE"];

[service getTokenWithCardNumber:@"XXXXXXXXXXXXX"
                            cvc:@"012"
                       expMonth:@"3"
                        expYear:@"2017"
               andResponseBlock:^(HpsTokenData *tokenResponse) {

                   if([tokenResponse.type isEqualToString:@"error"]) {
                        self.tokenCodeResultLabel.text = tokenResponse.code;
                        self.tokenResultLabel.text = tokenResponse.message;
                   }
                   else {
                        self.tokenResultLabel.text = tokenResponse.tokenValue;
                   }

               }];

Quick Tip: The included test suite can be a great source of code samples for using the SDK!

Testing & Certification

Testing your implementation in our Certification/Sandbox environment helps to identify and squash bugs before you begin processing transactions in the production environment. While you are encouraged to run as many test transactions as you can, Heartland provides a specific series of tests that you are required to complete before receiving Certification. Please contact Heartland in order to initiate a certification project.

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	2223000010005780	12	2019	900	6860 Dallas Pkwy	75024
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 issuers 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:

 [service doTransaction:transaction
        withResponseBlock:^(HpsGatewayData *gatewayResponse, NSError *error) {

            //Token success or errors
            //gatewayResponse.tokenResponse.code

            //Gateway success or errors
            //gatewayResponse.responseCode

            //System or connection errors
            //error

        }];

Contributing

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. You can find the test As mentioned earlier, the here.

License

This project is licensed under the GNU General Public License v2.0. Please see LICENSE.md located at the project's root for more details.

======== 2.0.24 - Surcharge Usage Doc

Surcharge Usage:

            let builder = HpsC2xCreditAuthBuilder(device: device)
            builder.amount = amountString
            builder.creditCard = card // Auth
            builder.address = address
            builder.isSurchargeEnabled = true
            builder.execute()

If surcharge is enabled and credit card could be surcheargable, it will prompt onTransactionWaitingForSurchargeConfirmation method


func onTransactionWaitingForSurchargeConfirmation(result: HpsTransactionStatus, response: HpsTerminalResponse) {
if result == .surchargeRequested, let builder = self.builder,
let surchargeFee = response.surchargeFee {
let alertController = UIAlertController(title: "Surcharge Confirmation Required",
message: "There will be a \(surchargeFee) surcharge added to your purchase",
preferredStyle: .alert)

        // Create the actions
        let okAction = UIAlertAction(title: "Accept", style: UIAlertAction.Style.default) {
            UIAlertAction in
            NSLog("OK Pressed")
            self.device?.confirmSurcharge(true)
        }
        let cancelAction = UIAlertAction(title: "Decline", style: UIAlertAction.Style.cancel) {
            UIAlertAction in
            NSLog("Cancel Pressed")
            self.device?.confirmSurcharge(false)
            self.showProgress(false)
        }

        // Add the actions
        alertController.addAction(okAction)
        alertController.addAction(cancelAction)

        // Present the controller
        self.present(alertController, animated: true, completion: nil)
    }
}


>>> self.device?.confirmSurcharge(true) will trigger the transaction sending to our Gateway and the return will be captured on onTransactionComplete(_ result: String, response: HpsTerminalResponse)

hps / heartland-ios

readme