blockchyp 2.2.4 → 2.3.5

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 4569f1fe2455fe98d3e09d7ed59c9d91f81bc366bcfc7b64dfbbaf1026443670
4
- data.tar.gz: 6ce270e6356101d6afee6b72462e6c6580dc59e1203e74b288ef0d5db2cb5e2c
3
+ metadata.gz: 5ca711b2e47c0391a4d2bae6df5f33eb9585fca0aec4121aa2a26bf6a96a2516
4
+ data.tar.gz: e63cfc05d92201d6ed4d30f6f0e7f83aa5224b8fbc54b34b8845e427bcef52f3
5
5
  SHA512:
6
- metadata.gz: 24fd0fc590987fa3e552ac0ad9ad6574a01c06c9db34007f9db5432deb7db0ca5b83fbf7c5ebc99b46261eae269a15e379de4bd2e43c061a3465b1d98680ec40
7
- data.tar.gz: f1df347d1baf97a3275971d0141464dbb980310cfd18ad03196813515fcb2ebc2074b3c9e336804c559b097de111ae01935e850725c9dd6f45da66e8654aa5a1
6
+ metadata.gz: 95113934892b77a450f0b9b0c69a4cd61721fd4cdf4286b73f99c9420ffeab10c7cdc892af18901b550731fa2a5579c76b28369031edac105075d00b7421fc25
7
+ data.tar.gz: c899ac8ef7ecf482d9e99102a4d8af54845d8f63d11522fc73ec9b0c1c3e17cb80a244d71f1b075ec5cdca42e6274bc3d957a6a4ea47681b9438d741b14077e7
data/README.md CHANGED
@@ -49,35 +49,11 @@ end
49
49
 
50
50
 
51
51
 
52
- ## The Rest APIs
52
+ ## Additional Documentation
53
53
 
54
- All BlockChyp SDKs provide a convenient way of accessing the BlockChyp REST APIs.
55
- You can checkout the REST API documentation via the links below.
54
+ Complete documentation can be found on our [Developer Documentation Portal].
56
55
 
