blockchyp 2.3.1 → 2.3.2

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: a9b0bc43922617adfcb4e8f0d20eef4d54a5dac3aee17efd246aaa6789caeac7
4
- data.tar.gz: c21e621def8bc145fe223771f205912ea20a0596ade43bf04f1a9c462ba476c7
3
+ metadata.gz: 6d481215ba0fe7d5cee061463d93274a0d8f088fdec08a0a6cb8236c47366917
4
+ data.tar.gz: fab48021f9c4d0afd995a2027d65125d13e7827eb427389729292be5cee2083c
5
5
  SHA512:
6
- metadata.gz: b7e80346fa5aef7adacb2d2328cf4639bd937c235a750ab835dfa16a576c26223df9c5ca7fdfec9b1b6f49ab36b13898240cc07660aff3e7b7184e7181e11670
7
- data.tar.gz: 5855fa07b214ba2eee7327c93af6eaefd73b2781e1a584658637ba63c89eb12a8af583a6226490fff027a5ea62eee900ba9de41c604f1c413c752b607dbcc699
6
+ metadata.gz: 78ea652f19b13953b7c6b146416eaff3120709756e4231dd70c656069d08bc1ac4dd18969cd2bfc83dcd82d0b5d5a18efea3290ff7ac9b817f7b6fec4b87c33e
7
+ data.tar.gz: 7d9d412d62e19e33ba6f1b057ca6f21b2ff3c3d74c6ef1213fbc0868a8bd904390d9214d49e8b518a26fdaf4b7e2e730fea9fddc945b284097834204645bd477
data/README.md CHANGED
@@ -98,9 +98,21 @@ You can also view a number of long form demos and learn more about us on our [Yo
98
98
  You don't want to read words. You want examples. Here's a quick rundown of the
99
99
  stuff you can do with the BlockChyp Ruby SDK and a few basic examples.
100
100
 
101
- #### Charge
101
+ #### Terminal Ping
102
+
103
+
104
+ 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.
105
+
106
+ It tests communication with the terminal and returns a positive response if everything
107
+ is okay. It works the same way in local or cloud relay mode.
108
+
109
+ If you get a positive response, you've successfully verified all of the following:
110
+
111
+ * The terminal is online.
112
+ * There is a valid route to the terminal.
113
+ * The API Credential are valid.
114
+
102
115
 
103
- Executes a standard direct preauth and capture.
104
116
 
105
117
 
106
118
  ```ruby
@@ -116,21 +128,53 @@ blockchyp = BlockChyp::BlockChyp.new(
116
128
 
117
129
  # Set request parameters
118
130
  request = {
119
- "test": true,
120
- "terminalName": 'Test Terminal',
121
- "amount": '55.00'
131
+ "terminalName": 'Test Terminal'
122
132
  }
123
133
 
124
- response = blockchyp.charge(request)
134
+ response = blockchyp.ping(request)
125
135
 
126
136
  puts "Response: #{response.inspect}"
127
137
 
128
138
 
129
139
  ```
130
140
 
131
- #### Preauthorization
141
+ #### Charge
142
+
143
+
144
+ Our most popular transaction executes a standard authorization and capture.
145
+ This is the most basic of
146
+ basic payment transactions, typically used in conventional retail.
147
+
148
+ Charge transactions can use a payment terminal to capture a payment or
149
+ use a previously enrolled payment token.
150
+
151
+ **Terminal Transactions**
152
+
153
+ For terminal transactions, make sure you pass in the terminal name using the `terminalName` property.
154
+
155
+ **Token Transactions**
156
+
157
+ If you have a payment token, omit the `terminalName` property and pass in the token with the `token`
158
+ property instead.
159
+
160
+ **Card Numbers and Mag Stripes**
161
+
162
+ You can also pass in PANs and Mag Stripes, but you probably shouldn't. This will
163
+ put you in PCI scope and the most common vector for POS breaches is key logging.
164
+ If you use terminals for manual card entry, you'll bypass any key loggers that
165
+ might be maliciously running on the point-of-sale system.
166
+
167
+ **Common Variations**
168
+
169
+ * **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.
170
+ * **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.
171
+ * **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.
172
+ * **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.
173
+ * **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.
174
+ * **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 services related scenarios.
175
+ * **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.
176
+
132
177
 
133
- Executes a preauthorization intended to be captured later.
134
178
 
135
179
 
136
180
  ```ruby
@@ -148,47 +192,53 @@ blockchyp = BlockChyp::BlockChyp.new(
148
192
  request = {
149
193
  "test": true,
150
194
  "terminalName": 'Test Terminal',
151
- "amount": '27.00'
195
+ "amount": '55.00'
152
196
  }
153
197
 
154
- response = blockchyp.preauth(request)
198
+ response = blockchyp.charge(request)
155
199
 
156
200
  puts "Response: #{response.inspect}"
157
201
 
158
202
 
159
203
  ```
160
204
 
161
- #### Terminal Ping
205
+ #### Preauthorization
162
206
 
163
- Tests connectivity with a payment terminal.
164
207
 
208
+ A preauthorization puts a hold on funds and must be captured later. This is used
209
+ in scenarios where the final transaction amount might change. Examples would
210
+ be fine dining where a tip adjustment is required prior to capture or hotels
165
211
 
166
- ```ruby
167
- # frozen_string_literal: true
212
+ Another use case for preauthorization is e-commerce. Typically, an online order
213
+ is preauthorized at the time of the order and then captured when the order ships.
168
214
 
169
- require 'blockchyp'
215
+ Preauthorizations can use a payment terminal to capture a payment or
216
+ use a previously enrolled payment token.
170
217
 
171
- blockchyp = BlockChyp::BlockChyp.new(
172
- ENV['BC_API_KEY'],
173
- ENV['BC_BEARER_TOKEN'],
174
- ENV['BC_SIGNING_KEY']
175
- )
218
+ **Terminal Transactions**
176
219
 
177
- # Set request parameters
178
- request = {
179
- "terminalName": 'Test Terminal'
180
- }
220
+ For terminal transactions, make sure you pass in the terminal name using the `terminalName` property.
181
221
 
182
- response = blockchyp.ping(request)
222
+ **Token Transactions**
183
223
 
184
- puts "Response: #{response.inspect}"
224
+ If you have a payment token, omit the `terminalName` property and pass in the token with the `token`
225
+ property instead.
185
226
 
227
+ **Card Numbers and Mag Stripes**
186
228
 
187
- ```
229
+ You can also pass in PANs and Mag Stripes, but you probably shouldn't. This will
230
+ put you in PCI scope and the most common vector for POS breaches is key logging.
231
+ If you use terminals for manual card entry, you'll bypass any key loggers that
232
+ might be maliciously running on the point-of-sale system.
233
+
234
+ **Common Variations**
235
+
236
+ * **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.
237
+ * **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.
238
+ * **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.
239
+ * **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
240
 
189
- #### Balance
190
241
 
191
- Checks the remaining balance on a payment method.
192
242
 
193
243
 
194
244
  ```ruby
@@ -206,19 +256,29 @@ blockchyp = BlockChyp::BlockChyp.new(
206
256
  request = {
207
257
  "test": true,
208
258
  "terminalName": 'Test Terminal',
209
- "cardType": CardType::EBT
259
+ "amount": '27.00'
210
260
  }
211
261
 
212
- response = blockchyp.balance(request)
262
+ response = blockchyp.preauth(request)
213
263
 
214
264
  puts "Response: #{response.inspect}"
215
265
 
216
266
 
217
267
  ```
218
268
 
219
- #### Terminal Clear
269
+ #### Capture Preauthorization
270
+
271
+
272
+ This API allows you to capture a previously approved preauthorization.
273
+
274
+ 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
275
+ exact amount of the preauth, the Transaction ID is all you need to pass in.
276
+
277
+ You can adjust the total if you need to by passing in a new `amount`. We
278
+ also recommend you pass in updated amounts for `tax` and `tip` as it can
279
+ reduce your interchange fees in some cases. (Level II Processing, for example.)
280
+
220
281
 
221
- Clears the line item display and any in progress transaction.
222
282
 
223
283
 
224
284
  ```ruby
@@ -235,69 +295,66 @@ blockchyp = BlockChyp::BlockChyp.new(
235
295
  # Set request parameters
236
296
  request = {
237
297
  "test": true,
238
- "terminalName": 'Test Terminal'
298
+ "transactionId": '<PREAUTH TRANSACTION ID>'
239
299
  }
240
300
 
241
- response = blockchyp.clear(request)
301
+ response = blockchyp.capture(request)
242
302
 
243
303
  puts "Response: #{response.inspect}"
244
304
 
245
305
 
246
306
  ```
247
307
 
248
- #### Terms & Conditions Capture
308
+ #### Refund
249
309
 
250
- Prompts the user to accept terms and conditions.
251
310
 
311
+ It's not ideal, but sometimes customers want their money back.
252
312
 
253
- ```ruby
254
- # frozen_string_literal: true
313
+ Our refund API allows you to confront this unpleasant reality by executing refunds in a few different scenarios.
255
314
 
256
- require 'blockchyp'
315
+ 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
316
+ 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.
257
317
 
258
- blockchyp = BlockChyp::BlockChyp.new(
259
- ENV['BC_API_KEY'],
260
- ENV['BC_BEARER_TOKEN'],
261
- ENV['BC_SIGNING_KEY']
262
- )
318
+ **Partial Refunds**
263
319
 
264
- # Set request parameters
265
- request = {
266
- "test": true,
267
- "terminalName": 'Test Terminal',
320
+ For a partial refund, just passing an amount along with the Transaction ID.
321
+ The only rule is that the amount has to be equal to or less than the original
322
+ transaction. You can even execute multiple partial refunds against the same
323
+ original transaction as long as the total refunded amount doesn't exceed the original transaction.
268
324
 
269
- # Alias for a Terms and Conditions template configured in the BlockChyp
270
- # dashboard.
271
- "tcAlias": 'hippa',
325
+ **Tokenized Refunds**
272
326
 
273
- # Name of the contract or document if not using an alias.
274
- "tcName": 'HIPPA Disclosure',
327
+ You can also use a token to execute a refund. Just pass in a token instead
328
+ of the Transaction ID along with the desired refund amount.
275
329
 
276
- # Full text of the contract or disclosure if not using an alias.
277
- "tcContent": 'Full contract text',
330
+ **Free Range Refunds**
278
331
 
279
- # File format for the signature image.
280
- "sigFormat": SignatureFormat::PNG,
332
+ When you execute a refund without referencing a previous transaction, we
333
+ call this a *free range refund*.
281
334
 
282
- # Width of the signature image in pixels.
283
- "sigWidth": 200,
335
+ We don't recommend it, but it is permitted. Just pass in a
336
+ Terminal Name and an amount.
284
337
 
285
- # Whether or not a signature is required. Defaults to true.
286
- "sigRequired": true
287
- }
338
+ You can even execute a manual or keyed refund by passing the `manual` flag
339
+ to a free range refund request.
288
340
 
289
- response = blockchyp.termsAndConditions(request)
341
+ **Gift Card Refunds**
290
342
 
291
- puts "Response: #{response.inspect}"
343
+ Gift card refunds are allowed in the context of a previous transaction, but
344
+ free range gift card refunds are not allowed. Use the gift card activation
345
+ API if you need to add more funds to a gift card.
292
346
 
347
+ **Store and Forward Support**
293
348
 
294
- ```
349
+ Refunds are not permitted when a terminal falls back to store and forward mode.
350
+
351
+ **Auto Voids**
352
+
353
+ If a refund referencing a previous transaction is executed for the full amount
354
+ before the original transaction's batch is closed, the refund is automatically
355
+ converted to a void. This saves the merchant a little bit of money.
295
356
 
296
- #### Update Transaction Display
297
357
 
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
358
 
302
359
 
303
360
  ```ruby
@@ -313,39 +370,40 @@ blockchyp = BlockChyp::BlockChyp.new(
313
370
 
314
371
  # Set request parameters
315
372
  request = {
316
- "test": true,
317
373
  "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
- }
374
+ "transactionId": '<PREVIOUS TRANSACTION ID>',
375
+
376
+ # Optional amount for partial refunds.
377
+ "amount": '5.00'
337
378
  }
338
379
 
339
- response = blockchyp.updateTransactionDisplay(request)
380
+ response = blockchyp.refund(request)
340
381
 
341
382
  puts "Response: #{response.inspect}"
342
383
 
343
384
 
344
385
  ```
345
386
 
346
- #### New Transaction Display
387
+ #### Enroll
388
+
389
+
390
+ This API allows you to tokenize and enroll a payment method in the token
391
+ vault. You can also pass in customer information and associate the
392
+ payment method with a customer record.
393
+
394
+ A token is returned in the response that can be used in subsequent charge,
395
+ preauth, and refund transactions.
396
+
397
+ **Gift Cards and EBT**
398
+
399
+ Gift Cards and EBT cards cannot be tokenized.
400
+
401
+ **E-Commerce Tokens**
402
+
403
+ The tokens returned by the enroll API and the e-commerce web tokenizer
404
+ are the same tokens and can be used interchangeably.
405
+
347
406
 
348
- Displays a new transaction on the terminal.
349
407
 
350
408
 
351
409
  ```ruby
@@ -362,38 +420,27 @@ blockchyp = BlockChyp::BlockChyp.new(
362
420
  # Set request parameters
363
421
  request = {
364
422
  "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
- }
423
+ "terminalName": 'Test Terminal'
385
424
  }
386
425
 
387
- response = blockchyp.newTransactionDisplay(request)
426
+ response = blockchyp.enroll(request)
388
427
 
389
428
  puts "Response: #{response.inspect}"
390
429
 
391
430
 
392
431
  ```
393
432
 
394
- #### Text Prompt
433
+ #### Void
434
+
435
+
436
+
437
+ Mistakes happen. If a transaction is made by mistake, you can void it
438
+ with this API. All that's needed is to pass in a Transaction ID and execute
439
+ the void before the original transaction's batch closes.
440
+
441
+ Voids work with EBT and gift card transactions with no additional parameters.
442
+
395
443
 
396
- Asks the consumer a text based question.
397
444
 
398
445
 
399
446
  ```ruby
@@ -410,23 +457,38 @@ blockchyp = BlockChyp::BlockChyp.new(
410
457
  # Set request parameters
411
458
  request = {
412
459
  "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
460
+ "transactionId": '<PREVIOUS TRANSACTION ID>'
418
461
  }
419
462
 
420
- response = blockchyp.textPrompt(request)
463
+ response = blockchyp.void(request)
421
464
 
422
465
  puts "Response: #{response.inspect}"
423
466
 
424
467
 
425
468
  ```
426
469
 
427
- #### Boolean Prompt
470
+ #### Time Out Reversal
471
+
472
+
473
+
474
+ Payment transactions require a stable network to function correctly and
475
+ no network is stable all the time. Time out reversals are a great line
476
+ of defense against accidentally double charging consumers when payments
477
+ are retried during shaky network conditions.
478
+
479
+ We highly recommend developers use this API whenever a charge, preauth, or refund transaction times out. If you don't receive a definitive response
480
+ from BlockChyp, you can't be certain about whether or not the transaction went through.
481
+
482
+ A 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.
483
+
484
+ The only caveat is that developers must use the `transactionRef` property (`txRef` for the CLI) when executing charge, preauth, and refund transactions.
485
+
486
+ The reason for this requirement is that if a system never receives a definitive
487
+ response for a transaction, the system would never have received the BlockChyp
488
+ generated Transaction ID. We have to fallback to transaction ref to identify
489
+ a transaction.
490
+
428
491
 
429
- Asks the consumer a yes/no question.
430
492
 
431
493
 
432
494
  ```ruby
@@ -442,23 +504,70 @@ blockchyp = BlockChyp::BlockChyp.new(
442
504
 
443
505
  # Set request parameters
444
506
  request = {
445
- "test": true,
446
- "terminalName": 'Test Terminal',
447
- "prompt": 'Would you like to become a member?',
448
- "yesCaption": 'Yes',
449
- "noCaption": 'No'
507
+ "transactionRef": '<LAST TRANSACTION REF>'
450
508
  }
451
509
 
452
- response = blockchyp.booleanPrompt(request)
510
+ response = blockchyp.reverse(request)
453
511
 
454
512
  puts "Response: #{response.inspect}"
455
513
 
456
514
 
457
515
  ```
458
516
 
459
- #### Display Message
517
+ #### Gift Card Activation
518
+
519
+
520
+ This API can be used to activate or add value to BlockChyp gift cards.
521
+ Just pass in the terminal name and the amount to add to the card.
522
+ Once the customer swipes their card, the terminal will use keys
523
+ on the mag stripe to add value to the card.
524
+
525
+ You don't need to handle a new gift card or a gift card recharge any
526
+ differently. The terminal firmware will figure out what to do on its
527
+ own and also returns the new balance for the gift card.
528
+
529
+ This is the part of the system where BlockChyp's blockchain DNA comes
530
+ closest to the surface. The BlockChyp gift card system doesn't really
531
+ use gift card numbers. This means they can't be stolen.
532
+
533
+ BlockChyp identifies cards with an elliptic curve public key instead.
534
+ Gift card transactions are actually blocks signed with those keys.
535
+ This means there are no shared secrets sent over the network with
536
+ BlockChyp gift cards.
537
+ To keep track of a BlockChyp gift card, hang on to the **public key** returned
538
+ during gift card activation. That's the gift card's elliptic curve public key.
539
+
540
+ We sometimes print numbers on our gift cards, but these are actually
541
+ decimal encoded hashes of a portion of the public key to make our gift
542
+ cards seem *normal* to *normies*. They can be used
543
+ for balance checks and play a lookup role in online gift card
544
+ authorization, but are of little use beyond that.
545
+
546
+ **Voids and Reversals**
547
+
548
+ Gift card activations can be voided and reversed just like any other
549
+ BlockChyp transaction. Use the Transaction ID or Transaction Ref
550
+ to identify the gift activation transaction as you normally would for
551
+ voiding or reversing a conventional payment transaction.
552
+
553
+ **Importing Gift Cards**
554
+
555
+ BlockChyp does have the ability to import gift card liability from
556
+ conventional gift card platforms. Unfortunately, BlockChyp does not
557
+ support activating cards on third party systems, but you can import
558
+ your outstanding gift cards and customerSearch can swipe them on the
559
+ terminals just like BlockChyp's standard gift cards.
560
+
561
+ No special coding is required to access this feature. The gateway and
562
+ terminal firmware handle everything for you.
563
+
564
+ **Third Party Gift Card Networks**
565
+
566
+ BlockChyp does not currently provide any native support for other gift card
567
+ platforms beyond importing gift card liability. We do have a white listing system however that be used support your own custom gift card implementations. We have a security review
568
+ process before we allow a BIN range to be white listed, so contact support@blockchyp.com if you need to white list a BIN range.
569
+
460
570
 
461
- Displays a short message on the terminal.
462
571
 
463
572
 
464
573
  ```ruby
@@ -476,51 +585,47 @@ blockchyp = BlockChyp::BlockChyp.new(
476
585
  request = {
477
586
  "test": true,
478
587
  "terminalName": 'Test Terminal',
479
- "message": 'Thank you for your business.'
588
+ "amount": '50.00'
480
589
  }
481
590
 
482
- response = blockchyp.message(request)
591
+ response = blockchyp.giftActivate(request)
483
592
 
484
593
  puts "Response: #{response.inspect}"
485
594
 
486
595
 
487
596
  ```
488
597
 
489
- #### Refund
598
+ #### Balance
490
599
 
491
- Executes a refund.
492
600
 
493
601
 
494
- ```ruby
495
- # frozen_string_literal: true
602
+ Checks a gift or EBT card balance.
496
603
 
497
- require 'blockchyp'
604
+ **Gift Card Balance Checks**
498
605
 
499
- blockchyp = BlockChyp::BlockChyp.new(
500
- ENV['BC_API_KEY'],
501
- ENV['BC_BEARER_TOKEN'],
502
- ENV['BC_SIGNING_KEY']
503
- )
606
+ For gift cards, just pass in a terminal name and the customer will be prompted
607
+ to swipe a card on that terminal. The remaining balance will be displayed
608
+ briefly on the terminal screen and the API response will include the gift card's public key and the remaining balance.
504
609
 
505
- # Set request parameters
506
- request = {
507
- "terminalName": 'Test Terminal',
508
- "transactionId": '<PREVIOUS TRANSACTION ID>',
610
+ **EBT Balance Checks**
509
611
 
510
- # Optional amount for partial refunds.
511
- "amount": '5.00'
512
- }
612
+ All EBT transactions require a PIN, so in order to check an EBT card balance,
613
+ you need to pass in the `ebt` flag just like you would for a normal EBT
614
+ charge transaction. The customer will be prompted to swipe their card and
615
+ 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.
513
616
 
514
- response = blockchyp.refund(request)
617
+ **Testing Gift Card Balance Checks**
515
618
 
516
- puts "Response: #{response.inspect}"
619
+ Test gift card balance checks works no differently than live gift cards. You
620
+ must activate a test gift card first in order to test balance checks. Test
621
+ gift cards are real blockchain cards that live on our parallel test blockchain.
517
622
 
623
+ **Testing EBT Gift Card Balance Checks**
518
624
 
519
- ```
625
+ All test EBT transactions assume a starting balance of $100.00. As a result,
626
+ test EBT balance checks always return a balance of $100.00.
520
627
 
521
- #### Enroll
522
628
 
523
- Adds a new payment method to the token vault.
524
629
 
525
630
 
526
631
  ```ruby
@@ -537,19 +642,29 @@ blockchyp = BlockChyp::BlockChyp.new(
537
642
  # Set request parameters
538
643
  request = {
539
644
  "test": true,
540
- "terminalName": 'Test Terminal'
645
+ "terminalName": 'Test Terminal',
646
+ "cardType": CardType::EBT
541
647
  }
542
648
 
543
- response = blockchyp.enroll(request)
649
+ response = blockchyp.balance(request)
544
650
 
545
651
  puts "Response: #{response.inspect}"
546
652
 
547
653
 
548
654
  ```
549
655
 
550
- #### Gift Card Activation
656
+ #### Close Batch
657
+
658
+
659
+ This API will close the merchant's batch, if it's currently open.
660
+
661
+ By default, merchant batches will close automatically at 3 AM in their
662
+ local time zone. The automatic batch closure time can be changed
663
+ in the Merchant Profile or disabled completely.
664
+
665
+ If automatic batch closure is disabled, you'll need to use this API to
666
+ close the batch manually.
551
667
 
552
- Activates or recharges a gift card.
553
668
 
554
669
 
555
670
  ```ruby
@@ -565,37 +680,100 @@ blockchyp = BlockChyp::BlockChyp.new(
565
680
 
566
681
  # Set request parameters
567
682
  request = {
568
- "test": true,
569
- "terminalName": 'Test Terminal',
570
- "amount": '50.00'
683
+ "test": true
571
684
  }
572
685
 
573
- response = blockchyp.giftActivate(request)
686
+ response = blockchyp.closeBatch(request)
574
687
 
575
688
  puts "Response: #{response.inspect}"
576
689
 
577
690
 
578
691
  ```
579
692
 
580
- #### Time Out Reversal
693
+ #### Send Payment Link
581
694
 
582
- Executes a manual time out reversal.
583
695
 
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
696
 
697
+ This API allows you to send an invoice to a customer and capture payment
698
+ via a BlockChyp hosted payment page.
592
699
 
593
- ```ruby
594
- # frozen_string_literal: true
700
+ If you set the `autoSend` flag, BlockChyp will send a basic invoice email
701
+ to the customer for you that includes the payment link. If you'd rather have
702
+ more control over the look of the email message, you can omit the `autoSend`
703
+ flag and send the customer email yourself.
595
704
 
596
- require 'blockchyp'
705
+ There are a lot of optional parameters for this API, but at a minimum
706
+ you'll need to pass in a total, customer name, and email address.
597
707
 
598
- blockchyp = BlockChyp::BlockChyp.new(
708
+ **Customer Info**
709
+
710
+ You must specify a customer, either by creating a new customer record inline
711
+ or by passing in an existing Customer ID or Customer Ref.
712
+
713
+ **Line Item Level Data**
714
+
715
+ It's not strictly required, but we strongly recommend sending line item level
716
+ data with every request. It will make the invoice look a little more complete
717
+ and the data format for line item level data is the exact same format used
718
+ for terminal line item display, so the same code can be used to support both areas.
719
+
720
+ **Descriptions**
721
+
722
+ You can also send a free form description or message that's displayed near
723
+ the bottom of the invoice. Usually this is some kind of thank you note
724
+ or instructions.
725
+
726
+ **Terms and Conditions**
727
+
728
+ You can include long form contract language with a request and capture
729
+ terms and conditions acceptance at the same time payment is captured.
730
+
731
+ The interface is identical to that used for the terminal based terms and
732
+ conditions API in that you can pass in content directly via `tcContent` or via
733
+ a preconfigured template via `tcAlias`. The terms and conditions log will also be updated when
734
+ terms and conditions acceptance is incorporated into a send link request.
735
+
736
+ **Auto Send**
737
+
738
+ By default, BlockChyp does not send the email notification automatically. This is
739
+ really just a safeguard to prevent real emails from going out when you may not expect it.
740
+ If you want BlockChyp to send the email for you, just add the `autoSend` flag with
741
+ all requests.
742
+
743
+ **Payment Notifications**
744
+
745
+ When a customer successfully submits payment, the merchant will receive an email
746
+ notifying them that the payment was received.
747
+
748
+ **Real Time Callback Notifications**
749
+
750
+ Email notifications are fine, but you may also want your system to be informed
751
+ immediately whenever a payment event occurs. By using the optional `callbackUrl` request
752
+ property, you can specify a URL to which the Authorization Response will be posted
753
+ every time the user submits a payment, whether approved or otherwise.
754
+
755
+ The response will be sent as a JSON encoded POST request and will be the exact
756
+ same format as all BlockChyp charge and preauth transaction responses.
757
+
758
+ **Status Polling**
759
+
760
+ If real time callbacks aren't practical or necesary in your environment, you can
761
+ always use the Transaction Status API described below.
762
+
763
+ A common use case for the send link API with status polling is curbside pickup.
764
+ You could have your system check the Transaction Status when a customer arrives to
765
+ ensure it's been paid without necessarily needing to create background threads
766
+ to constantly poll for status updates.
767
+
768
+
769
+
770
+
771
+ ```ruby
772
+ # frozen_string_literal: true
773
+
774
+ require 'blockchyp'
775
+
776
+ blockchyp = BlockChyp::BlockChyp.new(
599
777
  ENV['BC_API_KEY'],
600
778
  ENV['BC_BEARER_TOKEN'],
601
779
  ENV['BC_SIGNING_KEY']
@@ -603,20 +781,51 @@ blockchyp = BlockChyp::BlockChyp.new(
603
781
 
604
782
  # Set request parameters
605
783
  request = {
606
- "terminalName": 'Test Terminal',
607
- "transactionRef": '<LAST TRANSACTION REF>'
784
+ "amount": '199.99',
785
+ "description": 'Widget',
786
+ "subject": 'Widget invoice',
787
+ "transaction": {
788
+ "subtotal": '195.00',
789
+ "tax": '4.99',
790
+ "total": '199.99',
791
+ "items": [
792
+ {
793
+ "description": 'Widget',
794
+ "price": '195.00',
795
+ "quantity": 1
796
+ }
797
+ ]
798
+ },
799
+ "autoSend": true,
800
+ "customer": {
801
+ "customerRef": 'Customer reference string',
802
+ "firstName": 'FirstName',
803
+ "lastName": 'LastName',
804
+ "companyName": 'Company Name',
805
+ "emailAddress": 'support@blockchyp.com',
806
+ "smsNumber": '(123) 123-1231'
807
+ }
608
808
  }
609
809
 
610
- response = blockchyp.reverse(request)
810
+ response = blockchyp.sendPaymentLink(request)
611
811
 
612
812
  puts "Response: #{response.inspect}"
613
813
 
614
814
 
615
815
  ```
616
816
 
617
- #### Capture Preauthorization
817
+ #### Transaction Status
818
+
819
+
820
+
821
+ Returns the current status for any transaction. You can lookup a transaction
822
+ by its BlockChyp assigned Transaction ID or your own Transaction Ref.
823
+
824
+ You should alway use globally unique Transaction Ref values, but in the event
825
+ that you duplicate Transaction Refs, the most recent transaction matching your
826
+ Transaction Ref is returned.
827
+
618
828
 
619
- Captures a preauthorization.
620
829
 
621
830
 
622
831
  ```ruby
@@ -632,20 +841,25 @@ blockchyp = BlockChyp::BlockChyp.new(
632
841
 
633
842
  # Set request parameters
634
843
  request = {
635
- "test": true,
636
- "transactionId": '<PREAUTH TRANSACTION ID>'
844
+ "transactionId": 'ID of transaction to retrieve'
637
845
  }
638
846
 
639
- response = blockchyp.capture(request)
847
+ response = blockchyp.transactionStatus(request)
640
848
 
641
849
  puts "Response: #{response.inspect}"
642
850
 
643
851
 
644
852
  ```
645
853
 
646
- #### Close Batch
854
+ #### Terminal Clear
855
+
856
+
857
+
858
+ This API interrupts whatever a terminal may be doing and returns it to the
859
+ idle state.
860
+
861
+
647
862
 
648
- Closes the current credit card batch.
649
863
 
650
864
 
651
865
  ```ruby
@@ -661,19 +875,33 @@ blockchyp = BlockChyp::BlockChyp.new(
661
875
 
662
876
  # Set request parameters
663
877
  request = {
664
- "test": true
878
+ "test": true,
879
+ "terminalName": 'Test Terminal'
665
880
  }
666
881
 
667
- response = blockchyp.closeBatch(request)
882
+ response = blockchyp.clear(request)
668
883
 
669
884
  puts "Response: #{response.inspect}"
670
885
 
671
886
 
672
887
  ```
673
888
 
674
- #### Void Transaction
889
+ #### Terminal Status
890
+
891
+
892
+
893
+ Returns the current status of a payment terminal. This is typically used
894
+ as a way to determine if the terminal is busy before sending a new transaction.
895
+
896
+ If the terminal is busy, `idle` will be false and the `status` field will return
897
+ a short string indicating the transaction type currently in progress. The system
898
+ will also return the timestamp of the last status change in the `since` field.
899
+
900
+ If the system is running a payment transaction and you wisely passed in a
901
+ Transaction Ref, this API will also return the Transaction Ref of the in progress
902
+ transaction in the response.
903
+
675
904
 
676
- Discards a previous preauth transaction.
677
905
 
678
906
 
679
907
  ```ruby
@@ -689,20 +917,59 @@ blockchyp = BlockChyp::BlockChyp.new(
689
917
 
690
918
  # Set request parameters
691
919
  request = {
692
- "test": true,
693
- "transactionId": '<PREVIOUS TRANSACTION ID>'
920
+ "terminalName": 'Test Terminal'
694
921
  }
695
922
 
696
- response = blockchyp.void(request)
923
+ response = blockchyp.terminalStatus(request)
697
924
 
698
925
  puts "Response: #{response.inspect}"
699
926
 
700
927
 
701
928
  ```
702
929
 
703
- #### Terminal Status
930
+ #### Terms & Conditions Capture
931
+
932
+
933
+
934
+ This API allows you to prompt a customer to accept a legal agreement on the terminal
935
+ and optionally capture their signature.
936
+
937
+ Content for the agreement can be specified in two ways. You can reference a
938
+ previously configured T&C template or pass in the full agreement text with every request.
939
+
940
+ **Using Templates**
941
+
942
+ If your application doesn't keep track of agreements you can leverage BlockChyp's
943
+ template system. You can create any number of T&C Templates in the merchant dashboard
944
+ and pass in the `tcAlias` flag to specify which one to display.
945
+
946
+ **Raw Content**
947
+
948
+ If your system keeps track of the agreement language or executes complicated merging
949
+ and rendering logic, you can bypass our template system and pass in the full text with
950
+ every transaction. Use the `tcName` to pass in the agreement name and `tcContent` to
951
+ pass in the contract text. Note that only plain text is supported.
952
+
953
+ **Bypassing Signatures**
954
+
955
+ Signature images are captured by default. If for some reason this doesn't fit your
956
+ use case and you'd like to capture acceptance without actually capturing a signature image set
957
+ the `disableSignature` flag in the request.
958
+
959
+ **Terms & Conditions Log**
960
+
961
+ Every time a user accepts an agreement on the terminal the signature image (if captured),
962
+ will be uploaded to the gateway and added to the log along with the full text of the
963
+ agreement. This preserves the historical record in the event that standard agreements
964
+ or templates change over time.
965
+
966
+ **Associating Agreements with Transactions**
967
+
968
+ To associate a Terms & Conditions log entry with a transaction, just pass in the
969
+ Transaction ID or Transaction Ref for the associated transaction.
970
+
971
+
704
972
 
705
- Returns the current status of a terminal.
706
973
 
707
974
 
708
975
  ```ruby
@@ -718,19 +985,60 @@ blockchyp = BlockChyp::BlockChyp.new(
718
985
 
719
986
  # Set request parameters
720
987
  request = {
721
- "terminalName": 'Test Terminal'
988
+ "test": true,
989
+ "terminalName": 'Test Terminal',
990
+
991
+ # Alias for a Terms and Conditions template configured in the BlockChyp
992
+ # dashboard.
993
+ "tcAlias": 'hippa',
994
+
995
+ # Name of the contract or document if not using an alias.
996
+ "tcName": 'HIPPA Disclosure',
997
+
998
+ # Full text of the contract or disclosure if not using an alias.
999
+ "tcContent": 'Full contract text',
1000
+
1001
+ # File format for the signature image.
1002
+ "sigFormat": SignatureFormat::PNG,
1003
+
1004
+ # Width of the signature image in pixels.
1005
+ "sigWidth": 200,
1006
+
1007
+ # Whether or not a signature is required. Defaults to true.
1008
+ "sigRequired": true
722
1009
  }
723
1010
 
724
- response = blockchyp.terminalStatus(request)
1011
+ response = blockchyp.termsAndConditions(request)
725
1012
 
726
1013
  puts "Response: #{response.inspect}"
727
1014
 
728
1015
 
729
1016
  ```
730
1017
 
731
- #### Capture Signature.
1018
+ #### Capture Signature
1019
+
1020
+
1021
+
1022
+ This endpoint captures a written signature from the terminal and returns the
1023
+ image.
1024
+
1025
+ Unlike the Terms & Conditions API, this endpoint performs basic signature
1026
+ capture with no agreement display or signature archival.
1027
+
1028
+ Under the hood, signatures are captured in a proprietary vector format and
1029
+ must be converted to a common raster format in order to be useful to most
1030
+ applications. At a minimum, you must specify an image format using the
1031
+ `sigFormat` parameter. As of this writing JPG and PNG are supported.
1032
+
1033
+ By default, images are returned in the JSON response as hex encoded binary.
1034
+ You can redirect the binary image output to a file using the `sigFile`
1035
+ parameter.
1036
+
1037
+ You can also scale the output image to your preferred width by
1038
+ passing in a `sigWidth` parameter. The image will be scaled to that
1039
+ width, preserving the aspect ratio of the original image.
1040
+
732
1041
 
733
- Captures and returns a signature.
734
1042
 
735
1043
 
736
1044
  ```ruby
@@ -762,9 +1070,31 @@ puts "Response: #{response.inspect}"
762
1070
 
763
1071
  ```
764
1072
 
765
- #### Update Customer
1073
+ #### New Transaction Display
1074
+
1075
+
1076
+
1077
+ Sends totals and line item level data to the terminal.
1078
+
1079
+ At a minimum, you should send total information as part of a display request,
1080
+ including `total`, `tax`, and `subtotal`.
1081
+
1082
+ You can also send line item level data and each line item can have a `description`,
1083
+ `qty`, `price`, and `extended` price.
1084
+
1085
+ If you fail to send an extended price, BlockChyp will multiply the `qty` by the
1086
+ `price`, but we strongly recommend you precalculate all the fields yourself
1087
+ to ensure consistency. Your treatment of floating-point multiplication and rounding
1088
+ may differ slightly from BlockChyp's, for example.
1089
+
1090
+ **Discounts**
1091
+
1092
+ You have the option to show discounts on the display as individual line items
1093
+ with negative values or you can associate discounts with a specific line item.
1094
+ You can apply any number of discounts to an individual line item with a description
1095
+ and amount.
1096
+
766
1097
 
767
- Updates or creates a customer record.
768
1098
 
769
1099
 
770
1100
  ```ruby
@@ -780,27 +1110,69 @@ blockchyp = BlockChyp::BlockChyp.new(
780
1110
 
781
1111
  # Set request parameters
782
1112
  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'
1113
+ "test": true,
1114
+ "terminalName": 'Test Terminal',
1115
+ "transaction": {
1116
+ "subtotal": '60.00',
1117
+ "tax": '5.00',
1118
+ "total": '65.00',
1119
+ "items": [
1120
+ {
1121
+ "description": 'Leki Trekking Poles',
1122
+ "price": '35.00',
1123
+ "quantity": 2,
1124
+ "extended": '70.00',
1125
+ "discounts": [
1126
+ {
1127
+ "description": 'memberDiscount',
1128
+ "amount": '10.00'
1129
+ }
1130
+ ]
1131
+ }
1132
+ ]
791
1133
  }
792
1134
  }
793
1135
 
794
- response = blockchyp.updateCustomer(request)
1136
+ response = blockchyp.newTransactionDisplay(request)
795
1137
 
796
1138
  puts "Response: #{response.inspect}"
797
1139
 
798
1140
 
799
1141
  ```
800
1142
 
801
- #### Retrieve Customer
1143
+ #### Update Transaction Display
1144
+
1145
+
1146
+
1147
+ Similar to *New Transaction Display*, this variant allows developers to update
1148
+ line item level data currently being displayed on the terminal.
1149
+
1150
+ This is designed for situations where you want to update the terminal display as
1151
+ items are scanned. This variant means you only have to send information to the
1152
+ terminal that's changed, which usually means the new line item and updated totals.
1153
+
1154
+ If the terminal is not in line item display mode and you invoke this endpoint,
1155
+ the first invocation will behave like a *New Transaction Display* call.
1156
+
1157
+ At a minimum, you should send total information as part of a display request,
1158
+ including `total`, `tax`, and `subtotal`.
1159
+
1160
+ You can also send line item level data and each line item can have a `description`,
1161
+ `qty`, `price`, and `extended` price.
1162
+
1163
+ If you fail to send an extended price, BlockChyp will multiply the `qty` by the
1164
+ `price`, but we strongly recommend you precalculate all the fields yourself
1165
+ to ensure consistency. Your treatment of floating-point multiplication and rounding
1166
+ may differ slightly from BlockChyp's, for example.
1167
+
1168
+ **Discounts**
1169
+
1170
+ You have the option to show discounts on the display as individual line items
1171
+ with negative values or you can associate discounts with a specific line item.
1172
+ You can apply any number of discounts to an individual line item with a description
1173
+ and amount.
1174
+
802
1175
 
803
- Retrieves a customer by id.
804
1176
 
805
1177
 
806
1178
  ```ruby
@@ -816,19 +1188,45 @@ blockchyp = BlockChyp::BlockChyp.new(
816
1188
 
817
1189
  # Set request parameters
818
1190
  request = {
819
- "customerId": 'ID of the customer to retrieve'
1191
+ "test": true,
1192
+ "terminalName": 'Test Terminal',
1193
+ "transaction": {
1194
+ "subtotal": '60.00',
1195
+ "tax": '5.00',
1196
+ "total": '65.00',
1197
+ "items": [
1198
+ {
1199
+ "description": 'Leki Trekking Poles',
1200
+ "price": '35.00',
1201
+ "quantity": 2,
1202
+ "extended": '70.00',
1203
+ "discounts": [
1204
+ {
1205
+ "description": 'memberDiscount',
1206
+ "amount": '10.00'
1207
+ }
1208
+ ]
1209
+ }
1210
+ ]
1211
+ }
820
1212
  }
821
1213
 
822
- response = blockchyp.customer(request)
1214
+ response = blockchyp.updateTransactionDisplay(request)
823
1215
 
824
1216
  puts "Response: #{response.inspect}"
825
1217
 
826
1218
 
827
1219
  ```
828
1220
 
829
- #### Search Customer
1221
+ #### Display Message
1222
+
1223
+
1224
+
1225
+ Displays a message on the payment terminal.
1226
+
1227
+ Just specify the target terminal and the message using the `message` parameter.
1228
+
830
1229
 
831
- Searches the customer database.
832
1230
 
833
1231
 
834
1232
  ```ruby
@@ -844,19 +1242,36 @@ blockchyp = BlockChyp::BlockChyp.new(
844
1242
 
845
1243
  # Set request parameters
846
1244
  request = {
847
- "query": '(123) 123-1234'
1245
+ "test": true,
1246
+ "terminalName": 'Test Terminal',
1247
+ "message": 'Thank you for your business.'
848
1248
  }
849
1249
 
850
- response = blockchyp.customerSearch(request)
1250
+ response = blockchyp.message(request)
851
1251
 
852
1252
  puts "Response: #{response.inspect}"
853
1253
 
854
1254
 
855
1255
  ```
856
1256
 
857
- #### Cash Discount
1257
+ #### Boolean Prompt
1258
+
1259
+
1260
+
1261
+ Prompts the customer to answer a yes or no question.
1262
+
1263
+ You can specify the question or prompt with the `prompt` parameter and
1264
+ the response is returned in the `response` field.
1265
+
1266
+ This can be used for a number of use cases including starting a loyalty enrollment
1267
+ workflow or customer facing suggestive selling prompts.
1268
+
1269
+ **Custom Captions**
1270
+
1271
+ You can optionally override the "YES" and "NO" button captions by
1272
+ using the `yesCaption` and `noCaption` request parameters.
1273
+
858
1274
 
859
- Calculates the discount for actual cash transactions.
860
1275
 
861
1276
 
862
1277
  ```ruby
@@ -872,19 +1287,47 @@ blockchyp = BlockChyp::BlockChyp.new(
872
1287
 
873
1288
  # Set request parameters
874
1289
  request = {
875
- "amount": '100.00'
1290
+ "test": true,
1291
+ "terminalName": 'Test Terminal',
1292
+ "prompt": 'Would you like to become a member?',
1293
+ "yesCaption": 'Yes',
1294
+ "noCaption": 'No'
876
1295
  }
877
1296
 
878
- response = blockchyp.cashDiscount(request)
1297
+ response = blockchyp.booleanPrompt(request)
879
1298
 
880
1299
  puts "Response: #{response.inspect}"
881
1300
 
882
1301
 
883
1302
  ```
884
1303
 
885
- #### Transaction Status
1304
+ #### Text Prompt
1305
+
1306
+
1307
+
1308
+ Prompts the customer to enter numeric or alphanumeric data.
1309
+
1310
+ Due to PCI rules, free form prompts are not permitted when the response
1311
+ could be any valid string. The reason for this is that a malicious
1312
+ developer (not you, of course) could use text prompts to ask the customer to
1313
+ input a card number or PIN code.
1314
+
1315
+ This means that instead of providing a prompt, you provide a `promptType` instead.
1316
+
1317
+ The prompt types currently supported are listed below:
1318
+
1319
+ * **phone**: Captures a phone number.
1320
+ * **email**: Captures an email address.
1321
+ * **first-name**: Captures a first name.
1322
+ * **last-name**: Captures a last name.
1323
+ * **customer-number**: Captures a customer number.
1324
+ * **rewards-number**: Captures a rewards number.
1325
+
1326
+ You can specify the prompt with the `promptType` parameter and
1327
+ the response is returned in the `response` field.
1328
+
1329
+
886
1330
 
887
- Retrieves the current status of a transaction.
888
1331
 
889
1332
 
890
1333
  ```ruby
@@ -900,19 +1343,50 @@ blockchyp = BlockChyp::BlockChyp.new(
900
1343
 
901
1344
  # Set request parameters
902
1345
  request = {
903
- "transactionId": 'ID of transaction to retrieve'
1346
+ "test": true,
1347
+ "terminalName": 'Test Terminal',
1348
+
1349
+ # Type of prompt. Can be 'email', 'phone', 'customer-number', or
1350
+ # 'rewards-number'.
1351
+ "promptType": PromptType::EMAIL
904
1352
  }
905
1353
 
906
- response = blockchyp.transactionStatus(request)
1354
+ response = blockchyp.textPrompt(request)
907
1355
 
908
1356
  puts "Response: #{response.inspect}"
909
1357
 
910
1358
 
911
1359
  ```
912
1360
 
913
- #### Send Payment Link
1361
+ #### Update Customer
1362
+
1363
+
1364
+
1365
+ Adds or updates a customer record.
1366
+
1367
+ If you pass in customer information including `firstName`, `lastName`, `email`,
1368
+ `email`, or `sms` without any Customer ID or Customer Ref, a new record will
1369
+ be created.
1370
+
1371
+ If you pass in `customerRef` and `customerId`, the customer record will be updated
1372
+ if it exists.
1373
+
1374
+ **Customer Ref**
1375
+
1376
+ The `customerRef` field is optional, but highly recommended as this allows you
1377
+ to use your own customer identifiers instead of storing BlockChyp's Customer IDs
1378
+ in your systems.
1379
+
1380
+ **Creating Customer Records With Payment Transactions**
1381
+
1382
+ If you have customer information available at the time a payment transaction is
1383
+ executed, you can pass all the same customer information directly into a payment transaction and
1384
+ create a customer record at the same time payment is captured. The advantage of this approach is
1385
+ that the customer's payment card is automatically associated with the customer record in a single step.
1386
+ If the customer uses the payment card in the future, the customer data will automatically
1387
+ be returned without needing to ask the customer to provide any additional information.
1388
+
914
1389
 
915
- Creates and send a payment link to a customer.
916
1390
 
917
1391
 
918
1392
  ```ruby
@@ -928,23 +1402,8 @@ blockchyp = BlockChyp::BlockChyp.new(
928
1402
 
929
1403
  # Set request parameters
930
1404
  request = {
931
- "amount": '199.99',
932
- "description": 'Widget',
933
- "subject": 'Widget invoice',
934
- "transaction": {
935
- "subtotal": '195.00',
936
- "tax": '4.99',
937
- "total": '199.99',
938
- "items": [
939
- {
940
- "description": 'Widget',
941
- "price": '195.00',
942
- "quantity": 1
943
- }
944
- ]
945
- },
946
- "autoSend": true,
947
1405
  "customer": {
1406
+ "id": 'ID of the customer to update',
948
1407
  "customerRef": 'Customer reference string',
949
1408
  "firstName": 'FirstName',
950
1409
  "lastName": 'LastName',
@@ -954,7 +1413,115 @@ request = {
954
1413
  }
955
1414
  }
956
1415
 
957
- response = blockchyp.sendPaymentLink(request)
1416
+ response = blockchyp.updateCustomer(request)
1417
+
1418
+ puts "Response: #{response.inspect}"
1419
+
1420
+
1421
+ ```
1422
+
1423
+ #### Retrieve Customer
1424
+
1425
+
1426
+
1427
+ Retrieves detailed information about a customer record, including saved payment
1428
+ methods if available.
1429
+
1430
+ Customers can be looked up by `customerId` or `customerRef`.
1431
+
1432
+
1433
+
1434
+
1435
+ ```ruby
1436
+ # frozen_string_literal: true
1437
+
1438
+ require 'blockchyp'
1439
+
1440
+ blockchyp = BlockChyp::BlockChyp.new(
1441
+ ENV['BC_API_KEY'],
1442
+ ENV['BC_BEARER_TOKEN'],
1443
+ ENV['BC_SIGNING_KEY']
1444
+ )
1445
+
1446
+ # Set request parameters
1447
+ request = {
1448
+ "customerId": 'ID of the customer to retrieve'
1449
+ }
1450
+
1451
+ response = blockchyp.customer(request)
1452
+
1453
+ puts "Response: #{response.inspect}"
1454
+
1455
+
1456
+ ```
1457
+
1458
+ #### Search Customer
1459
+
1460
+
1461
+
1462
+ Searches the customer database and returns matching results.
1463
+
1464
+ Use `query` to pass in a search string and the system will return all results whose
1465
+ first or last names contain the query string.
1466
+
1467
+
1468
+
1469
+
1470
+ ```ruby
1471
+ # frozen_string_literal: true
1472
+
1473
+ require 'blockchyp'
1474
+
1475
+ blockchyp = BlockChyp::BlockChyp.new(
1476
+ ENV['BC_API_KEY'],
1477
+ ENV['BC_BEARER_TOKEN'],
1478
+ ENV['BC_SIGNING_KEY']
1479
+ )
1480
+
1481
+ # Set request parameters
1482
+ request = {
1483
+ "query": '(123) 123-1234'
1484
+ }
1485
+
1486
+ response = blockchyp.customerSearch(request)
1487
+
1488
+ puts "Response: #{response.inspect}"
1489
+
1490
+
1491
+ ```
1492
+
1493
+ #### Cash Discount
1494
+
1495
+
1496
+
1497
+ Calculates the surcharge, cash discount, and total amounts for cash transactions.
1498
+
1499
+ If you're using BlockChyp's cash discounting features, you can use this endpoint
1500
+ to make sure the numbers and receipts for true cash transactions are consistent
1501
+ with transactions processed by BlockChyp.
1502
+
1503
+
1504
+
1505
+
1506
+ ```ruby
1507
+ # frozen_string_literal: true
1508
+
1509
+ require 'blockchyp'
1510
+
1511
+ blockchyp = BlockChyp::BlockChyp.new(
1512
+ ENV['BC_API_KEY'],
1513
+ ENV['BC_BEARER_TOKEN'],
1514
+ ENV['BC_SIGNING_KEY']
1515
+ )
1516
+
1517
+ # Set request parameters
1518
+ request = {
1519
+ "amount": '100.00',
1520
+ "cashDiscount": true,
1521
+ "surcharge": true
1522
+ }
1523
+
1524
+ response = blockchyp.cashDiscount(request)
958
1525
 
959
1526
  puts "Response: #{response.inspect}"
960
1527