hps 2.2.5 → 2.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (83) hide show
  1. checksums.yaml +5 -5
  2. data/Gemfile +4 -4
  3. data/Gemfile.lock +59 -0
  4. data/LICENSE.md +264 -0
  5. data/PRIVACY.txt +65 -65
  6. data/README.md +213 -216
  7. data/Rakefile +15 -15
  8. data/examples/sinatra-verify-only/Gemfile +4 -4
  9. data/examples/sinatra-verify-only/app.rb +32 -32
  10. data/examples/sinatra-verify-only/views/index.erb +478 -478
  11. data/examples/sinatra-verify-only/views/result.erb +39 -39
  12. data/hps.gemspec +28 -28
  13. data/lib/hps/configuration.rb +17 -17
  14. data/lib/hps/entities/hps_account_verify.rb +8 -8
  15. data/lib/hps/entities/hps_address.rb +6 -6
  16. data/lib/hps/entities/hps_authorization.rb +12 -12
  17. data/lib/hps/entities/hps_batch.rb +6 -6
  18. data/lib/hps/entities/hps_cardholder.rb +6 -6
  19. data/lib/hps/entities/hps_charge.rb +8 -8
  20. data/lib/hps/entities/hps_charge_exceptions.rb +6 -6
  21. data/lib/hps/entities/hps_check.rb +18 -18
  22. data/lib/hps/entities/hps_check_holder.rb +10 -10
  23. data/lib/hps/entities/hps_check_response.rb +45 -45
  24. data/lib/hps/entities/hps_check_response_details.rb +9 -9
  25. data/lib/hps/entities/hps_credit_card.rb +34 -34
  26. data/lib/hps/entities/hps_direct_market_data.rb +5 -5
  27. data/lib/hps/entities/hps_encryption_data.rb +6 -6
  28. data/lib/hps/entities/hps_gift_card.rb +133 -0
  29. data/lib/hps/entities/hps_manage_tokens.rb +8 -8
  30. data/lib/hps/entities/hps_refund.rb +8 -8
  31. data/lib/hps/entities/hps_report_transaction_details.rb +10 -10
  32. data/lib/hps/entities/hps_report_transaction_summary.rb +6 -6
  33. data/lib/hps/entities/hps_reversal.rb +10 -10
  34. data/lib/hps/entities/hps_token_data.rb +10 -10
  35. data/lib/hps/entities/hps_track_data.rb +5 -5
  36. data/lib/hps/entities/hps_transaction.rb +161 -161
  37. data/lib/hps/entities/hps_transaction_details.rb +6 -6
  38. data/lib/hps/entities/hps_transaction_header.rb +8 -8
  39. data/lib/hps/entities/hps_transaction_type.rb +16 -16
  40. data/lib/hps/entities/hps_void.rb +8 -8
  41. data/lib/hps/infrastructure/api_connection_exception.rb +11 -11
  42. data/lib/hps/infrastructure/authentication_exception.rb +11 -11
  43. data/lib/hps/infrastructure/card_exception.rb +15 -15
  44. data/lib/hps/infrastructure/exceptions.json +547 -468
  45. data/lib/hps/infrastructure/hps_account_type.rb +11 -11
  46. data/lib/hps/infrastructure/hps_check_exception.rb +13 -13
  47. data/lib/hps/infrastructure/hps_check_type.rb +11 -11
  48. data/lib/hps/infrastructure/hps_data_entry_mode.rb +11 -11
  49. data/lib/hps/infrastructure/hps_exception.rb +25 -25
  50. data/lib/hps/infrastructure/hps_exception_mapper.rb +145 -134
  51. data/lib/hps/infrastructure/hps_gateway_response_validation.rb +20 -20
  52. data/lib/hps/infrastructure/hps_input_validation.rb +13 -13
  53. data/lib/hps/infrastructure/hps_sdk_codes.rb +48 -48
  54. data/lib/hps/infrastructure/hps_sec_code.rb +27 -27
  55. data/lib/hps/infrastructure/hps_track_data_method.rb +6 -6
  56. data/lib/hps/infrastructure/invalid_request_exception.rb +15 -15
  57. data/lib/hps/services/hps_batch_service.rb +29 -29
  58. data/lib/hps/services/hps_charge_service.rb +773 -773
  59. data/lib/hps/services/hps_check_service.rb +110 -110
  60. data/lib/hps/services/hps_gift_card_service.rb +301 -0
  61. data/lib/hps/services/hps_service.rb +141 -136
  62. data/lib/hps/version.rb +3 -3
  63. data/lib/hps.rb +63 -61
  64. data/tests/amex_tests.rb +292 -292
  65. data/tests/cert_tests.rb +80 -80
  66. data/tests/certification/card_present_spec.rb +320 -320
  67. data/tests/certification/gift_card_certification_test.rb +107 -0
  68. data/tests/certification/gift_card_certification_tests.rb +107 -0
  69. data/tests/check_tests.rb +50 -50
  70. data/tests/discover_tests.rb +386 -386
  71. data/tests/exception_mapper_tests.rb +311 -244
  72. data/tests/general_tests.rb +140 -140
  73. data/tests/giftcard_tests.rb +212 -0
  74. data/tests/hps_token_service.rb +56 -56
  75. data/tests/mastercard_tests.rb +387 -387
  76. data/tests/secret_key.rb +11 -11
  77. data/tests/test_check.rb +77 -77
  78. data/tests/test_data.rb +138 -128
  79. data/tests/test_helper.rb +179 -116
  80. data/tests/token_tests.rb +512 -512
  81. data/tests/visa_tests.rb +445 -445
  82. metadata +40 -15
  83. data/LICENSE.txt +0 -32