57
- [Terminal REST API Docs](https://docs.blockchyp.com/rest-api/terminal/index.html)
58
-
59
- [Gateway REST API Docs](https://docs.blockchyp.com/rest-api/gateway/index.html)
60
-
61
- ## Other SDKs
62
-
63
- BlockChyp has officially supported SDKs for eight different development platforms and counting.
64
- Here's the full list with links to their GitHub repositories.
65
-
66
- [Go SDK](https://github.com/blockchyp/blockchyp-go)
67
-
68
- [Node.js/JavaScript SDK](https://github.com/blockchyp/blockchyp-js)
69
-
70
- [Java SDK](https://github.com/blockchyp/blockchyp-java)
71
-
72
- [.net/C# SDK](https://github.com/blockchyp/blockchyp-csharp)
73
-
74
- [Ruby SDK](https://github.com/blockchyp/blockchyp-ruby)
75
-
76
- [PHP SDK](https://github.com/blockchyp/blockchyp-php)
77
-
78
- [Python SDK](https://github.com/blockchyp/blockchyp-python)
79
-
80
- [iOS (Objective-C/Swift) SDK](https://github.com/blockchyp/blockchyp-ios)
56
+ [Developer Documentation Portal]: https://docs.blockchyp.com/
81
57
 
82
58
  ## Getting a Developer Kit
83
59
 
@@ -98,9 +74,21 @@ You can also view a number of long form demos and learn more about us on our [Yo
98
74
  You don't want to read words. You want examples. Here's a quick rundown of the
99
75
  stuff you can do with the BlockChyp Ruby SDK and a few basic examples.
100
76
 
101
- #### Charge
77
+ #### Terminal Ping
78
+
79
+
80
+ This simple test transaction helps ensure you have good communication with a payment terminal and is usually the first one you'll run in development.
81
+
82
+ It tests communication with the terminal and returns a positive response if everything
83
+ is okay. It works the same way in local or cloud relay mode.
84
+
85
+ If you get a positive response, you've successfully verified all of the following:
86
+
87
+ * The terminal is online.
88
+ * There is a valid route to the terminal.
89
+ * The API Credential are valid.
90
+
102
91
 
103
- Executes a standard direct preauth and capture.
104
92
 
105
93
 
106
94
  ```ruby
@@ -116,21 +104,53 @@ blockchyp = BlockChyp::BlockChyp.new(
116
104
 
117
105
  # Set request parameters
118
106
  request = {
119
- "test": true,
120
- "terminalName": 'Test Terminal',
121
- "amount": '55.00'
107
+ "terminalName": 'Test Terminal'
122
108
  }
123
109
 
124
- response = blockchyp.charge(request)
110
+ response = blockchyp.ping(request)
125
111
 
126
112
  puts "Response: #{response.inspect}"
127
113
 
128
114
 
129
115
  ```
130
116
 
131
- #### Preauthorization
117
+ #### Charge
118
+
119
+
120
+ Our most popular transaction executes a standard authorization and capture.
121
+ This is the most basic of
122
+ basic payment transactions, typically used in conventional retail.
123
+
124
+ Charge transactions can use a payment terminal to capture a payment or
125
+ use a previously enrolled payment token.
126
+
127
+ **Terminal Transactions**
128
+
129
+ For terminal transactions, make sure you pass in the terminal name using the `terminalName` property.
130
+
131
+ **Token Transactions**
132
+
133
+ If you have a payment token, omit the `terminalName` property and pass in the token with the `token`
134
+ property instead.
135
+
136
+ **Card Numbers and Mag Stripes**
137
+
138
+ You can also pass in PANs and Mag Stripes, but you probably shouldn't. This will
139
+ put you in PCI scope and the most common vector for POS breaches is key logging.
140
+ If you use terminals for manual card entry, you'll bypass any key loggers that
141
+ might be maliciously running on the point-of-sale system.
142
+
143
+ **Common Variations**
144
+
145
+ * **Gift Card Redemption**: There's no special API for gift card redemption in BlockChyp. Just execute a plain charge transaction and if the customer happens to swipe a gift card, our terminals will identify the gift card and run a gift card redemption. Also note that if for some reason the gift card's original purchase transaction is associated with fraud or a chargeback, the transaction will be rejected.
146
+ * **EBT**: Set the `ebt` flag to process an EBT SNAP transaction. Note that test EBT transactions alway assume a balance of $100.00, so test EBT transactions over that amount may be declined.
147
+ * **Cash Back**: To enable cash back for debit transactions, set the `cashBack` flag. If the card presented isn't a debit card, the `cashBack` flag will be ignored.
148
+ * **Manual Card Entry**: Set the `manual` flag to enable manual card entry. Good as a backup when chips and MSR's don't work or for more secure phone orders. You can even combine the `manual` flag with the `ebt` flag for manual EBT card entry.
149
+ * **Inline Tokenization**: You can enroll the payment method in the token vault inline with a charge transaction by setting the `enroll` flag. You'll get a token back in the response. You can even bind the token to a customer record if you also pass in customer data.
150
+ * **Prompting for Tips**: Set the `promptForTips` flag if you'd like to prompt the customer for a tip before authorization. Good for pay-at-the-table and other service related scenarios.
151
+ * **Cash Discounting and Surcharging**: The `surcharge` and `cashDiscount` flags can be used together to support cash discounting or surcharge problems. Consult the Cash Discount documentation for more details.
152
+
132
153
 
133
- Executes a preauthorization intended to be captured later.
134
154
 
135
155
 
136
156
  ```ruby
@@ -148,47 +168,53 @@ blockchyp = BlockChyp::BlockChyp.new(
148
168
  request = {
149
169
  "test": true,
150
170
  "terminalName": 'Test Terminal',
151
- "amount": '27.00'
171
+ "amount": '55.00'
152
172
  }
153
173
 
154
- response = blockchyp.preauth(request)
174
+ response = blockchyp.charge(request)
155
175
 
156
176
  puts "Response: #{response.inspect}"
157
177
 
158
178
 
159
179
  ```
160
180
 
161
- #### Terminal Ping
181
+ #### Preauthorization
162
182
 
163
- Tests connectivity with a payment terminal.
164
183
 
184
+ A preauthorization puts a hold on funds and must be captured later. This is used
185
+ in scenarios where the final transaction amount might change. A common examples would
186
+ be fine dining where a tip adjustment is required prior to final settlement.
165
187
 
166
- ```ruby
167
- # frozen_string_literal: true
188
+ Another use case for preauthorization is e-commerce. Typically, an online order
189
+ is preauthorized at the time of the order and then captured when the order ships.
168
190
 
169
- require 'blockchyp'
191
+ Preauthorizations can use a payment terminal to capture a payment or
192
+ use a previously enrolled payment token.
170
193
 
171
- blockchyp = BlockChyp::BlockChyp.new(
172
- ENV['BC_API_KEY'],
173
- ENV['BC_BEARER_TOKEN'],
174
- ENV['BC_SIGNING_KEY']
175
- )
194
+ **Terminal Transactions**
176
195
 
177
- # Set request parameters
178
- request = {
179
- "terminalName": 'Test Terminal'
180
- }
196
+ For terminal transactions, make sure you pass in the terminal name using the `terminalName` property.
181
197
 
182
- response = blockchyp.ping(request)
198
+ **Token Transactions**
183
199
 
184
- puts "Response: #{response.inspect}"
200
+ If you have a payment token, omit the `terminalName` property and pass in the token with the `token`
201
+ property instead.
185
202
 
203
+ **Card Numbers and Mag Stripes**
186
204
 
187
- ```
205
+ You can also pass in PANs and Mag Stripes, but you probably shouldn't. This will
206
+ put you in PCI scope and the most common vector for POS breaches is key logging.
207
+ If you use terminals for manual card entry, you'll bypass any key loggers that
208
+ might be maliciously running on the point-of-sale system.
209
+
210
+ **Common Variations**
211
+
212
+ * **Manual Card Entry**: Set the `manual` flag to enable manual card entry. Good as a backup when chips and MSR's don't work or for more secure phone orders. You can even combine the `manual` flag with the `ebt` flag for manual EBT card entry.
213
+ * **Inline Tokenization**: You can enroll the payment method in the token vault in line with a charge transaction by setting the `enroll` flag. You'll get a token back in the response. You can even bind the token to a customer record if you also pass in customer data.
214
+ * **Prompting for Tips**: Set the `promptForTips` flag if you'd like to prompt the customer for a tip before authorization. You can prompt for tips as part of a preauthorization, although it's not a very common approach.
215
+ * **Cash Discounting and Surcharging**: The `surcharge` and `cashDiscount` flags can be used together to support cash discounting or surcharge problems. Consult the Cash Discount documentation for more details.
188
216
 
189
- #### Balance
190
217
 
191
- Checks the remaining balance on a payment method.
192
218
 
193
219
 
194
220
  ```ruby
@@ -206,19 +232,29 @@ blockchyp = BlockChyp::BlockChyp.new(
206
232
  request = {
207
233
  "test": true,
208
234
  "terminalName": 'Test Terminal',
209
- "cardType": CardType::EBT
235
+ "amount": '27.00'
210
236
  }
211
237
 
212
- response = blockchyp.balance(request)
238
+ response = blockchyp.preauth(request)
213
239
 
214
240
  puts "Response: #{response.inspect}"
215
241
 
216
242
 
217
243
  ```
218
244
 
219
- #### Terminal Clear
245
+ #### Capture Preauthorization
246
+
247
+
248
+ This API allows you to capture a previously approved preauthorization.
249
+
250
+ You'll need to make sure you pass in the Transaction ID returned by the original preauth transaction so we know which transaction we're capturing. If you want to capture the transaction for the
251
+ exact amount of the preauth, the Transaction ID is all you need to pass in.
252
+
253
+ You can adjust the total if you need to by passing in a new `amount`. We
254
+ also recommend you pass in updated amounts for `tax` and `tip` as it can
255
+ reduce your interchange fees in some cases. (Level II Processing, for example.)
256
+
220
257
 
221
- Clears the line item display and any in progress transaction.
222
258
 
223
259
 
224
260
  ```ruby
@@ -235,19 +271,66 @@ blockchyp = BlockChyp::BlockChyp.new(
235
271
  # Set request parameters
236
272
  request = {
237
273
  "test": true,
238
- "terminalName": 'Test Terminal'
274
+ "transactionId": '<PREAUTH TRANSACTION ID>'
239
275
  }
240
276
 
241
- response = blockchyp.clear(request)
277
+ response = blockchyp.capture(request)
242
278
 
243
279
  puts "Response: #{response.inspect}"
244
280
 
245
281
 
246
282
  ```
247
283
 
248
- #### Terms & Conditions Capture
284
+ #### Refund
285
+
286
+
287
+ It's not ideal, but sometimes customers want their money back.
288
+
289
+ Our refund API allows you to confront this unpleasant reality by executing refunds in a few different scenarios.
290
+
291
+ The most fraud resistent method is to execute refunds in the context of a previous transaction. You should always keep track of the Transaction ID
292
+ returned in a BlockChyp response. To refund the full amount of the previous transaction, just pass in the original Transaction ID with the refund requests.
293
+
294
+ **Partial Refunds**
295
+
296
+ For a partial refund, just pass in an amount along with the Transaction ID.
297
+ The only rule is that the amount has to be equal to or less than the original
298
+ transaction. You can execute multiple partial refunds against the same
299
+ original transaction as long as the total refunded amount doesn't exceed the original amount.
300
+
301
+ **Tokenized Refunds**
302
+
303
+ You can also use a token to execute a refund. Pass in a token instead
304
+ of the Transaction ID along with the desired refund amount.
305
+
306
+ **Free Range Refunds**
307
+
308
+ When you execute a refund without referencing a previous transaction, we
309
+ call this a *free range refund*.
310
+
311
+ We don't recommend it, but it is permitted. If you absolutely insist on
312
+ doing it, pass in a Terminal Name and an amount.
313
+
314
+ You can execute a manual or keyed refund by passing the `manual` flag
315
+ to a free range refund request.
316
+
317
+ **Gift Card Refunds**
318
+
319
+ Gift card refunds are allowed in the context of a previous transaction, but
320
+ free range gift card refunds are not allowed. Use the gift card activation
321
+ API if you need to add more funds to a gift card.
322
+
323
+ **Store and Forward Support**
324
+
325
+ Refunds are not permitted when a terminal falls back to store and forward mode.
326
+
327
+ **Auto Voids**
328
+
329
+ If a refund referencing a previous transaction is executed for the full amount
330
+ before the original transaction's batch is closed, the refund is automatically
331
+ converted to a void. This saves the merchant a little bit of money.
332
+
249
333
 
250
- Prompts the user to accept terms and conditions.
251
334
 
252
335
 
253
336
  ```ruby
@@ -263,41 +346,39 @@ blockchyp = BlockChyp::BlockChyp.new(
263
346
 
264
347
  # Set request parameters
265
348
  request = {
266
- "test": true,
267
- "terminalName": 'Test Terminal',
349
+ "transactionId": '<PREVIOUS TRANSACTION ID>',
268
350
 
269
- # Alias for a Terms and Conditions template configured in the BlockChyp
270
- # dashboard.
271
- "tcAlias": 'hippa',
351
+ # Optional amount for partial refunds.
352
+ "amount": '5.00'
353
+ }
272
354
 
273
- # Name of the contract or document if not using an alias.
274
- "tcName": 'HIPPA Disclosure',
355
+ response = blockchyp.refund(request)
275
356
 
276
- # Full text of the contract or disclosure if not using an alias.
277
- "tcContent": 'Full contract text',
357
+ puts "Response: #{response.inspect}"
278
358
 
279
- # File format for the signature image.
280
- "sigFormat": SignatureFormat::PNG,
281
359
 
282
- # Width of the signature image in pixels.
283
- "sigWidth": 200,
360
+ ```
284
361
 
285
- # Whether or not a signature is required. Defaults to true.
286
- "sigRequired": true
287
- }
362
+ #### Enroll
288
363
 
289
- response = blockchyp.termsAndConditions(request)
290
364
 
291
- puts "Response: #{response.inspect}"
365
+ This API allows you to tokenize and enroll a payment method in the token
366
+ vault. You can also pass in customer information and associate the
367
+ payment method with a customer record.
292
368
 
369
+ A token is returned in the response that can be used in subsequent charge,
370
+ preauth, and refund transactions.
293
371
 
294
- ```
372
+ **Gift Cards and EBT**
373
+
374
+ Gift Cards and EBT cards cannot be tokenized.
375
+
376
+ **E-Commerce Tokens**
377
+
378
+ The tokens returned by the enroll API and the e-commerce web tokenizer
379
+ are the same tokens and can be used interchangeably.
295
380
 
296
- #### Update Transaction Display
297
381
 
298
- Appends items to an existing transaction display. Subtotal, Tax, and Total are
299
- overwritten by the request. Items with the same description are combined into
300
- groups.
301
382
 
302
383
 
303
384
  ```ruby
@@ -314,38 +395,27 @@ blockchyp = BlockChyp::BlockChyp.new(
314
395
  # Set request parameters
315
396
  request = {
316
397
  "test": true,
317
- "terminalName": 'Test Terminal',
318
- "transaction": {
319
- "subtotal": '60.00',
320
- "tax": '5.00',
321
- "total": '65.00',
322
- "items": [
323
- {
324
- "description": 'Leki Trekking Poles',
325
- "price": '35.00',
326
- "quantity": 2,
327
- "extended": '70.00',
328
- "discounts": [
329
- {
330
- "description": 'memberDiscount',
331
- "amount": '10.00'
332
- }
333
- ]
334
- }
335
- ]
336
- }
398
+ "terminalName": 'Test Terminal'
337
399
  }
338
400
 
339
- response = blockchyp.updateTransactionDisplay(request)
401
+ response = blockchyp.enroll(request)
340
402
 
341
403
  puts "Response: #{response.inspect}"
342
404
 
343
405
 
344
406
  ```
345
407
 
346
- #### New Transaction Display
408
+ #### Void
409
+
410
+
411
+
412
+ Mistakes happen. If a transaction is made by mistake, you can void it
413
+ with this API. All that's needed is to pass in a Transaction ID and execute
414
+ the void before the original transaction's batch closes.
415
+
416
+ Voids work with EBT and gift card transactions with no additional parameters.
417
+
347
418
 
348
- Displays a new transaction on the terminal.
349
419
 
350
420
 
351
421
  ```ruby
@@ -362,38 +432,38 @@ blockchyp = BlockChyp::BlockChyp.new(
362
432
  # Set request parameters
363
433
  request = {
364
434
  "test": true,
365
- "terminalName": 'Test Terminal',
366
- "transaction": {
367
- "subtotal": '60.00',
368
- "tax": '5.00',
369
- "total": '65.00',
370
- "items": [
371
- {
372
- "description": 'Leki Trekking Poles',
373
- "price": '35.00',
374
- "quantity": 2,
375
- "extended": '70.00',
376
- "discounts": [
377
- {
378
- "description": 'memberDiscount',
379
- "amount": '10.00'
380
- }
381
- ]
382
- }
383
- ]
384
- }
435
+ "transactionId": '<PREVIOUS TRANSACTION ID>'
385
436
  }
386
437
 
387
- response = blockchyp.newTransactionDisplay(request)
438
+ response = blockchyp.void(request)
388
439
 
389
440
  puts "Response: #{response.inspect}"
390
441
 
391
442
 
392
443
  ```
393
444
 
394
- #### Text Prompt
445
+ #### Time Out Reversal
446
+
447
+
448
+
449
+ Payment transactions require a stable network to function correctly and
450
+ no network is stable all the time. Time out reversals are a great line
451
+ of defense against accidentally double charging consumers when payments
452
+ are retried during shaky network conditions.
453
+
454
+ We highly recommend developers use this API whenever a charge, preauth, or refund transaction times out. If you don't receive a definitive response
455
+ from BlockChyp, you can't be certain about whether or not the transaction went through.
456
+
457
+ The best practice in this situation is to send a time out reversal request. Time out reversals check for a transaction and void it if it exists.
458
+
459
+ The only caveat is that developers must use the `transactionRef` property (`txRef` for the CLI) when executing charge, preauth, and refund transactions.
460
+
461
+ The reason for this requirement is that if a system never receives a definitive
462
+ response for a transaction, the system would never have received the BlockChyp
463
+ generated Transaction ID. We have to fallback to Transaction Ref to identify
464
+ a transaction.
465
+
395
466
 
396
- Asks the consumer a text based question.
397
467
 
398
468
 
399
469
  ```ruby
@@ -409,24 +479,71 @@ blockchyp = BlockChyp::BlockChyp.new(
409
479
 
410
480
  # Set request parameters
411
481
  request = {
412
- "test": true,
413
- "terminalName": 'Test Terminal',
414
-
415
- # Type of prompt. Can be 'email', 'phone', 'customer-number', or
416
- # 'rewards-number'.
417
- "promptType": PromptType::EMAIL
482
+ "transactionRef": '<LAST TRANSACTION REF>'
418
483
  }
419
484
 
420
- response = blockchyp.textPrompt(request)
485
+ response = blockchyp.reverse(request)
421
486
 
422
487
  puts "Response: #{response.inspect}"
423
488
 
424
489
 
425
490
  ```
426
491
 
427
- #### Boolean Prompt
492
+ #### Gift Card Activation
493
+
494
+
495
+ This API can be used to activate or add value to BlockChyp gift cards.
496
+ Just pass in the terminal name and the amount to add to the card.
497
+ Once the customer swipes their card, the terminal will use keys
498
+ on the mag stripe to add value to the card.
499
+
500
+ You don't need to handle a new gift card activation or a gift card recharge any
501
+ differently. The terminal firmware will figure out what to do on its
502
+ own and also returns the new balance for the gift card.
503
+
504
+ This is the part of the system where BlockChyp's blockchain DNA comes
505
+ closest to the surface. The BlockChyp gift card system doesn't really
506
+ use gift card numbers. This means they can't be stolen.
507
+
508
+ BlockChyp identifies cards with an elliptic curve public key instead.
509
+ Gift card transactions are actually blocks signed with those keys.
510
+ This means there are no shared secrets sent over the network.
511
+ To keep track of a BlockChyp gift card, hang on to the **public key** returned
512
+ during gift card activation. That's the gift card's elliptic curve public key.
513
+
514
+ We sometimes print numbers on our gift cards, but these are actually
515
+ decimal encoded hashes of a portion of the public key to make our gift
516
+ cards seem *normal* to *normies*. They can be used
517
+ for balance checks and play a lookup role in online gift card
518
+ authorization, but are of little use beyond that.
519
+
520
+ **Voids and Reversals**
521
+
522
+ Gift card activations can be voided and reversed just like any other
523
+ BlockChyp transaction. Use the Transaction ID or Transaction Ref
524
+ to identify the gift activation transaction as you normally would for
525
+ voiding or reversing a conventional payment transaction.
526
+
527
+ **Importing Gift Cards**
528
+
529
+ BlockChyp does have the ability to import gift card liability from
530
+ conventional gift card platforms. Unfortunately, BlockChyp does not
531
+ support activating cards on third party systems, but you can import
532
+ your outstanding gift cards and customers can swipe them on the
533
+ terminals just like BlockChyp's standard gift cards.
534
+
535
+ No special coding is required to access this feature. The gateway and
536
+ terminal firmware handle everything for you.
537
+
538
+ **Third Party Gift Card Networks**
539
+
540
+ BlockChyp does not currently provide any native support for other gift card
541
+ platforms beyond importing gift card liability. We do have a white listing system
542
+ that can be used to support your own custom gift card implementations. We have a security review
543
+ process before we allow a BIN range to be white listed, so contact
544
+ support@blockchyp.com if you need to white list a BIN range.
545
+
428
546
 
429
- Asks the consumer a yes/no question.
430
547
 
431
548
 
432
549
  ```ruby
@@ -444,21 +561,47 @@ blockchyp = BlockChyp::BlockChyp.new(
444
561
  request = {
445
562
  "test": true,
446
563
  "terminalName": 'Test Terminal',
447
- "prompt": 'Would you like to become a member?',
448
- "yesCaption": 'Yes',
449
- "noCaption": 'No'
564
+ "amount": '50.00'
450
565
  }
451
566
 
452
- response = blockchyp.booleanPrompt(request)
567
+ response = blockchyp.giftActivate(request)
453
568
 
454
569
  puts "Response: #{response.inspect}"
455
570
 
456
571
 
457
572
  ```
458
573
 
459
- #### Display Message
574
+ #### Balance
575
+
576
+
577
+
578
+ Checks a gift or EBT card balance.
579
+
580
+ **Gift Card Balance Checks**
581
+
582
+ For gift cards, just pass in a terminal name and the customer will be prompted
583
+ to swipe a card on that terminal. The remaining balance will be displayed
584
+ briefly on the terminal screen and the API response will include the gift card's public key and the remaining balance.
585
+
586
+ **EBT Balance Checks**
587
+
588
+ All EBT transactions require a PIN, so in order to check an EBT card balance,
589
+ you need to pass in the `ebt` flag just like you would for a normal EBT
590
+ charge transaction. The customer will be prompted to swipe their card and
591
+ enter a PIN code. If everything checks out, the remaining balance on the card will be displayed on terminal for the customer and returned in the API.
592
+
593
+ **Testing Gift Card Balance Checks**
594
+
595
+ Test gift card balance checks work no differently than live gift cards. You
596
+ must activate a test gift card first in order to test balance checks. Test
597
+ gift cards are real blockchain cards that live on our parallel test blockchain.
598
+
599
+ **Testing EBT Gift Card Balance Checks**
600
+
601
+ All test EBT transactions assume a starting balance of $100.00. As a result,
602
+ test EBT balance checks always return a balance of $100.00.
603
+
460
604
 
461
- Displays a short message on the terminal.
462
605
 
463
606
 
464
607
  ```ruby
@@ -476,51 +619,547 @@ blockchyp = BlockChyp::BlockChyp.new(
476
619
  request = {
477
620
  "test": true,
478
621
  "terminalName": 'Test Terminal',
479
- "message": 'Thank you for your business.'
622
+ "cardType": CardType::EBT
623
+ }
624
+
625
+ response = blockchyp.balance(request)
626
+
627
+ puts "Response: #{response.inspect}"
628
+
629
+
630
+ ```
631
+
632
+ #### Close Batch
633
+
634
+
635
+ This API will close the merchant's batch if it's currently open.
636
+
637
+ By default, merchant batches will close automatically at 3 AM in their
638
+ local time zone. The automatic batch closure time can be changed
639
+ in the Merchant Profile or disabled completely.
640
+
641
+ If automatic batch closure is disabled, you'll need to use this API to
642
+ close the batch manually.
643
+
644
+
645
+
646
+ ```ruby
647
+ # frozen_string_literal: true
648
+
649
+ require 'blockchyp'
650
+
651
+ blockchyp = BlockChyp::BlockChyp.new(
652
+ ENV['BC_API_KEY'],
653
+ ENV['BC_BEARER_TOKEN'],
654
+ ENV['BC_SIGNING_KEY']
655
+ )
656
+
657
+ # Set request parameters
658
+ request = {
659
+ "test": true
660
+ }
661
+
662
+ response = blockchyp.closeBatch(request)
663
+
664
+ puts "Response: #{response.inspect}"
665
+
666
+
667
+ ```
668
+
669
+ #### Send Payment Link
670
+
671
+
672
+
673
+ This API allows you to send an invoice to a customer and capture payment
674
+ via a BlockChyp hosted payment page.
675
+
676
+ If you set the `autoSend` flag, BlockChyp will send a basic invoice email
677
+ to the customer for you that includes the payment link. If you'd rather have
678
+ more control over the look of the email message, you can omit the `autoSend`
679
+ flag and send the customer email yourself.
680
+
681
+ There are a lot of optional parameters for this API, but at a minimum
682
+ you'll need to pass in a total, customer name, and email address. (Unless
683
+ you use the `cashier` flag.)
684
+
685
+ **Customer Info**
686
+
687
+ Unless you're using the `cashier` flag, you must specify a customer, either by
688
+ creating a new customer record inline or by passing in an existing Customer ID or Customer Ref.
689
+
690
+ **Line Item Level Data**
691
+
692
+ It's not strictly required, but we strongly recommend sending line item level
693
+ detail with every request. It will make the invoice look a little more complete
694
+ and the data format for line item level data is the exact same format used
695
+ for terminal line item display, so the same code can be used to support both areas.
696
+
697
+ **Descriptions**
698
+
699
+ You can also provide a free form description or message that's displayed near
700
+ the bottom of the invoice. Usually this is some kind of thank you note
701
+ or instruction.
702
+
703
+ **Terms and Conditions**
704
+
705
+ You can include long form contract language with a request and capture
706
+ terms and conditions acceptance at the same time payment is captured.
707
+
708
+ The interface is identical to that used for the terminal based Terms and
709
+ Conditions API in that you can pass in content directly via `tcContent` or via
710
+ a preconfigured template via `tcAlias`. The Terms and Conditions log will also be updated when
711
+ agreement acceptance is incorporated into a send link request.
712
+
713
+ **Auto Send**
714
+
715
+ BlockChyp does not send the email notification automatically. This is
716
+ a safeguard to prevent real emails from going out when you may not expect it.
717
+ If you want BlockChyp to send the email for you, just add the `autoSend` flag with
718
+ all requests.
719
+
720
+ **Cashier Facing Card Entry**
721
+
722
+ BlockChyp can be used to generate internal/cashier facing card entry pages as well. This is
723
+ designed for situations where you might need to take a phone order and you don't
724
+ have a terminal.
725
+
726
+ If you pass in the `cashier` flag, no email will be sent and you'll be be able to
727
+ load the link in a browser or iframe for payment entry. When the `cashier` flag
728
+ is used, the `autoSend` flag will be ignored.
729
+
730
+ **Payment Notifications**
731
+
732
+ When a customer successfully submits payment, the merchant will receive an email
733
+ notifying them that the payment was received.
734
+
735
+ **Real Time Callback Notifications**
736
+
737
+ Email notifications are fine, but you may want your system to be informed
738
+ immediately whenever a payment event occurs. By using the optional `callbackUrl` request
739
+ property, you can specify a URL to which the Authorization Response will be posted
740
+ every time the user submits a payment, whether approved or otherwise.
741
+
742
+ The response will be sent as a JSON encoded POST request and will be the exact
743
+ same format as all BlockChyp charge and preauth transaction responses.
744
+
745
+ **Status Polling**
746
+
747
+ If real time callbacks aren't practical or necesary in your environment, you can
748
+ always use the Transaction Status API described below.
749
+
750
+ A common use case for the send link API with status polling is curbside pickup.
751
+ You could have your system check the Transaction Status when a customer arrives to
752
+ ensure it's been paid without necessarily needing to create background threads
753
+ to constantly poll for status updates.
754
+
755
+
756
+
757
+
758
+ ```ruby
759
+ # frozen_string_literal: true
760
+
761
+ require 'blockchyp'
762
+
763
+ blockchyp = BlockChyp::BlockChyp.new(
764
+ ENV['BC_API_KEY'],
765
+ ENV['BC_BEARER_TOKEN'],
766
+ ENV['BC_SIGNING_KEY']
767
+ )
768
+
769
+ # Set request parameters
770
+ request = {
771
+ "amount": '199.99',
772
+ "description": 'Widget',
773
+ "subject": 'Widget invoice',
774
+ "transaction": {
775
+ "subtotal": '195.00',
776
+ "tax": '4.99',
777
+ "total": '199.99',
778
+ "items": [
779
+ {
780
+ "description": 'Widget',
781
+ "price": '195.00',
782
+ "quantity": 1
783
+ }
784
+ ]
785
+ },
786
+ "autoSend": true,
787
+ "customer": {
788
+ "customerRef": 'Customer reference string',
789
+ "firstName": 'FirstName',
790
+ "lastName": 'LastName',
791
+ "companyName": 'Company Name',
792
+ "emailAddress": 'support@blockchyp.com',
793
+ "smsNumber": '(123) 123-1231'
794
+ }
795
+ }
796
+
797
+ response = blockchyp.sendPaymentLink(request)
798
+
799
+ puts "Response: #{response.inspect}"
800
+
801
+
802
+ ```
803
+
804
+ #### Transaction Status
805
+
806
+
807
+
808
+ Returns the current status for any transaction. You can lookup a transaction
809
+ by its BlockChyp assigned Transaction ID or your own Transaction Ref.
810
+
811
+ You should alway use globally unique Transaction Ref values, but in the event
812
+ that you duplicate Transaction Refs, the most recent transaction matching your
813
+ Transaction Ref is returned.
814
+
815
+
816
+
817
+
818
+ ```ruby
819
+ # frozen_string_literal: true
820
+
821
+ require 'blockchyp'
822
+
823
+ blockchyp = BlockChyp::BlockChyp.new(
824
+ ENV['BC_API_KEY'],
825
+ ENV['BC_BEARER_TOKEN'],
826
+ ENV['BC_SIGNING_KEY']
827
+ )
828
+
829
+ # Set request parameters
830
+ request = {
831
+ "transactionId": 'ID of transaction to retrieve'
832
+ }
833
+
834
+ response = blockchyp.transactionStatus(request)
835
+
836
+ puts "Response: #{response.inspect}"
837
+
838
+
839
+ ```
840
+
841
+ #### Terminal Clear
842
+
843
+
844
+
845
+ This API interrupts whatever a terminal may be doing and returns it to the
846
+ idle state.
847
+
848
+
849
+
850
+
851
+
852
+ ```ruby
853
+ # frozen_string_literal: true
854
+
855
+ require 'blockchyp'
856
+
857
+ blockchyp = BlockChyp::BlockChyp.new(
858
+ ENV['BC_API_KEY'],
859
+ ENV['BC_BEARER_TOKEN'],
860
+ ENV['BC_SIGNING_KEY']
861
+ )
862
+
863
+ # Set request parameters
864
+ request = {
865
+ "test": true,
866
+ "terminalName": 'Test Terminal'
867
+ }
868
+
869
+ response = blockchyp.clear(request)
870
+
871
+ puts "Response: #{response.inspect}"
872
+
873
+
874
+ ```
875
+
876
+ #### Terminal Status
877
+
878
+
879
+
880
+ Returns the current status of a payment terminal. This is typically used
881
+ as a way to determine if the terminal is busy before sending a new transaction.
882
+
883
+ If the terminal is busy, `idle` will be false and the `status` field will return
884
+ a short string indicating the transaction type currently in progress. The system
885
+ will also return the timestamp of the last status change in the `since` field.
886
+
887
+ If the system is running a payment transaction and you wisely passed in a
888
+ Transaction Ref, this API will also return the Transaction Ref of the in progress
889
+ transaction.
890
+
891
+
892
+
893
+
894
+ ```ruby
895
+ # frozen_string_literal: true
896
+
897
+ require 'blockchyp'
898
+
899
+ blockchyp = BlockChyp::BlockChyp.new(
900
+ ENV['BC_API_KEY'],
901
+ ENV['BC_BEARER_TOKEN'],
902
+ ENV['BC_SIGNING_KEY']
903
+ )
904
+
905
+ # Set request parameters
906
+ request = {
907
+ "terminalName": 'Test Terminal'
908
+ }
909
+
910
+ response = blockchyp.terminalStatus(request)
911
+
912
+ puts "Response: #{response.inspect}"
913
+
914
+
915
+ ```
916
+
917
+ #### Terms & Conditions Capture
918
+
919
+
920
+
921
+ This API allows you to prompt a customer to accept a legal agreement on the terminal
922
+ and (usually) capture their signature.
923
+
924
+ Content for the agreement can be specified in two ways. You can reference a
925
+ previously configured T&C template or pass in the full agreement text with every request.
926
+
927
+ **Using Templates**
928
+
929
+ If your application doesn't keep track of agreements you can leverage BlockChyp's
930
+ template system. You can create any number of T&C Templates in the merchant dashboard
931
+ and pass in the `tcAlias` flag to specify which one to display.
932
+
933
+ **Raw Content**
934
+
935
+ If your system keeps track of the agreement language or executes complicated merging
936
+ and rendering logic, you can bypass our template system and pass in the full text with
937
+ every transaction. Use the `tcName` to pass in the agreement name and `tcContent` to
938
+ pass in the contract text. Note that only plain text is supported.
939
+
940
+ **Bypassing Signatures**
941
+
942
+ Signature images are captured by default. If for some reason this doesn't fit your
943
+ use case and you'd like to capture acceptance without actually capturing a signature image, set
944
+ the `disableSignature` flag in the request.
945
+
946
+ **Terms & Conditions Log**
947
+
948
+ Every time a user accepts an agreement on the terminal, the signature image (if captured),
949
+ will be uploaded to the gateway and added to the log along with the full text of the
950
+ agreement. This preserves the historical record in the event that standard agreements
951
+ or templates change over time.
952
+
953
+ **Associating Agreements with Transactions**
954
+
955
+ To associate a Terms & Conditions log entry with a transaction, just pass in the
956
+ Transaction ID or Transaction Ref for the associated transaction.
957
+
958
+
959
+
960
+
961
+
962
+ ```ruby
963
+ # frozen_string_literal: true
964
+
965
+ require 'blockchyp'
966
+
967
+ blockchyp = BlockChyp::BlockChyp.new(
968
+ ENV['BC_API_KEY'],
969
+ ENV['BC_BEARER_TOKEN'],
970
+ ENV['BC_SIGNING_KEY']
971
+ )
972
+
973
+ # Set request parameters
974
+ request = {
975
+ "test": true,
976
+ "terminalName": 'Test Terminal',
977
+
978
+ # Alias for a Terms and Conditions template configured in the BlockChyp
979
+ # dashboard.
980
+ "tcAlias": 'hippa',
981
+
982
+ # Name of the contract or document if not using an alias.
983
+ "tcName": 'HIPPA Disclosure',
984
+
985
+ # Full text of the contract or disclosure if not using an alias.
986
+ "tcContent": 'Full contract text',
987
+
988
+ # File format for the signature image.
989
+ "sigFormat": SignatureFormat::PNG,
990
+
991
+ # Width of the signature image in pixels.
992
+ "sigWidth": 200,
993
+
994
+ # Whether or not a signature is required. Defaults to true.
995
+ "sigRequired": true
996
+ }
997
+
998
+ response = blockchyp.termsAndConditions(request)
999
+
1000
+ puts "Response: #{response.inspect}"
1001
+
1002
+
1003
+ ```
1004
+
1005
+ #### Capture Signature
1006
+
1007
+
1008
+
1009
+ This endpoint captures a written signature from the terminal and returns the
1010
+ image.
1011
+
1012
+ Unlike the Terms & Conditions API, this endpoint performs basic signature
1013
+ capture with no agreement display or signature archival.
1014
+
1015
+ Under the hood, signatures are captured in a proprietary vector format and
1016
+ must be converted to a common raster format in order to be useful to most
1017
+ applications. At a minimum, you must specify an image format using the
1018
+ `sigFormat` parameter. As of this writing JPG and PNG are supported.
1019
+
1020
+ By default, images are returned in the JSON response as hex encoded binary.
1021
+ You can redirect the binary image output to a file using the `sigFile`
1022
+ parameter.
1023
+
1024
+ You can also scale the output image to your preferred width by
1025
+ passing in a `sigWidth` parameter. The image will be scaled to that
1026
+ width, preserving the aspect ratio of the original image.
1027
+
1028
+
1029
+
1030
+
1031
+ ```ruby
1032
+ # frozen_string_literal: true
1033
+
1034
+ require 'blockchyp'
1035
+
1036
+ blockchyp = BlockChyp::BlockChyp.new(
1037
+ ENV['BC_API_KEY'],
1038
+ ENV['BC_BEARER_TOKEN'],
1039
+ ENV['BC_SIGNING_KEY']
1040
+ )
1041
+
1042
+ # Set request parameters
1043
+ request = {
1044
+ "terminalName": 'Test Terminal',
1045
+
1046
+ # File format for the signature image.
1047
+ "sigFormat": SignatureFormat::PNG,
1048
+
1049
+ # Width of the signature image in pixels.
1050
+ "sigWidth": 200
1051
+ }
1052
+
1053
+ response = blockchyp.captureSignature(request)
1054
+
1055
+ puts "Response: #{response.inspect}"
1056
+
1057
+
1058
+ ```
1059
+
1060
+ #### New Transaction Display
1061
+
1062
+
1063
+
1064
+ Sends totals and line item level data to the terminal.
1065
+
1066
+ At a minimum, you should send total information as part of a display request,
1067
+ including `total`, `tax`, and `subtotal`.
1068
+
1069
+ You can also send line item level data and each line item can have a `description`,
1070
+ `qty`, `price`, and `extended` price.
1071
+
1072
+ If you fail to send an extended price, BlockChyp will multiply the `qty` by the
1073
+ `price`, but we strongly recommend you precalculate all the fields yourself
1074
+ to ensure consistency. Your treatment of floating-point multiplication and rounding
1075
+ may differ slightly from BlockChyp's, for example.
1076
+
1077
+ **Discounts**
1078
+
1079
+ You have the option to show discounts on the display as individual line items
1080
+ with negative values or you can associate discounts with a specific line item.
1081
+ You can apply any number of discounts to an individual line item with a description
1082
+ and amount.
1083
+
1084
+
1085
+
1086
+
1087
+ ```ruby
1088
+ # frozen_string_literal: true
1089
+
1090
+ require 'blockchyp'
1091
+
1092
+ blockchyp = BlockChyp::BlockChyp.new(
1093
+ ENV['BC_API_KEY'],
1094
+ ENV['BC_BEARER_TOKEN'],
1095
+ ENV['BC_SIGNING_KEY']
1096
+ )
1097
+
1098
+ # Set request parameters
1099
+ request = {
1100
+ "test": true,
1101
+ "terminalName": 'Test Terminal',
1102
+ "transaction": {
1103
+ "subtotal": '60.00',
1104
+ "tax": '5.00',
1105
+ "total": '65.00',
1106
+ "items": [
1107
+ {
1108
+ "description": 'Leki Trekking Poles',
1109
+ "price": '35.00',
1110
+ "quantity": 2,
1111
+ "extended": '70.00',
1112
+ "discounts": [
1113
+ {
1114
+ "description": 'memberDiscount',
1115
+ "amount": '10.00'
1116
+ }
1117
+ ]
1118
+ }
1119
+ ]
1120
+ }
480
1121
  }
481
1122
 
482
- response = blockchyp.message(request)
1123
+ response = blockchyp.newTransactionDisplay(request)
483
1124
 
484
1125
  puts "Response: #{response.inspect}"
485
1126
 
486
1127
 
487
1128
  ```
488
1129
 
489
- #### Refund
490
-
491
- Executes a refund.
1130
+ #### Update Transaction Display
492
1131
 
493
1132
 
494
- ```ruby
495
- # frozen_string_literal: true
496
1133
 
497
- require 'blockchyp'
1134
+ Similar to *New Transaction Display*, this variant allows developers to update
1135
+ line item level data currently being displayed on the terminal.
498
1136
 
499
- blockchyp = BlockChyp::BlockChyp.new(
500
- ENV['BC_API_KEY'],
501
- ENV['BC_BEARER_TOKEN'],
502
- ENV['BC_SIGNING_KEY']
503
- )
1137
+ This is designed for situations where you want to update the terminal display as
1138
+ items are scanned. This variant means you only have to send information to the
1139
+ terminal that's changed, which usually means the new line item and updated totals.
504
1140
 
505
- # Set request parameters
506
- request = {
507
- "terminalName": 'Test Terminal',
508
- "transactionId": '<PREVIOUS TRANSACTION ID>',
1141
+ If the terminal is not in line item display mode and you invoke this endpoint,
1142
+ the first invocation will behave like a *New Transaction Display* call.
509
1143
 
510
- # Optional amount for partial refunds.
511
- "amount": '5.00'
512
- }
1144
+ At a minimum, you should send total information as part of a display request,
1145
+ including `total`, `tax`, and `subtotal`.
513
1146
 
514
- response = blockchyp.refund(request)
1147
+ You can also send line item level data and each line item can have a `description`,
1148
+ `qty`, `price`, and `extended` price.
515
1149
 
516
- puts "Response: #{response.inspect}"
1150
+ If you fail to send an extended price, BlockChyp will multiply the `qty` by the
1151
+ `price`, but we strongly recommend you precalculate all the fields yourself
1152
+ to ensure consistency. Your treatment of floating-point multiplication and rounding
1153
+ may differ slightly from BlockChyp's, for example.
517
1154
 
1155
+ **Discounts**
518
1156
 
519
- ```
1157
+ You have the option to show discounts on the display as individual line items
1158
+ with negative values or you can associate discounts with a specific line item.
1159
+ You can apply any number of discounts to an individual line item with a description
1160
+ and amount.
520
1161
 
521
- #### Enroll
522
1162
 
523
- Adds a new payment method to the token vault.
524
1163
 
525
1164
 
526
1165
  ```ruby
@@ -537,19 +1176,44 @@ blockchyp = BlockChyp::BlockChyp.new(
537
1176
  # Set request parameters
538
1177
  request = {
539
1178
  "test": true,
540
- "terminalName": 'Test Terminal'
1179
+ "terminalName": 'Test Terminal',
1180
+ "transaction": {
1181
+ "subtotal": '60.00',
1182
+ "tax": '5.00',
1183
+ "total": '65.00',
1184
+ "items": [
1185
+ {
1186
+ "description": 'Leki Trekking Poles',
1187
+ "price": '35.00',
1188
+ "quantity": 2,
1189
+ "extended": '70.00',
1190
+ "discounts": [
1191
+ {
1192
+ "description": 'memberDiscount',
1193
+ "amount": '10.00'
1194
+ }
1195
+ ]
1196
+ }
1197
+ ]
1198
+ }
541
1199
  }
542
1200
 
543
- response = blockchyp.enroll(request)
1201
+ response = blockchyp.updateTransactionDisplay(request)
544
1202
 
545
1203
  puts "Response: #{response.inspect}"
546
1204
 
547
1205
 
548
1206
  ```
549
1207
 
550
- #### Gift Card Activation
1208
+ #### Display Message
1209
+
1210
+
1211
+
1212
+ Displays a message on the payment terminal.
1213
+
1214
+ Just specify the target terminal and the message using the `message` parameter.
1215
+
551
1216
 
552
- Activates or recharges a gift card.
553
1217
 
554
1218
 
555
1219
  ```ruby
@@ -567,27 +1231,34 @@ blockchyp = BlockChyp::BlockChyp.new(
567
1231
  request = {
568
1232
  "test": true,
569
1233
  "terminalName": 'Test Terminal',
570
- "amount": '50.00'
1234
+ "message": 'Thank you for your business.'
571
1235
  }
572
1236
 
573
- response = blockchyp.giftActivate(request)
1237
+ response = blockchyp.message(request)
574
1238
 
575
1239
  puts "Response: #{response.inspect}"
576
1240
 
577
1241
 
578
1242
  ```
579
1243
 
580
- #### Time Out Reversal
1244
+ #### Boolean Prompt
1245
+
1246
+
1247
+
1248
+ Prompts the customer to answer a yes or no question.
1249
+
1250
+ You can specify the question or prompt with the `prompt` parameter and
1251
+ the response is returned in the `response` field.
1252
+
1253
+ This can be used for a number of use cases including starting a loyalty enrollment
1254
+ workflow or customer facing suggestive selling prompts.
1255
+
1256
+ **Custom Captions**
1257
+
1258
+ You can optionally override the "YES" and "NO" button captions by
1259
+ using the `yesCaption` and `noCaption` request parameters.
581
1260
 
582
- Executes a manual time out reversal.
583
1261
 
584
- We love time out reversals. Don't be afraid to use them whenever a request to a
585
- BlockChyp terminal times out. You have up to two minutes to reverse any
586
- transaction. The only caveat is that you must assign transactionRef values when
587
- you build the original request. Otherwise, we have no real way of knowing which
588
- transaction you're trying to reverse because we may not have assigned it an id
589
- yet. And if we did assign it an id, you wouldn't know what it is because your
590
- request to the terminal timed out before you got a response.
591
1262
 
592
1263
 
593
1264
  ```ruby
@@ -603,20 +1274,47 @@ blockchyp = BlockChyp::BlockChyp.new(
603
1274
 
604
1275
  # Set request parameters
605
1276
  request = {
1277
+ "test": true,
606
1278
  "terminalName": 'Test Terminal',
607
- "transactionRef": '<LAST TRANSACTION REF>'
1279
+ "prompt": 'Would you like to become a member?',
1280
+ "yesCaption": 'Yes',
1281
+ "noCaption": 'No'
608
1282
  }
609
1283
 
610
- response = blockchyp.reverse(request)
1284
+ response = blockchyp.booleanPrompt(request)
611
1285
 
612
1286
  puts "Response: #{response.inspect}"
613
1287
 
614
1288
 
615
1289
  ```
616
1290
 
617
- #### Capture Preauthorization
1291
+ #### Text Prompt
1292
+
1293
+
1294
+
1295
+ Prompts the customer to enter numeric or alphanumeric data.
1296
+
1297
+ Due to PCI rules, free form prompts are not permitted when the response
1298
+ could be any valid string. The reason for this is that a malicious
1299
+ developer (not you, of course) could use text prompts to ask the customer to
1300
+ input a card number or PIN code.
1301
+
1302
+ This means that instead of providing a prompt, you provide a `promptType` instead.
1303
+
1304
+ The prompt types currently supported are listed below:
1305
+
1306
+ * **phone**: Captures a phone number.
1307
+ * **email**: Captures an email address.
1308
+ * **first-name**: Captures a first name.
1309
+ * **last-name**: Captures a last name.
1310
+ * **customer-number**: Captures a customer number.
1311
+ * **rewards-number**: Captures a rewards number.
1312
+
1313
+ You can specify the prompt with the `promptType` parameter and
1314
+ the response is returned in the `response` field.
1315
+
1316
+
618
1317
 
619
- Captures a preauthorization.
620
1318
 
621
1319
 
622
1320
  ```ruby
@@ -633,47 +1331,49 @@ blockchyp = BlockChyp::BlockChyp.new(
633
1331
  # Set request parameters
634
1332
  request = {
635
1333
  "test": true,
636
- "transactionId": '<PREAUTH TRANSACTION ID>'
1334
+ "terminalName": 'Test Terminal',
1335
+
1336
+ # Type of prompt. Can be 'email', 'phone', 'customer-number', or
1337
+ # 'rewards-number'.
1338
+ "promptType": PromptType::EMAIL
637
1339
  }
638
1340
 
639
- response = blockchyp.capture(request)
1341
+ response = blockchyp.textPrompt(request)
640
1342
 
641
1343
  puts "Response: #{response.inspect}"
642
1344
 
643
1345
 
644
1346
  ```
645
1347
 
646
- #### Close Batch
647
-
648
- Closes the current credit card batch.
1348
+ #### Update Customer
649
1349
 
650
1350
 
651
- ```ruby
652
- # frozen_string_literal: true
653
1351
 
654
- require 'blockchyp'
1352
+ Adds or updates a customer record.
655
1353
 
656
- blockchyp = BlockChyp::BlockChyp.new(
657
- ENV['BC_API_KEY'],
658
- ENV['BC_BEARER_TOKEN'],
659
- ENV['BC_SIGNING_KEY']
660
- )
1354
+ If you pass in customer information including `firstName`, `lastName`, `email`,
1355
+ `email`, or `sms` without any Customer ID or Customer Ref, a new record will
1356
+ be created.
661
1357
 
662
- # Set request parameters
663
- request = {
664
- "test": true
665
- }
1358
+ If you pass in `customerRef` and `customerId`, the customer record will be updated
1359
+ if it exists.
666
1360
 
667
- response = blockchyp.closeBatch(request)
1361
+ **Customer Ref**
668
1362
 
669
- puts "Response: #{response.inspect}"
1363
+ The `customerRef` field is optional, but highly recommended as this allows you
1364
+ to use your own customer identifiers instead of storing BlockChyp's Customer IDs
1365
+ in your systems.
670
1366
 
1367
+ **Creating Customer Records With Payment Transactions**
671
1368
 
672
- ```
1369
+ If you have customer information available at the time a payment transaction is
1370
+ executed, you can pass all the same customer information directly into a payment transaction and
1371
+ create a customer record at the same time payment is captured. The advantage of this approach is
1372
+ that the customer's payment card is automatically associated with the customer record in a single step.
1373
+ If the customer uses the payment card in the future, the customer data will automatically
1374
+ be returned without needing to ask the customer to provide any additional information.
673
1375
 
674
- #### Void Transaction
675
1376
 
676
- Discards a previous preauth transaction.
677
1377
 
678
1378
 
679
1379
  ```ruby
@@ -689,20 +1389,34 @@ blockchyp = BlockChyp::BlockChyp.new(
689
1389
 
690
1390
  # Set request parameters
691
1391
  request = {
692
- "test": true,
693
- "transactionId": '<PREVIOUS TRANSACTION ID>'
1392
+ "customer": {
1393
+ "id": 'ID of the customer to update',
1394
+ "customerRef": 'Customer reference string',
1395
+ "firstName": 'FirstName',
1396
+ "lastName": 'LastName',
1397
+ "companyName": 'Company Name',
1398
+ "emailAddress": 'support@blockchyp.com',
1399
+ "smsNumber": '(123) 123-1231'
1400
+ }
694
1401
  }
695
1402
 
696
- response = blockchyp.void(request)
1403
+ response = blockchyp.updateCustomer(request)
697
1404
 
698
1405
  puts "Response: #{response.inspect}"
699
1406
 
700
1407
 
701
1408
  ```
702
1409
 
703
- #### Terminal Status
1410
+ #### Retrieve Customer
1411
+
1412
+
1413
+
1414
+ Retrieves detailed information about a customer record, including saved payment
1415
+ methods if available.
1416
+
1417
+ Customers can be looked up by `customerId` or `customerRef`.
1418
+
704
1419
 
705
- Returns the current status of a terminal.
706
1420
 
707
1421
 
708
1422
  ```ruby
@@ -718,19 +1432,26 @@ blockchyp = BlockChyp::BlockChyp.new(
718
1432
 
719
1433
  # Set request parameters
720
1434
  request = {
721
- "terminalName": 'Test Terminal'
1435
+ "customerId": 'ID of the customer to retrieve'
722
1436
  }
723
1437
 
724
- response = blockchyp.terminalStatus(request)
1438
+ response = blockchyp.customer(request)
725
1439
 
726
1440
  puts "Response: #{response.inspect}"
727
1441
 
728
1442
 
729
1443
  ```
730
1444
 
731
- #### Capture Signature.
1445
+ #### Search Customer
1446
+
1447
+
1448
+
1449
+ Searches the customer database and returns matching results.
1450
+
1451
+ Use `query` to pass in a search string and the system will return all results whose
1452
+ first or last names contain the query string.
1453
+
732
1454
 
733
- Captures and returns a signature.
734
1455
 
735
1456
 
736
1457
  ```ruby
@@ -746,25 +1467,27 @@ blockchyp = BlockChyp::BlockChyp.new(
746
1467
 
747
1468
  # Set request parameters
748
1469
  request = {
749
- "terminalName": 'Test Terminal',
750
-
751
- # File format for the signature image.
752
- "sigFormat": SignatureFormat::PNG,
753
-
754
- # Width of the signature image in pixels.
755
- "sigWidth": 200
1470
+ "query": '(123) 123-1234'
756
1471
  }
757
1472
 
758
- response = blockchyp.captureSignature(request)
1473
+ response = blockchyp.customerSearch(request)
759
1474
 
760
1475
  puts "Response: #{response.inspect}"
761
1476
 
762
1477
 
763
1478
  ```
764
1479
 
765
- #### Update Customer
1480
+ #### Cash Discount
1481
+
1482
+
1483
+
1484
+ Calculates the surcharge, cash discount, and total amounts for cash transactions.
1485
+
1486
+ If you're using BlockChyp's cash discounting features, you can use this endpoint
1487
+ to make sure the numbers and receipts for true cash transactions are consistent
1488
+ with transactions processed by BlockChyp.
1489
+
766
1490
 
767
- Updates or creates a customer record.
768
1491
 
769
1492
 
770
1493
  ```ruby
@@ -780,27 +1503,45 @@ blockchyp = BlockChyp::BlockChyp.new(
780
1503
 
781
1504
  # Set request parameters
782
1505
  request = {
783
- "customer": {
784
- "id": 'ID of the customer to update',
785
- "customerRef": 'Customer reference string',
786
- "firstName": 'FirstName',
787
- "lastName": 'LastName',
788
- "companyName": 'Company Name',
789
- "emailAddress": 'support@blockchyp.com',
790
- "smsNumber": '(123) 123-1231'
791
- }
1506
+ "amount": '100.00',
1507
+ "cashDiscount": true,
1508
+ "surcharge": true
792
1509
  }
793
1510
 
794
- response = blockchyp.updateCustomer(request)
1511
+ response = blockchyp.cashDiscount(request)
795
1512
 
796
1513
  puts "Response: #{response.inspect}"
797
1514
 
798
1515
 
799
1516
  ```
800
1517
 
801
- #### Retrieve Customer
1518
+ #### Batch History
1519
+
1520
+
1521
+
1522
+ This endpoint allows developers to query the gateway for the merchant's batch history.
1523
+ The data will be returned in descending order of open date with the most recent
1524
+ batch returned first. The results will include basic information about the batch.
1525
+ For more detail about a specific batch, consider using the Batch Details API.
1526
+
1527
+ **Limiting Results**
1528
+
1529
+ This API will return a maximum of 250 results. Use the `maxResults` property to
1530
+ limit maximum results even further and use the `startIndex` property to
1531
+ page through results that span multiple queries.
1532
+
1533
+ For example, if you want the ten most recent batches, just pass in a value of
1534
+ `10` for `maxResults`. Also note that `startIndex` is zero based. Use a value of `0` to
1535
+ get the first batch in the dataset.
1536
+
1537
+ **Filtering By Date Range**
1538
+
1539
+ You can also filter results by date. Use the `startDate` and `endDate`
1540
+ properties to return only those batches opened between those dates.
1541
+ You can use either `startDate` and `endDate` and you can use date filters
1542
+ in conjunction with `maxResults` and `startIndex`
1543
+
802
1544
 
803
- Retrieves a customer by id.
804
1545
 
805
1546
 
806
1547
  ```ruby
@@ -816,19 +1557,30 @@ blockchyp = BlockChyp::BlockChyp.new(
816
1557
 
817
1558
  # Set request parameters
818
1559
  request = {
819
- "customerId": 'ID of the customer to retrieve'
1560
+ "maxResults": 250,
1561
+ "startIndex": 1
820
1562
  }
821
1563
 
822
- response = blockchyp.customer(request)
1564
+ response = blockchyp.batchHistory(request)
823
1565
 
824
1566
  puts "Response: #{response.inspect}"
825
1567
 
826
1568
 
827
1569
  ```
828
1570
 
829
- #### Search Customer
1571
+ #### Batch Details
1572
+
1573
+
1574
+
1575
+ This endpoint allows developers to pull down details for a specific batch,
1576
+ including captured volume, gift card activity, expected deposit, and
1577
+ captured volume broken down by terminal.
1578
+
1579
+ The only required request parameter is `batchId`. Batch IDs are returned
1580
+ with every transaction response and can also be discovered using the Batch
1581
+ History API.
1582
+
830
1583
 
831
- Searches the customer database.
832
1584
 
833
1585
 
834
1586
  ```ruby
@@ -844,47 +1596,59 @@ blockchyp = BlockChyp::BlockChyp.new(
844
1596
 
845
1597
  # Set request parameters
846
1598
  request = {
847
- "query": '(123) 123-1234'
1599
+ "batchId": 'BATCHID'
848
1600
  }
849
1601
 
850
- response = blockchyp.customerSearch(request)
1602
+ response = blockchyp.batchDetails(request)
851
1603
 
852
1604
  puts "Response: #{response.inspect}"
853
1605
 
854
1606
 
855
1607
  ```
856
1608
 
857
- #### Transaction Status
1609
+ #### Transaction History
858
1610
 
859
- Retrieves the current status of a transaction.
860
1611
 
861
1612
 
862
- ```ruby
863
- # frozen_string_literal: true
1613
+ This endpoint provides a number of different methods to sift through
1614
+ transaction history.
864
1615
 
865
- require 'blockchyp'
1616
+ By default with no filtering properties, this endpoint will return the 250
1617
+ most recent transactions.
866
1618
 
867
- blockchyp = BlockChyp::BlockChyp.new(
868
- ENV['BC_API_KEY'],
869
- ENV['BC_BEARER_TOKEN'],
870
- ENV['BC_SIGNING_KEY']
871
- )
1619
+ **Limiting Results**
872
1620
 
873
- # Set request parameters
874
- request = {
875
- "transactionId": 'ID of transaction to retrieve'
876
- }
1621
+ This API will return a maximum of 250 results in a single query. Use the `maxResults` property
1622
+ to limit maximum results even further and use the `startIndex` property to
1623
+ page through results that span multiple queries.
877
1624
 
878
- response = blockchyp.transactionStatus(request)
1625
+ For example, if you want the ten most recent batches, just pass in a value of
1626
+ `10` for `maxResults`. Also note that `startIndex` is zero based. Use a value of `0` to
1627
+ get the first transaction in the dataset.
879
1628
 
880
- puts "Response: #{response.inspect}"
1629
+ **Filtering By Date Range**
881
1630
 
1631
+ You can also filter results by date. Use the `startDate` and `endDate`
1632
+ properties to return only transactions run between those dates.
1633
+ You can use either `startDate` or `endDate` and you can use date filters
1634
+ in conjunction with `maxResults` and `startIndex`
882
1635
 
883
- ```
1636
+ **Filtering By Batch**
1637
+
1638
+ To restrict results to a single batch, pass in the `batchId` parameter.
1639
+
1640
+ **Filtering By Terminal**
1641
+
1642
+ To restrict results to those executed on a single terminal, just
1643
+ pass in the terminal name.
1644
+
1645
+ **Combining Filters**
1646
+
1647
+ None of the above filters are mutually exclusive. You can combine any of the
1648
+ above properties in a single request to restrict transaction results to a
1649
+ narrower set of results.
884
1650
 
885
- #### Send Payment Link
886
1651
 
887
- Creates and send a payment link to a customer.
888
1652
 
889
1653
 
890
1654
  ```ruby
@@ -900,33 +1664,10 @@ blockchyp = BlockChyp::BlockChyp.new(
900
1664
 
901
1665
  # Set request parameters
902
1666
  request = {
903
- "amount": '199.99',
904
- "description": 'Widget',
905
- "subject": 'Widget invoice',
906
- "transaction": {
907
- "subtotal": '195.00',
908
- "tax": '4.99',
909
- "total": '199.99',
910
- "items": [
911
- {
912
- "description": 'Widget',
913
- "price": '195.00',
914
- "quantity": 1
915
- }
916
- ]
917
- },
918
- "autoSend": true,
919
- "customer": {
920
- "customerRef": 'Customer reference string',
921
- "firstName": 'FirstName',
922
- "lastName": 'LastName',
923
- "companyName": 'Company Name',
924
- "emailAddress": 'support@blockchyp.com',
925
- "smsNumber": '(123) 123-1231'
926
- }
1667
+ "maxResults": 10
927
1668
  }
928
1669
 
929
- response = blockchyp.sendPaymentLink(request)
1670
+ response = blockchyp.transactionHistory(request)
930
1671
 
931
1672
  puts "Response: #{response.inspect}"
932
1673
 
@@ -987,3 +1728,24 @@ Copyright BlockChyp, Inc., 2019
987
1728
  Distributed under the terms of the [MIT] license, blockchyp-ruby is free and open source software.
988
1729
 
989
1730
  [MIT]: https://github.com/blockchyp/blockchyp-ruby/blob/master/LICENSE
1731
+
1732
+ ## Other SDKs
1733
+
1734
+ BlockChyp has officially supported SDKs for eight different development platforms and counting.
1735
+ Here's the full list with links to their GitHub repositories.
1736
+
1737
+ [Go SDK](https://github.com/blockchyp/blockchyp-go)
1738
+
1739
+ [Node.js/JavaScript SDK](https://github.com/blockchyp/blockchyp-js)
1740
+
1741
+ [Java SDK](https://github.com/blockchyp/blockchyp-java)
1742
+
1743
+ [.net/C# SDK](https://github.com/blockchyp/blockchyp-csharp)
1744
+
1745
+ [Ruby SDK](https://github.com/blockchyp/blockchyp-ruby)
1746
+
1747
+ [PHP SDK](https://github.com/blockchyp/blockchyp-php)
1748
+
1749
+ [Python SDK](https://github.com/blockchyp/blockchyp-python)
1750
+
1751
+ [iOS (Objective-C/Swift) SDK](https://github.com/blockchyp/blockchyp-ios)