blockchyp 2.3.3 → 2.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +359 -151
- data/lib/blockchyp.rb +21 -1
- data/lib/blockchyp/version.rb +1 -1
- data/lib/blockchyp_client.rb +50 -60
- data/test/batch_history_test.rb +48 -0
- data/test/boolean_prompt_test.rb +12 -12
- data/test/capture_signature_test.rb +9 -9
- data/test/gateway_timeout_test.rb +10 -10
- data/test/get_customer_test.rb +13 -13
- data/test/heartbeat_test.rb +10 -10
- data/test/merchant_profile_test.rb +38 -0
- data/test/new_transaction_display_test.rb +20 -20
- data/test/pan_charge_test.rb +22 -22
- data/test/pan_enroll_test.rb +20 -20
- data/test/pan_preauth_test.rb +21 -21
- data/test/search_customer_test.rb +13 -13
- data/test/send_payment_link_test.rb +26 -26
- data/test/simple_batch_close_test.rb +11 -13
- data/test/simple_capture_test.rb +12 -12
- data/test/simple_gift_activate_test.rb +11 -11
- data/test/simple_message_test.rb +9 -9
- data/test/simple_ping_test.rb +8 -8
- data/test/simple_refund_test.rb +13 -13
- data/test/simple_reversal_test.rb +13 -13
- data/test/simple_void_test.rb +13 -13
- data/test/terminal_charge_test.rb +20 -20
- data/test/terminal_clear_test.rb +8 -8
- data/test/terminal_ebt_balance_test.rb +10 -10
- data/test/terminal_ebt_charge_test.rb +22 -22
- data/test/terminal_enroll_test.rb +19 -19
- data/test/terminal_gift_card_balance_test.rb +9 -9
- data/test/terminal_keyed_charge_test.rb +21 -21
- data/test/terminal_manual_ebt_charge_test.rb +23 -23
- data/test/terminal_preauth_test.rb +20 -20
- data/test/terminal_status_test.rb +8 -8
- data/test/terminal_timeout_test.rb +9 -9
- data/test/terms_and_conditions_test.rb +13 -13
- data/test/test_helper.rb +7 -6
- data/test/text_prompt_test.rb +10 -10
- data/test/transaction_history_test.rb +48 -0
- data/test/update_customer_test.rb +12 -12
- data/test/update_transaction_display_test.rb +20 -20
- metadata +5 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 49dc32372aabccb3d15971f69deb80b427934ddc9c810fa5e9132c6856b12b90
|
|
4
|
+
data.tar.gz: 21ad4be26072a746a7db7494ae60c624f0aab00f17dd6c49e60a3a442578251e
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: b9871571c1d25f338af7a5419ef5c369ab41428d373fa7fabed9d5e94aafea9e5cefa06350bcc65c20d13bcbedd8ef0fe25682c8f1a58e58b70ec6763ff938a8
|
|
7
|
+
data.tar.gz: b899f32df715af449cd2a00e8d1c3f0e2d88118259a7d27ccd3708f792da3f04e23dcefd8da27f9a85c6b142e84a2c92a75cdb0e4bd5547cb42374a298499d56
|
data/README.md
CHANGED
|
@@ -86,7 +86,7 @@ If you get a positive response, you've successfully verified all of the followin
|
|
|
86
86
|
|
|
87
87
|
* The terminal is online.
|
|
88
88
|
* There is a valid route to the terminal.
|
|
89
|
-
* The API
|
|
89
|
+
* The API Credentials are valid.
|
|
90
90
|
|
|
91
91
|
|
|
92
92
|
|
|
@@ -104,7 +104,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
104
104
|
|
|
105
105
|
# Set request parameters
|
|
106
106
|
request = {
|
|
107
|
-
|
|
107
|
+
terminalName: 'Test Terminal'
|
|
108
108
|
}
|
|
109
109
|
|
|
110
110
|
response = blockchyp.ping(request)
|
|
@@ -147,7 +147,7 @@ might be maliciously running on the point-of-sale system.
|
|
|
147
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
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
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
|
|
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
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
152
|
|
|
153
153
|
|
|
@@ -166,9 +166,9 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
166
166
|
|
|
167
167
|
# Set request parameters
|
|
168
168
|
request = {
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
169
|
+
test: true,
|
|
170
|
+
terminalName: 'Test Terminal',
|
|
171
|
+
amount: '55.00'
|
|
172
172
|
}
|
|
173
173
|
|
|
174
174
|
response = blockchyp.charge(request)
|
|
@@ -182,8 +182,8 @@ puts "Response: #{response.inspect}"
|
|
|
182
182
|
|
|
183
183
|
|
|
184
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.
|
|
186
|
-
be fine dining where a tip adjustment is required prior to
|
|
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.
|
|
187
187
|
|
|
188
188
|
Another use case for preauthorization is e-commerce. Typically, an online order
|
|
189
189
|
is preauthorized at the time of the order and then captured when the order ships.
|
|
@@ -230,9 +230,9 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
230
230
|
|
|
231
231
|
# Set request parameters
|
|
232
232
|
request = {
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
233
|
+
test: true,
|
|
234
|
+
terminalName: 'Test Terminal',
|
|
235
|
+
amount: '27.00'
|
|
236
236
|
}
|
|
237
237
|
|
|
238
238
|
response = blockchyp.preauth(request)
|
|
@@ -270,8 +270,8 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
270
270
|
|
|
271
271
|
# Set request parameters
|
|
272
272
|
request = {
|
|
273
|
-
|
|
274
|
-
|
|
273
|
+
test: true,
|
|
274
|
+
transactionId: '<PREAUTH TRANSACTION ID>'
|
|
275
275
|
}
|
|
276
276
|
|
|
277
277
|
response = blockchyp.capture(request)
|
|
@@ -293,14 +293,14 @@ returned in a BlockChyp response. To refund the full amount of the previous tra
|
|
|
293
293
|
|
|
294
294
|
**Partial Refunds**
|
|
295
295
|
|
|
296
|
-
For a partial refund, just
|
|
296
|
+
For a partial refund, just pass in an amount along with the Transaction ID.
|
|
297
297
|
The only rule is that the amount has to be equal to or less than the original
|
|
298
|
-
transaction. You can
|
|
299
|
-
original transaction as long as the total refunded amount doesn't exceed 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
300
|
|
|
301
301
|
**Tokenized Refunds**
|
|
302
302
|
|
|
303
|
-
You can also use a token to execute a refund.
|
|
303
|
+
You can also use a token to execute a refund. Pass in a token instead
|
|
304
304
|
of the Transaction ID along with the desired refund amount.
|
|
305
305
|
|
|
306
306
|
**Free Range Refunds**
|
|
@@ -308,10 +308,10 @@ of the Transaction ID along with the desired refund amount.
|
|
|
308
308
|
When you execute a refund without referencing a previous transaction, we
|
|
309
309
|
call this a *free range refund*.
|
|
310
310
|
|
|
311
|
-
We don't recommend it, but it is permitted.
|
|
312
|
-
Terminal Name and an amount.
|
|
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
313
|
|
|
314
|
-
You can
|
|
314
|
+
You can execute a manual or keyed refund by passing the `manual` flag
|
|
315
315
|
to a free range refund request.
|
|
316
316
|
|
|
317
317
|
**Gift Card Refunds**
|
|
@@ -346,11 +346,10 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
346
346
|
|
|
347
347
|
# Set request parameters
|
|
348
348
|
request = {
|
|
349
|
-
|
|
350
|
-
"transactionId": '<PREVIOUS TRANSACTION ID>',
|
|
349
|
+
transactionId: '<PREVIOUS TRANSACTION ID>',
|
|
351
350
|
|
|
352
351
|
# Optional amount for partial refunds.
|
|
353
|
-
|
|
352
|
+
amount: '5.00'
|
|
354
353
|
}
|
|
355
354
|
|
|
356
355
|
response = blockchyp.refund(request)
|
|
@@ -395,8 +394,8 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
395
394
|
|
|
396
395
|
# Set request parameters
|
|
397
396
|
request = {
|
|
398
|
-
|
|
399
|
-
|
|
397
|
+
test: true,
|
|
398
|
+
terminalName: 'Test Terminal'
|
|
400
399
|
}
|
|
401
400
|
|
|
402
401
|
response = blockchyp.enroll(request)
|
|
@@ -432,8 +431,8 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
432
431
|
|
|
433
432
|
# Set request parameters
|
|
434
433
|
request = {
|
|
435
|
-
|
|
436
|
-
|
|
434
|
+
test: true,
|
|
435
|
+
transactionId: '<PREVIOUS TRANSACTION ID>'
|
|
437
436
|
}
|
|
438
437
|
|
|
439
438
|
response = blockchyp.void(request)
|
|
@@ -455,13 +454,13 @@ are retried during shaky network conditions.
|
|
|
455
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
|
|
456
455
|
from BlockChyp, you can't be certain about whether or not the transaction went through.
|
|
457
456
|
|
|
458
|
-
|
|
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.
|
|
459
458
|
|
|
460
459
|
The only caveat is that developers must use the `transactionRef` property (`txRef` for the CLI) when executing charge, preauth, and refund transactions.
|
|
461
460
|
|
|
462
461
|
The reason for this requirement is that if a system never receives a definitive
|
|
463
462
|
response for a transaction, the system would never have received the BlockChyp
|
|
464
|
-
generated Transaction ID. We have to fallback to
|
|
463
|
+
generated Transaction ID. We have to fallback to Transaction Ref to identify
|
|
465
464
|
a transaction.
|
|
466
465
|
|
|
467
466
|
|
|
@@ -480,7 +479,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
480
479
|
|
|
481
480
|
# Set request parameters
|
|
482
481
|
request = {
|
|
483
|
-
|
|
482
|
+
transactionRef: '<LAST TRANSACTION REF>'
|
|
484
483
|
}
|
|
485
484
|
|
|
486
485
|
response = blockchyp.reverse(request)
|
|
@@ -498,7 +497,7 @@ Just pass in the terminal name and the amount to add to the card.
|
|
|
498
497
|
Once the customer swipes their card, the terminal will use keys
|
|
499
498
|
on the mag stripe to add value to the card.
|
|
500
499
|
|
|
501
|
-
You don't need to handle a new gift card or a gift card recharge any
|
|
500
|
+
You don't need to handle a new gift card activation or a gift card recharge any
|
|
502
501
|
differently. The terminal firmware will figure out what to do on its
|
|
503
502
|
own and also returns the new balance for the gift card.
|
|
504
503
|
|
|
@@ -508,8 +507,7 @@ use gift card numbers. This means they can't be stolen.
|
|
|
508
507
|
|
|
509
508
|
BlockChyp identifies cards with an elliptic curve public key instead.
|
|
510
509
|
Gift card transactions are actually blocks signed with those keys.
|
|
511
|
-
This means there are no shared secrets sent over the network
|
|
512
|
-
BlockChyp gift cards.
|
|
510
|
+
This means there are no shared secrets sent over the network.
|
|
513
511
|
To keep track of a BlockChyp gift card, hang on to the **public key** returned
|
|
514
512
|
during gift card activation. That's the gift card's elliptic curve public key.
|
|
515
513
|
|
|
@@ -531,7 +529,7 @@ voiding or reversing a conventional payment transaction.
|
|
|
531
529
|
BlockChyp does have the ability to import gift card liability from
|
|
532
530
|
conventional gift card platforms. Unfortunately, BlockChyp does not
|
|
533
531
|
support activating cards on third party systems, but you can import
|
|
534
|
-
your outstanding gift cards and
|
|
532
|
+
your outstanding gift cards and customers can swipe them on the
|
|
535
533
|
terminals just like BlockChyp's standard gift cards.
|
|
536
534
|
|
|
537
535
|
No special coding is required to access this feature. The gateway and
|
|
@@ -540,8 +538,10 @@ terminal firmware handle everything for you.
|
|
|
540
538
|
**Third Party Gift Card Networks**
|
|
541
539
|
|
|
542
540
|
BlockChyp does not currently provide any native support for other gift card
|
|
543
|
-
platforms beyond importing gift card liability. We do have a white listing system
|
|
544
|
-
|
|
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
545
|
|
|
546
546
|
|
|
547
547
|
|
|
@@ -559,9 +559,9 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
559
559
|
|
|
560
560
|
# Set request parameters
|
|
561
561
|
request = {
|
|
562
|
-
|
|
563
|
-
|
|
564
|
-
|
|
562
|
+
test: true,
|
|
563
|
+
terminalName: 'Test Terminal',
|
|
564
|
+
amount: '50.00'
|
|
565
565
|
}
|
|
566
566
|
|
|
567
567
|
response = blockchyp.giftActivate(request)
|
|
@@ -588,11 +588,11 @@ briefly on the terminal screen and the API response will include the gift card's
|
|
|
588
588
|
All EBT transactions require a PIN, so in order to check an EBT card balance,
|
|
589
589
|
you need to pass in the `ebt` flag just like you would for a normal EBT
|
|
590
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.
|
|
591
|
+
enter a PIN code. If everything checks out, the remaining balance on the card will be displayed on the terminal for the customer and returned in the API.
|
|
592
592
|
|
|
593
593
|
**Testing Gift Card Balance Checks**
|
|
594
594
|
|
|
595
|
-
Test gift card balance checks
|
|
595
|
+
Test gift card balance checks work no differently than live gift cards. You
|
|
596
596
|
must activate a test gift card first in order to test balance checks. Test
|
|
597
597
|
gift cards are real blockchain cards that live on our parallel test blockchain.
|
|
598
598
|
|
|
@@ -617,9 +617,9 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
617
617
|
|
|
618
618
|
# Set request parameters
|
|
619
619
|
request = {
|
|
620
|
-
|
|
621
|
-
|
|
622
|
-
|
|
620
|
+
test: true,
|
|
621
|
+
terminalName: 'Test Terminal',
|
|
622
|
+
cardType: CardType::EBT
|
|
623
623
|
}
|
|
624
624
|
|
|
625
625
|
response = blockchyp.balance(request)
|
|
@@ -632,7 +632,7 @@ puts "Response: #{response.inspect}"
|
|
|
632
632
|
#### Close Batch
|
|
633
633
|
|
|
634
634
|
|
|
635
|
-
This API will close the merchant's batch
|
|
635
|
+
This API will close the merchant's batch if it's currently open.
|
|
636
636
|
|
|
637
637
|
By default, merchant batches will close automatically at 3 AM in their
|
|
638
638
|
local time zone. The automatic batch closure time can be changed
|
|
@@ -656,7 +656,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
656
656
|
|
|
657
657
|
# Set request parameters
|
|
658
658
|
request = {
|
|
659
|
-
|
|
659
|
+
test: true
|
|
660
660
|
}
|
|
661
661
|
|
|
662
662
|
response = blockchyp.closeBatch(request)
|
|
@@ -679,43 +679,59 @@ more control over the look of the email message, you can omit the `autoSend`
|
|
|
679
679
|
flag and send the customer email yourself.
|
|
680
680
|
|
|
681
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.
|
|
682
|
+
you'll need to pass in a total, customer name, and email address. (Unless
|
|
683
|
+
you use the `cashier` flag.)
|
|
683
684
|
|
|
684
685
|
**Customer Info**
|
|
685
686
|
|
|
686
|
-
|
|
687
|
-
or by passing in an existing Customer ID or Customer Ref.
|
|
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.
|
|
688
689
|
|
|
689
690
|
**Line Item Level Data**
|
|
690
691
|
|
|
691
692
|
It's not strictly required, but we strongly recommend sending line item level
|
|
692
|
-
|
|
693
|
+
detail with every request. It will make the invoice look a little more complete
|
|
693
694
|
and the data format for line item level data is the exact same format used
|
|
694
695
|
for terminal line item display, so the same code can be used to support both areas.
|
|
695
696
|
|
|
696
697
|
**Descriptions**
|
|
697
698
|
|
|
698
|
-
You can also
|
|
699
|
+
You can also provide a free form description or message that's displayed near
|
|
699
700
|
the bottom of the invoice. Usually this is some kind of thank you note
|
|
700
|
-
or
|
|
701
|
+
or instruction.
|
|
701
702
|
|
|
702
703
|
**Terms and Conditions**
|
|
703
704
|
|
|
704
705
|
You can include long form contract language with a request and capture
|
|
705
706
|
terms and conditions acceptance at the same time payment is captured.
|
|
706
707
|
|
|
707
|
-
The interface is identical to that used for the terminal based
|
|
708
|
-
|
|
709
|
-
a preconfigured template via `tcAlias`. The
|
|
710
|
-
|
|
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.
|
|
711
712
|
|
|
712
713
|
**Auto Send**
|
|
713
714
|
|
|
714
|
-
|
|
715
|
-
|
|
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.
|
|
716
717
|
If you want BlockChyp to send the email for you, just add the `autoSend` flag with
|
|
717
718
|
all requests.
|
|
718
719
|
|
|
720
|
+
**Tokenization**
|
|
721
|
+
|
|
722
|
+
Add the `enroll` flag to a send link request to enroll the payment method
|
|
723
|
+
in the token vault.
|
|
724
|
+
|
|
725
|
+
**Cashier Facing Card Entry**
|
|
726
|
+
|
|
727
|
+
BlockChyp can be used to generate internal/cashier facing card entry pages as well. This is
|
|
728
|
+
designed for situations where you might need to take a phone order and you don't
|
|
729
|
+
have a terminal.
|
|
730
|
+
|
|
731
|
+
If you pass in the `cashier` flag, no email will be sent and you'll be be able to
|
|
732
|
+
load the link in a browser or iframe for payment entry. When the `cashier` flag
|
|
733
|
+
is used, the `autoSend` flag will be ignored.
|
|
734
|
+
|
|
719
735
|
**Payment Notifications**
|
|
720
736
|
|
|
721
737
|
When a customer successfully submits payment, the merchant will receive an email
|
|
@@ -723,7 +739,7 @@ notifying them that the payment was received.
|
|
|
723
739
|
|
|
724
740
|
**Real Time Callback Notifications**
|
|
725
741
|
|
|
726
|
-
Email notifications are fine, but you may
|
|
742
|
+
Email notifications are fine, but you may want your system to be informed
|
|
727
743
|
immediately whenever a payment event occurs. By using the optional `callbackUrl` request
|
|
728
744
|
property, you can specify a URL to which the Authorization Response will be posted
|
|
729
745
|
every time the user submits a payment, whether approved or otherwise.
|
|
@@ -733,7 +749,7 @@ same format as all BlockChyp charge and preauth transaction responses.
|
|
|
733
749
|
|
|
734
750
|
**Status Polling**
|
|
735
751
|
|
|
736
|
-
If real time callbacks aren't practical or
|
|
752
|
+
If real time callbacks aren't practical or necessary in your environment, you can
|
|
737
753
|
always use the Transaction Status API described below.
|
|
738
754
|
|
|
739
755
|
A common use case for the send link API with status polling is curbside pickup.
|
|
@@ -757,29 +773,29 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
757
773
|
|
|
758
774
|
# Set request parameters
|
|
759
775
|
request = {
|
|
760
|
-
|
|
761
|
-
|
|
762
|
-
|
|
763
|
-
|
|
764
|
-
|
|
765
|
-
|
|
766
|
-
|
|
767
|
-
|
|
776
|
+
amount: '199.99',
|
|
777
|
+
description: 'Widget',
|
|
778
|
+
subject: 'Widget invoice',
|
|
779
|
+
transaction: {
|
|
780
|
+
subtotal: '195.00',
|
|
781
|
+
tax: '4.99',
|
|
782
|
+
total: '199.99',
|
|
783
|
+
items: [
|
|
768
784
|
{
|
|
769
|
-
|
|
770
|
-
|
|
771
|
-
|
|
785
|
+
description: 'Widget',
|
|
786
|
+
price: '195.00',
|
|
787
|
+
quantity: 1
|
|
772
788
|
}
|
|
773
789
|
]
|
|
774
790
|
},
|
|
775
|
-
|
|
776
|
-
|
|
777
|
-
|
|
778
|
-
|
|
779
|
-
|
|
780
|
-
|
|
781
|
-
|
|
782
|
-
|
|
791
|
+
autoSend: true,
|
|
792
|
+
customer: {
|
|
793
|
+
customerRef: 'Customer reference string',
|
|
794
|
+
firstName: 'FirstName',
|
|
795
|
+
lastName: 'LastName',
|
|
796
|
+
companyName: 'Company Name',
|
|
797
|
+
emailAddress: 'support@blockchyp.com',
|
|
798
|
+
smsNumber: '(123) 123-1231'
|
|
783
799
|
}
|
|
784
800
|
}
|
|
785
801
|
|
|
@@ -817,7 +833,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
817
833
|
|
|
818
834
|
# Set request parameters
|
|
819
835
|
request = {
|
|
820
|
-
|
|
836
|
+
transactionId: 'ID of transaction to retrieve'
|
|
821
837
|
}
|
|
822
838
|
|
|
823
839
|
response = blockchyp.transactionStatus(request)
|
|
@@ -851,8 +867,8 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
851
867
|
|
|
852
868
|
# Set request parameters
|
|
853
869
|
request = {
|
|
854
|
-
|
|
855
|
-
|
|
870
|
+
test: true,
|
|
871
|
+
terminalName: 'Test Terminal'
|
|
856
872
|
}
|
|
857
873
|
|
|
858
874
|
response = blockchyp.clear(request)
|
|
@@ -875,7 +891,7 @@ will also return the timestamp of the last status change in the `since` field.
|
|
|
875
891
|
|
|
876
892
|
If the system is running a payment transaction and you wisely passed in a
|
|
877
893
|
Transaction Ref, this API will also return the Transaction Ref of the in progress
|
|
878
|
-
transaction
|
|
894
|
+
transaction.
|
|
879
895
|
|
|
880
896
|
|
|
881
897
|
|
|
@@ -893,7 +909,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
893
909
|
|
|
894
910
|
# Set request parameters
|
|
895
911
|
request = {
|
|
896
|
-
|
|
912
|
+
terminalName: 'Test Terminal'
|
|
897
913
|
}
|
|
898
914
|
|
|
899
915
|
response = blockchyp.terminalStatus(request)
|
|
@@ -908,7 +924,7 @@ puts "Response: #{response.inspect}"
|
|
|
908
924
|
|
|
909
925
|
|
|
910
926
|
This API allows you to prompt a customer to accept a legal agreement on the terminal
|
|
911
|
-
and
|
|
927
|
+
and (usually) capture their signature.
|
|
912
928
|
|
|
913
929
|
Content for the agreement can be specified in two ways. You can reference a
|
|
914
930
|
previously configured T&C template or pass in the full agreement text with every request.
|
|
@@ -929,12 +945,12 @@ pass in the contract text. Note that only plain text is supported.
|
|
|
929
945
|
**Bypassing Signatures**
|
|
930
946
|
|
|
931
947
|
Signature images are captured by default. If for some reason this doesn't fit your
|
|
932
|
-
use case and you'd like to capture acceptance without actually capturing a signature image set
|
|
948
|
+
use case and you'd like to capture acceptance without actually capturing a signature image, set
|
|
933
949
|
the `disableSignature` flag in the request.
|
|
934
950
|
|
|
935
951
|
**Terms & Conditions Log**
|
|
936
952
|
|
|
937
|
-
Every time a user accepts an agreement on the terminal the signature image (if captured),
|
|
953
|
+
Every time a user accepts an agreement on the terminal, the signature image (if captured),
|
|
938
954
|
will be uploaded to the gateway and added to the log along with the full text of the
|
|
939
955
|
agreement. This preserves the historical record in the event that standard agreements
|
|
940
956
|
or templates change over time.
|
|
@@ -961,27 +977,27 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
961
977
|
|
|
962
978
|
# Set request parameters
|
|
963
979
|
request = {
|
|
964
|
-
|
|
965
|
-
|
|
980
|
+
test: true,
|
|
981
|
+
terminalName: 'Test Terminal',
|
|
966
982
|
|
|
967
983
|
# Alias for a Terms and Conditions template configured in the BlockChyp
|
|
968
984
|
# dashboard.
|
|
969
|
-
|
|
985
|
+
tcAlias: 'hippa',
|
|
970
986
|
|
|
971
987
|
# Name of the contract or document if not using an alias.
|
|
972
|
-
|
|
988
|
+
tcName: 'HIPPA Disclosure',
|
|
973
989
|
|
|
974
990
|
# Full text of the contract or disclosure if not using an alias.
|
|
975
|
-
|
|
991
|
+
tcContent: 'Full contract text',
|
|
976
992
|
|
|
977
993
|
# File format for the signature image.
|
|
978
|
-
|
|
994
|
+
sigFormat: SignatureFormat::PNG,
|
|
979
995
|
|
|
980
996
|
# Width of the signature image in pixels.
|
|
981
|
-
|
|
997
|
+
sigWidth: 200,
|
|
982
998
|
|
|
983
999
|
# Whether or not a signature is required. Defaults to true.
|
|
984
|
-
|
|
1000
|
+
sigRequired: true
|
|
985
1001
|
}
|
|
986
1002
|
|
|
987
1003
|
response = blockchyp.termsAndConditions(request)
|
|
@@ -1030,13 +1046,13 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1030
1046
|
|
|
1031
1047
|
# Set request parameters
|
|
1032
1048
|
request = {
|
|
1033
|
-
|
|
1049
|
+
terminalName: 'Test Terminal',
|
|
1034
1050
|
|
|
1035
1051
|
# File format for the signature image.
|
|
1036
|
-
|
|
1052
|
+
sigFormat: SignatureFormat::PNG,
|
|
1037
1053
|
|
|
1038
1054
|
# Width of the signature image in pixels.
|
|
1039
|
-
|
|
1055
|
+
sigWidth: 200
|
|
1040
1056
|
}
|
|
1041
1057
|
|
|
1042
1058
|
response = blockchyp.captureSignature(request)
|
|
@@ -1086,22 +1102,22 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1086
1102
|
|
|
1087
1103
|
# Set request parameters
|
|
1088
1104
|
request = {
|
|
1089
|
-
|
|
1090
|
-
|
|
1091
|
-
|
|
1092
|
-
|
|
1093
|
-
|
|
1094
|
-
|
|
1095
|
-
|
|
1105
|
+
test: true,
|
|
1106
|
+
terminalName: 'Test Terminal',
|
|
1107
|
+
transaction: {
|
|
1108
|
+
subtotal: '60.00',
|
|
1109
|
+
tax: '5.00',
|
|
1110
|
+
total: '65.00',
|
|
1111
|
+
items: [
|
|
1096
1112
|
{
|
|
1097
|
-
|
|
1098
|
-
|
|
1099
|
-
|
|
1100
|
-
|
|
1101
|
-
|
|
1113
|
+
description: 'Leki Trekking Poles',
|
|
1114
|
+
price: '35.00',
|
|
1115
|
+
quantity: 2,
|
|
1116
|
+
extended: '70.00',
|
|
1117
|
+
discounts: [
|
|
1102
1118
|
{
|
|
1103
|
-
|
|
1104
|
-
|
|
1119
|
+
description: 'memberDiscount',
|
|
1120
|
+
amount: '10.00'
|
|
1105
1121
|
}
|
|
1106
1122
|
]
|
|
1107
1123
|
}
|
|
@@ -1164,22 +1180,22 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1164
1180
|
|
|
1165
1181
|
# Set request parameters
|
|
1166
1182
|
request = {
|
|
1167
|
-
|
|
1168
|
-
|
|
1169
|
-
|
|
1170
|
-
|
|
1171
|
-
|
|
1172
|
-
|
|
1173
|
-
|
|
1183
|
+
test: true,
|
|
1184
|
+
terminalName: 'Test Terminal',
|
|
1185
|
+
transaction: {
|
|
1186
|
+
subtotal: '60.00',
|
|
1187
|
+
tax: '5.00',
|
|
1188
|
+
total: '65.00',
|
|
1189
|
+
items: [
|
|
1174
1190
|
{
|
|
1175
|
-
|
|
1176
|
-
|
|
1177
|
-
|
|
1178
|
-
|
|
1179
|
-
|
|
1191
|
+
description: 'Leki Trekking Poles',
|
|
1192
|
+
price: '35.00',
|
|
1193
|
+
quantity: 2,
|
|
1194
|
+
extended: '70.00',
|
|
1195
|
+
discounts: [
|
|
1180
1196
|
{
|
|
1181
|
-
|
|
1182
|
-
|
|
1197
|
+
description: 'memberDiscount',
|
|
1198
|
+
amount: '10.00'
|
|
1183
1199
|
}
|
|
1184
1200
|
]
|
|
1185
1201
|
}
|
|
@@ -1218,9 +1234,9 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1218
1234
|
|
|
1219
1235
|
# Set request parameters
|
|
1220
1236
|
request = {
|
|
1221
|
-
|
|
1222
|
-
|
|
1223
|
-
|
|
1237
|
+
test: true,
|
|
1238
|
+
terminalName: 'Test Terminal',
|
|
1239
|
+
message: 'Thank you for your business.'
|
|
1224
1240
|
}
|
|
1225
1241
|
|
|
1226
1242
|
response = blockchyp.message(request)
|
|
@@ -1263,11 +1279,11 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1263
1279
|
|
|
1264
1280
|
# Set request parameters
|
|
1265
1281
|
request = {
|
|
1266
|
-
|
|
1267
|
-
|
|
1268
|
-
|
|
1269
|
-
|
|
1270
|
-
|
|
1282
|
+
test: true,
|
|
1283
|
+
terminalName: 'Test Terminal',
|
|
1284
|
+
prompt: 'Would you like to become a member?',
|
|
1285
|
+
yesCaption: 'Yes',
|
|
1286
|
+
noCaption: 'No'
|
|
1271
1287
|
}
|
|
1272
1288
|
|
|
1273
1289
|
response = blockchyp.booleanPrompt(request)
|
|
@@ -1319,12 +1335,12 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1319
1335
|
|
|
1320
1336
|
# Set request parameters
|
|
1321
1337
|
request = {
|
|
1322
|
-
|
|
1323
|
-
|
|
1338
|
+
test: true,
|
|
1339
|
+
terminalName: 'Test Terminal',
|
|
1324
1340
|
|
|
1325
1341
|
# Type of prompt. Can be 'email', 'phone', 'customer-number', or
|
|
1326
1342
|
# 'rewards-number'.
|
|
1327
|
-
|
|
1343
|
+
promptType: PromptType::EMAIL
|
|
1328
1344
|
}
|
|
1329
1345
|
|
|
1330
1346
|
response = blockchyp.textPrompt(request)
|
|
@@ -1341,7 +1357,7 @@ puts "Response: #{response.inspect}"
|
|
|
1341
1357
|
Adds or updates a customer record.
|
|
1342
1358
|
|
|
1343
1359
|
If you pass in customer information including `firstName`, `lastName`, `email`,
|
|
1344
|
-
|
|
1360
|
+
or `sms` without any Customer ID or Customer Ref, a new record will
|
|
1345
1361
|
be created.
|
|
1346
1362
|
|
|
1347
1363
|
If you pass in `customerRef` and `customerId`, the customer record will be updated
|
|
@@ -1378,14 +1394,14 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1378
1394
|
|
|
1379
1395
|
# Set request parameters
|
|
1380
1396
|
request = {
|
|
1381
|
-
|
|
1382
|
-
|
|
1383
|
-
|
|
1384
|
-
|
|
1385
|
-
|
|
1386
|
-
|
|
1387
|
-
|
|
1388
|
-
|
|
1397
|
+
customer: {
|
|
1398
|
+
id: 'ID of the customer to update',
|
|
1399
|
+
customerRef: 'Customer reference string',
|
|
1400
|
+
firstName: 'FirstName',
|
|
1401
|
+
lastName: 'LastName',
|
|
1402
|
+
companyName: 'Company Name',
|
|
1403
|
+
emailAddress: 'support@blockchyp.com',
|
|
1404
|
+
smsNumber: '(123) 123-1231'
|
|
1389
1405
|
}
|
|
1390
1406
|
}
|
|
1391
1407
|
|
|
@@ -1421,7 +1437,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1421
1437
|
|
|
1422
1438
|
# Set request parameters
|
|
1423
1439
|
request = {
|
|
1424
|
-
|
|
1440
|
+
customerId: 'ID of the customer to retrieve'
|
|
1425
1441
|
}
|
|
1426
1442
|
|
|
1427
1443
|
response = blockchyp.customer(request)
|
|
@@ -1456,7 +1472,7 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1456
1472
|
|
|
1457
1473
|
# Set request parameters
|
|
1458
1474
|
request = {
|
|
1459
|
-
|
|
1475
|
+
query: '(123) 123-1234'
|
|
1460
1476
|
}
|
|
1461
1477
|
|
|
1462
1478
|
response = blockchyp.customerSearch(request)
|
|
@@ -1492,9 +1508,9 @@ blockchyp = BlockChyp::BlockChyp.new(
|
|
|
1492
1508
|
|
|
1493
1509
|
# Set request parameters
|
|
1494
1510
|
request = {
|
|
1495
|
-
|
|
1496
|
-
|
|
1497
|
-
|
|
1511
|
+
amount: '100.00',
|
|
1512
|
+
cashDiscount: true,
|
|
1513
|
+
surcharge: true
|
|
1498
1514
|
}
|
|
1499
1515
|
|
|
1500
1516
|
response = blockchyp.cashDiscount(request)
|
|
@@ -1502,6 +1518,198 @@ response = blockchyp.cashDiscount(request)
|
|
|
1502
1518
|
puts "Response: #{response.inspect}"
|
|
1503
1519
|
|
|
1504
1520
|
|
|
1521
|
+
```
|
|
1522
|
+
|
|
1523
|
+
#### Batch History
|
|
1524
|
+
|
|
1525
|
+
|
|
1526
|
+
|
|
1527
|
+
This endpoint allows developers to query the gateway for the merchant's batch history.
|
|
1528
|
+
The data will be returned in descending order of open date with the most recent
|
|
1529
|
+
batch returned first. The results will include basic information about the batch.
|
|
1530
|
+
For more detail about a specific batch, consider using the Batch Details API.
|
|
1531
|
+
|
|
1532
|
+
**Limiting Results**
|
|
1533
|
+
|
|
1534
|
+
This API will return a maximum of 250 results. Use the `maxResults` property to
|
|
1535
|
+
limit maximum results even further and use the `startIndex` property to
|
|
1536
|
+
page through results that span multiple queries.
|
|
1537
|
+
|
|
1538
|
+
For example, if you want the ten most recent batches, just pass in a value of
|
|
1539
|
+
`10` for `maxResults`. Also note that `startIndex` is zero based. Use a value of `0` to
|
|
1540
|
+
get the first batch in the dataset.
|
|
1541
|
+
|
|
1542
|
+
**Filtering By Date Range**
|
|
1543
|
+
|
|
1544
|
+
You can also filter results by date. Use the `startDate` and `endDate`
|
|
1545
|
+
properties to return only those batches opened between those dates.
|
|
1546
|
+
You can use either `startDate` and `endDate` and you can use date filters
|
|
1547
|
+
in conjunction with `maxResults` and `startIndex`
|
|
1548
|
+
|
|
1549
|
+
|
|
1550
|
+
|
|
1551
|
+
|
|
1552
|
+
```ruby
|
|
1553
|
+
# frozen_string_literal: true
|
|
1554
|
+
|
|
1555
|
+
require 'blockchyp'
|
|
1556
|
+
|
|
1557
|
+
blockchyp = BlockChyp::BlockChyp.new(
|
|
1558
|
+
ENV['BC_API_KEY'],
|
|
1559
|
+
ENV['BC_BEARER_TOKEN'],
|
|
1560
|
+
ENV['BC_SIGNING_KEY']
|
|
1561
|
+
)
|
|
1562
|
+
|
|
1563
|
+
# Set request parameters
|
|
1564
|
+
request = {
|
|
1565
|
+
maxResults: 250,
|
|
1566
|
+
startIndex: 1
|
|
1567
|
+
}
|
|
1568
|
+
|
|
1569
|
+
response = blockchyp.batchHistory(request)
|
|
1570
|
+
|
|
1571
|
+
puts "Response: #{response.inspect}"
|
|
1572
|
+
|
|
1573
|
+
|
|
1574
|
+
```
|
|
1575
|
+
|
|
1576
|
+
#### Batch Details
|
|
1577
|
+
|
|
1578
|
+
|
|
1579
|
+
|
|
1580
|
+
This endpoint allows developers to pull down details for a specific batch,
|
|
1581
|
+
including captured volume, gift card activity, expected deposit, and
|
|
1582
|
+
captured volume broken down by terminal.
|
|
1583
|
+
|
|
1584
|
+
The only required request parameter is `batchId`. Batch IDs are returned
|
|
1585
|
+
with every transaction response and can also be discovered using the Batch
|
|
1586
|
+
History API.
|
|
1587
|
+
|
|
1588
|
+
|
|
1589
|
+
|
|
1590
|
+
|
|
1591
|
+
```ruby
|
|
1592
|
+
# frozen_string_literal: true
|
|
1593
|
+
|
|
1594
|
+
require 'blockchyp'
|
|
1595
|
+
|
|
1596
|
+
blockchyp = BlockChyp::BlockChyp.new(
|
|
1597
|
+
ENV['BC_API_KEY'],
|
|
1598
|
+
ENV['BC_BEARER_TOKEN'],
|
|
1599
|
+
ENV['BC_SIGNING_KEY']
|
|
1600
|
+
)
|
|
1601
|
+
|
|
1602
|
+
# Set request parameters
|
|
1603
|
+
request = {
|
|
1604
|
+
batchId: 'BATCHID'
|
|
1605
|
+
}
|
|
1606
|
+
|
|
1607
|
+
response = blockchyp.batchDetails(request)
|
|
1608
|
+
|
|
1609
|
+
puts "Response: #{response.inspect}"
|
|
1610
|
+
|
|
1611
|
+
|
|
1612
|
+
```
|
|
1613
|
+
|
|
1614
|
+
#### Transaction History
|
|
1615
|
+
|
|
1616
|
+
|
|
1617
|
+
|
|
1618
|
+
This endpoint provides a number of different methods to sift through
|
|
1619
|
+
transaction history.
|
|
1620
|
+
|
|
1621
|
+
By default with no filtering properties, this endpoint will return the 250
|
|
1622
|
+
most recent transactions.
|
|
1623
|
+
|
|
1624
|
+
**Limiting Results**
|
|
1625
|
+
|
|
1626
|
+
This API will return a maximum of 250 results in a single query. Use the `maxResults` property
|
|
1627
|
+
to limit maximum results even further and use the `startIndex` property to
|
|
1628
|
+
page through results that span multiple queries.
|
|
1629
|
+
|
|
1630
|
+
For example, if you want the ten most recent batches, just pass in a value of
|
|
1631
|
+
`10` for `maxResults`. Also note that `startIndex` is zero based. Use a value of `0` to
|
|
1632
|
+
get the first transaction in the dataset.
|
|
1633
|
+
|
|
1634
|
+
**Filtering By Date Range**
|
|
1635
|
+
|
|
1636
|
+
You can also filter results by date. Use the `startDate` and `endDate`
|
|
1637
|
+
properties to return only transactions run between those dates.
|
|
1638
|
+
You can use either `startDate` or `endDate` and you can use date filters
|
|
1639
|
+
in conjunction with `maxResults` and `startIndex`
|
|
1640
|
+
|
|
1641
|
+
**Filtering By Batch**
|
|
1642
|
+
|
|
1643
|
+
To restrict results to a single batch, pass in the `batchId` parameter.
|
|
1644
|
+
|
|
1645
|
+
**Filtering By Terminal**
|
|
1646
|
+
|
|
1647
|
+
To restrict results to those executed on a single terminal, just
|
|
1648
|
+
pass in the terminal name.
|
|
1649
|
+
|
|
1650
|
+
**Combining Filters**
|
|
1651
|
+
|
|
1652
|
+
None of the above filters are mutually exclusive. You can combine any of the
|
|
1653
|
+
above properties in a single request to restrict transaction results to a
|
|
1654
|
+
narrower set of results.
|
|
1655
|
+
|
|
1656
|
+
|
|
1657
|
+
|
|
1658
|
+
|
|
1659
|
+
```ruby
|
|
1660
|
+
# frozen_string_literal: true
|
|
1661
|
+
|
|
1662
|
+
require 'blockchyp'
|
|
1663
|
+
|
|
1664
|
+
blockchyp = BlockChyp::BlockChyp.new(
|
|
1665
|
+
ENV['BC_API_KEY'],
|
|
1666
|
+
ENV['BC_BEARER_TOKEN'],
|
|
1667
|
+
ENV['BC_SIGNING_KEY']
|
|
1668
|
+
)
|
|
1669
|
+
|
|
1670
|
+
# Set request parameters
|
|
1671
|
+
request = {
|
|
1672
|
+
maxResults: 10
|
|
1673
|
+
}
|
|
1674
|
+
|
|
1675
|
+
response = blockchyp.transactionHistory(request)
|
|
1676
|
+
|
|
1677
|
+
puts "Response: #{response.inspect}"
|
|
1678
|
+
|
|
1679
|
+
|
|
1680
|
+
```
|
|
1681
|
+
|
|
1682
|
+
#### Merchant Profile
|
|
1683
|
+
|
|
1684
|
+
|
|
1685
|
+
|
|
1686
|
+
Returns detailed metadata about the merchant's configuraton, including
|
|
1687
|
+
basic identity information, terminal settings, store and forward settings,
|
|
1688
|
+
and bank account information for merchants that support split settlement.
|
|
1689
|
+
|
|
1690
|
+
|
|
1691
|
+
|
|
1692
|
+
|
|
1693
|
+
```ruby
|
|
1694
|
+
# frozen_string_literal: true
|
|
1695
|
+
|
|
1696
|
+
require 'blockchyp'
|
|
1697
|
+
|
|
1698
|
+
blockchyp = BlockChyp::BlockChyp.new(
|
|
1699
|
+
ENV['BC_API_KEY'],
|
|
1700
|
+
ENV['BC_BEARER_TOKEN'],
|
|
1701
|
+
ENV['BC_SIGNING_KEY']
|
|
1702
|
+
)
|
|
1703
|
+
|
|
1704
|
+
# Set request parameters
|
|
1705
|
+
request = {
|
|
1706
|
+
}
|
|
1707
|
+
|
|
1708
|
+
response = blockchyp.merchantProfile(request)
|
|
1709
|
+
|
|
1710
|
+
puts "Response: #{response.inspect}"
|
|
1711
|
+
|
|
1712
|
+
|
|
1505
1713
|
```
|
|
1506
1714
|
|
|
1507
1715
|
## Running Integration Tests
|