data/README.md CHANGED
@@ -1,216 +1,213 @@
1
- <a href="http://developer.heartlandpaymentsystems.com/SecureSubmit" target="_blank">
2
- <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-heartland-logo" alt="Heartland logo" title="Heartland" align="right" />
3
- </a>
4
-
5
- # Heartland Ruby SDK
6
-
7
- This SDK makes it easy to integrate your Ruby application with Heartland's [**Portico Gateway API**](http://developer.heartlandpaymentsystems.com/Portico). Supported features include:
8
-
9
- * Card Not Present (eCommerce and mobile)
10
- * Card Present (Retail and Restaurant)
11
- * <a href="http://developer.heartlandpaymentsystems.com/SecureSubmit" target="_blank">Secure Submit</a> single-use tokenization and multi-use tokenization
12
- * <a href="https://www.heartlandpaymentsystems.com/about-heartland-secure/" target="_blank">Heartland Secure</a> End-to-End Encryption (E3)
13
- * [Credit](http://developer.heartlandpaymentsystems.com/Documentation/credit-card-payments/), [Gift & Loyalty](http://developer.heartlandpaymentsystems.com/Documentation/gift-card-payments/)</a>,and eCheck/ACH
14
- * [Recurring Payments](http://developer.heartlandpaymentsystems.com/Documentation/recurring-payments/)
15
-
16
- Supported Gateway Calls
17
-
18
- * CheckSale
19
- * CheckVoid
20
- * CreditAccountVerify (4.3)
21
- * CreditAddToBatch (4.4)
22
- * CreditAuth (4.5)
23
- * CreditReturn (4.9)
24
- * CreditReversal (4.10)
25
- * CreditSale (4.11)
26
- * ReportActivity (10.4)
27
- * ReportTxnDetail (10.8)
28
- * BatchClose (10.3)
29
-
30
-
31
- | <a href="#data-security"><b>Data Security</b></a> | <a href="#api-reference"><b>API Reference</b></a> | <a href="#testing--certification"><b>Testing & Certification</b></a> | <a href="#api-keys">API Keys</a> | Links |
32
- |:--:|:--:|:--:|:--:|:--|
33
- | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-secure)](#data-security) | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-resources)](#documentation-and-examples) | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-tools)](#certification--testing) | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-keys)](#api-keys) | <a href="http://developer.heartlandpaymentsystems.com/Account/Register" target="_blank">Register an Account</a> <br> <a href="http://www.heartlandpaymentsystems.com/partners/" target="_blank">Partner with Heartland</a> <br> <a href="http://developer.heartlandpaymentsystems.com/SecureSubmit/Support" target="_blank">Developer Support</a> |
34
-
35
-
36
- #### Developer Support
37
-
38
- You are not alone! If you have any questions while you are working through your development process, please feel free to <a href="mailto:entapp_devportal@e-hps.com?Subject=Developer Support Request">reach out to our team for assistance</a>.
39
-
40
-
41
- ## Requirements
42
- Ruby 2.3+
43
-
44
-
45
- ## Installation
46
-
47
- The SDK can be added into your application via a Ruby [Gem](http://guides.rubygems.org/rubygems-basics/) command:
48
-
49
- > gem install 'hps'
50
-
51
- You can also use [Bundler Gemfiles](http://bundler.io/v1.5/gemfile.html) to have it automatically installed. Add the following to your gemfile:
52
-
53
- > gem 'hps'
54
-
55
- And then run Bundler :
56
-
57
- > Bundler
58
-
59
-
60
- ## API Keys
61
-
62
- <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-keys" align="right"/>
63
- 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](http://developer.heartlandpaymentsystems.com/).
64
- Your keys are located under your profile information.
65
-
66
- [![Developer Keys](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-devportal-keys)](http://developer.heartlandpaymentsystems.com/Account/KeysAndCredentials)
67
-
68
- 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](http://developer.heartlandpaymentsystems.com/SecureSubmit).
69
-
70
- Note: Multi-Use tokenization is not enabled by default when creating an account. You can contact <a href="mailto:SecureSubmitCert@e-hps.com?subject=Multi-use Token Request&body=Please enable multi-use tokens on my developer portal account which was signed up under the following email : ">Heartland's Specialty Products Team</a> to have this enabled. This is also true if you wish to use Gift & Loyalty, ACH, and Debit.
71
-
72
-
73
- ## Data Security
74
-
75
- <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-secure" align="right"/>
76
- 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 at motion or at rest.
77
-
78
- * **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:
79
-
80
- * **Self-Hosted Fields** - this approach relies upon the standard, appropriately named, HTML form controls on the integrator's served web page.
81
-
82
- - **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 form. Check out the CoalFire's [whitepaper](http://developer.heartlandpaymentsystems.com/Resource/Download/coalfire-white-paper) for more information.
83
-
84
- - **Heartland Secure** for card-present retailers, hospitality, and other "POS" applications, comprises three distinct security technologies working in concert:
85
- - **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.
86
-
87
- - **Tokenization** - replaces sensitive data values with non-sensitive representations which may be stored for recurring billing, future orders, etc.
88
-
89
- - **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.
90
-
91
- 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.
92
-
93
- 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.
94
-
95
- 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.
96
-
97
- To summarize, when you create a payment method using this SDK you have the following options for securely avoiding interaction with sensitive cardholder data:
98
-
99
- - 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.
100
-
101
- - Encrypted card data (track or PAN) may be obtained directly from a Heartland Secure device and passed to the SDK
102
-
103
-
104
- ## Documentation and Examples
105
-
106
- <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-resources" align="right"/>
107
- You can find the latest SDK documentation along with code examples on our [Developer Portal](http://developer.heartlandpaymentsystems.com/documentation).
108
- In addition the included [test suite](http://github.hps.com/DevPortal/Ruby-SDK/tree/master/tests) can be a great source of code samples for using the SDK!
109
-
110
-
111
- ## Testing & Certification
112
-
113
- <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-tools" align="right"/>
114
- 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 <a href="mailto:SecureSubmitCert@e-hps.com?Subject=Certification Request&Body=I am ready to start certifying my integration! ">contact</a> Heartland in order to initiate a certification project.
115
-
116
- *Quick Tip*: You can get a head start on your certification by reviewing the [certification tests](https://github.com/hps/heartland-ruby/tree/master/tests) in the included test suite.
117
-
118
- #### Test Card Data
119
-
120
- 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.
121
-
122
- <table align="center">
123
- <thead>
124
- <tr>
125
- <th scope="col">Name</th>
126
- <th scope="col">Number</th>
127
- <th scope="col">Exp Month</th>
128
- <th scope="col">Exp Year</th>
129
- <th scope="col">CVV</th>
130
- <th scope="col">Address</th>
131
- <th scope="col">Zip</th>
132
- </tr>
133
- </thead>
134
- <tbody>
135
- <tr>
136
- <td>Visa</td>
137
- <td>4012002000060016</td>
138
- <td>12</td>
139
- <td>2025</td>
140
- <td>123</td>
141
- <td>6860 Dallas Pkwy</td>
142
- <td>750241234</td>
143
- </tr>
144
- <tr>
145
- <td>MasterCard</td>
146
- <td>5473500000000014</td>
147
- <td>12</td>
148
- <td>2025</td>
149
- <td>123</td>
150
- <td>6860 Dallas Pkwy</td>
151
- <td>75024</td>
152
- </tr>
153
- <tr>
154
- <td>Discover</td>
155
- <td>6011000990156527</td>
156
- <td>12</td>
157
- <td>2025</td>
158
- <td>123</td>
159
- <td>6860</td>
160
- <td>750241234</td>
161
- </tr>
162
- <tr>
163
- <td>Amex</td>
164
- <td>372700699251018</td>
165
- <td>12</td>
166
- <td>2025</td>
167
- <td>1234</td>
168
- <td>6860</td>
169
- <td>75024</td>
170
- </tr>
171
- <tr>
172
- <td>JCB</td>
173
- <td>3566007770007321</td>
174
- <td>12</td>
175
- <td>2025</td>
176
- <td>123</td>
177
- <td>6860</td>
178
- <td>75024</td>
179
- </tr>
180
- </tbody>
181
- </table>
182
-
183
- #### Testing Exceptions
184
-
185
- 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](https://cert.api2.heartlandportico.com/Gateway/PorticoDevGuide/build/PorticoDeveloperGuide/Issuer%20Response%20Codes.html) and [gateway response codes](https://cert.api2.heartlandportico.com/Gateway/PorticoDevGuide/build/PorticoDeveloperGuide/Gateway%20Response%20Codes.html). Please <a href="mailto:SecureSubmitCert@e-hps.com?subject=Hard Coded Values Spreadsheet Request">contact</a> 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:
186
-
187
- ```ruby
188
- begin
189
- credit_service.charge(-5, 'usd', credit_card, card_holder)
190
- rescue HpsInvalidRequestException => e
191
- # handle error for amount less than zero dollars
192
- rescue HpsAuthenticationException => e
193
- # handle errors related to your HpsServiceConfig
194
- except HpsCreditException => e
195
- # handle card-related exceptions: card declined, processing error, etc
196
- ````
197
-
198
- More exceptions can be found [here](https://github.com/hps/heartland-ruby/tree/master/lib/hps/infrastructure).
199
-
200
- ## Contributing
201
-
202
- All our code is open sourced and we encourage fellow developers to contribute and help improve it!
203
-
204
- 1. Fork it
205
- 2. Create your feature branch (`git checkout -b my-new-feature`)
206
- 3. Ensure SDK tests are passing
207
- 4. Commit your changes (`git commit -am 'Add some feature'`)
208
- 5. Push to the branch (`git push origin my-new-feature`)
209
- 6. Create new Pull Request
210
-
211
-
212
- #### Included Test Suite
213
-
214
- 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](http://github.hps.com/DevPortal/Ruby-SDK/blob/master/tests/cert_tests.rb) contains tests that mirror the types of requirements you will encounter when you certify your integration for production.
215
-
216
-
1
+ <a href="http://developer.heartlandpaymentsystems.com/SecureSubmit" target="_blank">
2
+ <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-heartland-logo" alt="Heartland logo" title="Heartland" align="right" />
3
+ </a>
4
+
5
+ # Heartland Ruby SDK
6
+
7
+ This SDK makes it easy to integrate your Ruby application with Heartland's [**Portico Gateway API**](http://developer.heartlandpaymentsystems.com/Portico). Supported features include:
8
+
9
+ * Card Not Present (eCommerce and mobile)
10
+ * Card Present (Retail and Restaurant)
11
+ * <a href="http://developer.heartlandpaymentsystems.com/SecureSubmit" target="_blank">Secure Submit</a> single-use tokenization and multi-use tokenization
12
+ * <a href="https://www.heartlandpaymentsystems.com/about-heartland-secure/" target="_blank">Heartland Secure</a> End-to-End Encryption (E3)
13
+ * [Credit](http://developer.heartlandpaymentsystems.com/Documentation/credit-card-payments/), [Gift & Loyalty](http://developer.heartlandpaymentsystems.com/Documentation/gift-card-payments/)</a>,and eCheck/ACH
14
+ * [Recurring Payments](http://developer.heartlandpaymentsystems.com/Documentation/recurring-payments/)
15
+
16
+ Supported Gateway Calls
17
+
18
+ * BatchClose
19
+ * CheckSale
20
+ * CheckVoid
21
+ * CreditAccountVerify
22
+ * CreditAddToBatch
23
+ * CreditAuth
24
+ * CreditReturn
25
+ * CreditReversal
26
+ * CreditSale
27
+ * GiftCardActivate
28
+ * GiftCardAddValue
29
+ * GiftCardAlias
30
+ * GiftCardBalance
31
+ * GiftCardDeactivate
32
+ * GiftCardReplace
33
+ * GiftCardReward
34
+ * GiftCardSale
35
+ * GiftCardVoid
36
+ * GiftCardReversal
37
+ * ReportActivity
38
+ * ReportTxnDetail
39
+
40
+ | <a href="#data-security"><b>Data Security</b></a> | <a href="#api-reference"><b>API Reference</b></a> | <a href="#testing--certification"><b>Testing & Certification</b></a> | <a href="#api-keys">API Keys</a> | Links |
41
+ |:--:|:--:|:--:|:--:|:--|
42
+ | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-secure)](#data-security) | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-resources)](#documentation-and-examples) | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-tools)](#certification--testing) | [![](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-keys)](#api-keys) | <a href="http://developer.heartlandpaymentsystems.com/Account/Register" target="_blank">Register an Account</a> <br> <a href="http://www.heartlandpaymentsystems.com/partners/" target="_blank">Partner with Heartland</a> <br> <a href="http://developer.heartlandpaymentsystems.com/SecureSubmit/Support" target="_blank">Developer Support</a> |
43
+
44
+ #### Developer Support
45
+
46
+ You are not alone! If you have any questions while you are working through your development process, please feel free to <a href="mailto:entapp_devportal@e-hps.com?Subject=Developer Support Request">reach out to our team for assistance</a>.
47
+
48
+ ## Requirements
49
+
50
+ Ruby 2.3+
51
+
52
+ ## Installation
53
+
54
+ The SDK can be added into your application via a Ruby [Gem](http://guides.rubygems.org/rubygems-basics/) command:
55
+
56
+ > gem install 'hps'
57
+
58
+ You can also use [Bundler Gemfiles](http://bundler.io/v1.5/gemfile.html) to have it automatically installed. Add the following to your gemfile:
59
+
60
+ > gem 'hps'
61
+
62
+ And then run Bundler :
63
+
64
+ > Bundler
65
+
66
+ ## API Keys
67
+
68
+ <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-keys" align="right"/>
69
+ 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](http://developer.heartlandpaymentsystems.com/).
70
+ Your keys are located under your profile information.
71
+
72
+ [![Developer Keys](http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-devportal-keys)](http://developer.heartlandpaymentsystems.com/Account/KeysAndCredentials)
73
+
74
+ 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](http://developer.heartlandpaymentsystems.com/SecureSubmit).
75
+
76
+ Note: Multi-Use tokenization is not enabled by default when creating an account. You can contact <a href="mailto:SecureSubmitCert@e-hps.com?subject=Multi-use Token Request&body=Please enable multi-use tokens on my developer portal account which was signed up under the following email : ">Heartland's Specialty Products Team</a> to have this enabled. This is also true if you wish to use Gift & Loyalty, ACH, and Debit.
77
+
78
+
79
+ ## Data Security
80
+
81
+ <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-secure" align="right"/>
82
+ 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 at motion or at rest.
83
+
84
+ - **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:
85
+ - **Self-Hosted Fields** - this approach relies upon the standard, appropriately named, HTML form controls on the integrator's served web page.
86
+ - **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 form. Check out the CoalFire's [whitepaper](http://developer.heartlandpaymentsystems.com/Resource/Download/coalfire-white-paper) for more information.
87
+ - **Heartland Secure** for card-present retailers, hospitality, and other "POS" applications, comprises three distinct security technologies working in concert:
88
+ - **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.
89
+ - **Tokenization** - replaces sensitive data values with non-sensitive representations which may be stored for recurring billing, future orders, etc.
90
+ - **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.
91
+
92
+ 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.
93
+
94
+ 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.
95
+
96
+ 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.
97
+
98
+ To summarize, when you create a payment method using this SDK you have the following options for securely avoiding interaction with sensitive cardholder data:
99
+
100
+ - 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.
101
+ - Encrypted card data (track or PAN) may be obtained directly from a Heartland Secure device and passed to the SDK
102
+
103
+ ## Documentation and Examples
104
+
105
+ <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-resources" align="right"/>
106
+ You can find the latest SDK documentation along with code examples on our [Developer Portal](http://developer.heartlandpaymentsystems.com/documentation).
107
+ In addition the included [test suite](http://github.hps.com/DevPortal/Ruby-SDK/tree/master/tests) can be a great source of code samples for using the SDK!
108
+
109
+ ## Testing & Certification
110
+
111
+ <img src="http://developer.heartlandpaymentsystems.com/Resource/Download/sdk-readme-icon-tools" align="right"/>
112
+ 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 <a href="mailto:SecureSubmitCert@e-hps.com?Subject=Certification Request&Body=I am ready to start certifying my integration! ">contact</a> Heartland in order to initiate a certification project.
113
+
114
+ *Quick Tip*: You can get a head start on your certification by reviewing the [certification tests](https://github.com/hps/heartland-ruby/tree/master/tests) in the included test suite.
115
+
116
+ #### Test Card Data
117
+
118
+ 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.
119
+
120
+ <table align="center">
121
+ <thead>
122
+ <tr>
123
+ <th scope="col">Name</th>
124
+ <th scope="col">Number</th>
125
+ <th scope="col">Exp Month</th>
126
+ <th scope="col">Exp Year</th>
127
+ <th scope="col">CVV</th>
128
+ <th scope="col">Address</th>
129
+ <th scope="col">Zip</th>
130
+ </tr>
131
+ </thead>
132
+ <tbody>
133
+ <tr>
134
+ <td>Visa</td>
135
+ <td>4012002000060016</td>
136
+ <td>12</td>
137
+ <td>2025</td>
138
+ <td>123</td>
139
+ <td>6860 Dallas Pkwy</td>
140
+ <td>750241234</td>
141
+ </tr>
142
+ <tr>
143
+ <td>MasterCard</td>
144
+ <td>5473500000000014</td>
145
+ <td>12</td>
146
+ <td>2025</td>
147
+ <td>123</td>
148
+ <td>6860 Dallas Pkwy</td>
149
+ <td>75024</td>
150
+ </tr>
151
+ <tr>
152
+ <td>Discover</td>
153
+ <td>6011000990156527</td>
154
+ <td>12</td>
155
+ <td>2025</td>
156
+ <td>123</td>
157
+ <td>6860</td>
158
+ <td>750241234</td>
159
+ </tr>
160
+ <tr>
161
+ <td>Amex</td>
162
+ <td>372700699251018</td>
163
+ <td>12</td>
164
+ <td>2025</td>
165
+ <td>1234</td>
166
+ <td>6860</td>
167
+ <td>75024</td>
168
+ </tr>
169
+ <tr>
170
+ <td>JCB</td>
171
+ <td>3566007770007321</td>
172
+ <td>12</td>
173
+ <td>2025</td>
174
+ <td>123</td>
175
+ <td>6860</td>
176
+ <td>75024</td>
177
+ </tr>
178
+ </tbody>
179
+ </table>
180
+
181
+ #### Testing Exceptions
182
+
183
+ 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](https://cert.api2.heartlandportico.com/Gateway/PorticoDevGuide/build/PorticoDeveloperGuide/Issuer%20Response%20Codes.html) and [gateway response codes](https://cert.api2.heartlandportico.com/Gateway/PorticoDevGuide/build/PorticoDeveloperGuide/Gateway%20Response%20Codes.html). Please <a href="mailto:SecureSubmitCert@e-hps.com?subject=Hard Coded Values Spreadsheet Request">contact</a> 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:
184
+
185
+ ```ruby
186
+ begin
187
+ credit_service.charge(-5, 'usd', credit_card, card_holder)
188
+ rescue HpsInvalidRequestException => e
189
+ # handle error for amount less than zero dollars
190
+ rescue HpsAuthenticationException => e
191
+ # handle errors related to your HpsServiceConfig
192
+ rescue HpsCreditException => e
193
+ # handle card-related exceptions: card declined, processing error, etc
194
+ end
195
+ ````
196
+
197
+ More exceptions can be found [here](https://github.com/hps/heartland-ruby/tree/master/lib/hps/infrastructure).
198
+
199
+ ## Contributing
200
+
201
+ All our code is open sourced and we encourage fellow developers to contribute and help improve it!
202
+
203
+ 1. Fork it
204
+ 2. Create your feature branch (`git checkout -b my-new-feature`)
205
+ 3. Ensure SDK tests are passing
206
+ 4. Commit your changes (`git commit -am 'Add some feature'`)
207
+ 5. Push to the branch (`git push origin my-new-feature`)
208
+ 6. Create new Pull Request
209
+
210
+
211
+ #### Included Test Suite
212
+
213
+ 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](http://github.hps.com/DevPortal/Ruby-SDK/blob/master/tests/cert_tests.rb) contains tests that mirror the types of requirements you will encounter when you certify your integration for production.
data/Rakefile CHANGED
@@ -1,15 +1,15 @@
1
- task :console do
2
- require 'bundler/gem_tasks'
3
- require 'hps'
4
- begin
5
- require 'pry'
6
- ARGV.clear
7
- Pry.start
8
- rescue LoadError
9
- #pry was not found so loading irb
10
- require 'irb'
11
- require 'irb/completion'
12
- ARGV.clear
13
- IRB.start
14
- end
15
- end
1
+ task :console do
2
+ require 'bundler/gem_tasks'
3
+ require 'hps'
4
+ begin
5
+ require 'pry'
6
+ ARGV.clear
7
+ Pry.start
8
+ rescue LoadError
9
+ #pry was not found so loading irb
10
+ require 'irb'
11
+ require 'irb/completion'
12
+ ARGV.clear
13
+ IRB.start
14
+ end
15
+ end
@@ -1,4 +1,4 @@
1
- source 'https://rubygems.org'
2
-
3
- gem 'sinatra'
4
- gem 'hps'
1
+ source 'https://rubygems.org'
2
+
3
+ gem 'sinatra'
4
+ gem 'hps'
@@ -1,32 +1,32 @@
1
- require 'sinatra'
2
- require 'hps'
3
-
4
- Hps.configure do |config|
5
- config.secret_api_key = 'skapi_cert_MTyMAQBiHVEAewvIzXVFcmUd2UcyBge_eCpaASUp0A'
6
- end
7
-
8
- service = Hps::HpsChargeService.new
9
-
10
- get '/' do
11
- erb :index
12
- end
13
-
14
- post '/charge' do
15
- card_holder = Hps::HpsCardHolder.new
16
- card_holder.first_name = request['FirstName']
17
- card_holder.last_name = request['LastName']
18
- card_holder.address = Hps::HpsAddress.new
19
- card_holder.address.address = request['Address']
20
- card_holder.address.city = request['City']
21
- card_holder.address.state = request['State']
22
- card_holder.address.zip = request['Zip']
23
-
24
- token = request['token_value']
25
-
26
- logger.info card_holder
27
- logger.info token
28
-
29
- verification = service.verify(token, card_holder, true)
30
-
31
- erb :result, :locals => { :verification => verification }
32
- end
1
+ require 'sinatra'
2
+ require 'hps'
3
+
4
+ Hps.configure do |config|
5
+ config.secret_api_key = 'skapi_cert_MTyMAQBiHVEAewvIzXVFcmUd2UcyBge_eCpaASUp0A'
6
+ end
7
+
8
+ service = Hps::HpsChargeService.new
9
+
10
+ get '/' do
11
+ erb :index
12
+ end
13
+
14
+ post '/charge' do
15
+ card_holder = Hps::HpsCardHolder.new
16
+ card_holder.first_name = request['FirstName']
17
+ card_holder.last_name = request['LastName']
18
+ card_holder.address = Hps::HpsAddress.new
19
+ card_holder.address.address = request['Address']
20
+ card_holder.address.city = request['City']
21
+ card_holder.address.state = request['State']
22
+ card_holder.address.zip = request['Zip']
23
+
24
+ token = request['token_value']
25
+
26
+ logger.info card_holder
27
+ logger.info token
28
+
29
+ verification = service.verify(token, card_holder, true)
30
+
31
+ erb :result, :locals => { :verification => verification }
32
+ end