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 +4 -4
- data/README.md +1057 -295
- data/lib/blockchyp.rb +68 -48
- data/lib/blockchyp/version.rb +1 -1
- data/test/batch_history_test.rb +48 -0
- data/test/get_customer_test.rb +2 -2
- data/test/pan_charge_test.rb +1 -1
- data/test/pan_enroll_test.rb +1 -1
- data/test/pan_preauth_test.rb +1 -1
- data/test/search_customer_test.rb +2 -2
- data/test/simple_batch_close_test.rb +2 -2
- data/test/simple_capture_test.rb +2 -2
- data/test/simple_refund_test.rb +2 -2
- data/test/simple_reversal_test.rb +2 -2
- data/test/simple_void_test.rb +2 -2
- data/test/terminal_charge_test.rb +1 -1
- data/test/terminal_ebt_charge_test.rb +1 -1
- data/test/terminal_enroll_test.rb +1 -1
- data/test/terminal_keyed_charge_test.rb +1 -1
- data/test/terminal_manual_ebt_charge_test.rb +1 -1
- data/test/terminal_preauth_test.rb +1 -1
- data/test/transaction_history_test.rb +48 -0
- metadata +4 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 5ca711b2e47c0391a4d2bae6df5f33eb9585fca0aec4121aa2a26bf6a96a2516
|
4
|
+
data.tar.gz: e63cfc05d92201d6ed4d30f6f0e7f83aa5224b8fbc54b34b8845e427bcef52f3
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
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
|
-
##
|
52
|
+
## Additional Documentation
|
53
53
|
|
54
|
-
|
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
|
-
[
|
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
|
-
####
|
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
|
-
"
|
120
|
-
"terminalName": 'Test Terminal',
|
121
|
-
"amount": '55.00'
|
107
|
+
"terminalName": 'Test Terminal'
|
122
108
|
}
|
123
109
|
|
124
|
-
response = blockchyp.
|
110
|
+
response = blockchyp.ping(request)
|
125
111
|
|
126
112
|
puts "Response: #{response.inspect}"
|
127
113
|
|
128
114
|
|
129
115
|
```
|
130
116
|
|
131
|
-
####
|
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": '
|
171
|
+
"amount": '55.00'
|
152
172
|
}
|
153
173
|
|
154
|
-
response = blockchyp.
|
174
|
+
response = blockchyp.charge(request)
|
155
175
|
|
156
176
|
puts "Response: #{response.inspect}"
|
157
177
|
|
158
178
|
|
159
179
|
```
|
160
180
|
|
161
|
-
####
|
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
|
-
|
167
|
-
|
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
|
-
|
191
|
+
Preauthorizations can use a payment terminal to capture a payment or
|
192
|
+
use a previously enrolled payment token.
|
170
193
|
|
171
|
-
|
172
|
-
ENV['BC_API_KEY'],
|
173
|
-
ENV['BC_BEARER_TOKEN'],
|
174
|
-
ENV['BC_SIGNING_KEY']
|
175
|
-
)
|
194
|
+
**Terminal Transactions**
|
176
195
|
|
177
|
-
|
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
|
-
|
198
|
+
**Token Transactions**
|
183
199
|
|
184
|
-
|
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
|
-
"
|
235
|
+
"amount": '27.00'
|
210
236
|
}
|
211
237
|
|
212
|
-
response = blockchyp.
|
238
|
+
response = blockchyp.preauth(request)
|
213
239
|
|
214
240
|
puts "Response: #{response.inspect}"
|
215
241
|
|
216
242
|
|
217
243
|
```
|
218
244
|
|
219
|
-
####
|
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
|
-
"
|
274
|
+
"transactionId": '<PREAUTH TRANSACTION ID>'
|
239
275
|
}
|
240
276
|
|
241
|
-
response = blockchyp.
|
277
|
+
response = blockchyp.capture(request)
|
242
278
|
|
243
279
|
puts "Response: #{response.inspect}"
|
244
280
|
|
245
281
|
|
246
282
|
```
|
247
283
|
|
248
|
-
####
|
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
|
-
"
|
267
|
-
"terminalName": 'Test Terminal',
|
349
|
+
"transactionId": '<PREVIOUS TRANSACTION ID>',
|
268
350
|
|
269
|
-
#
|
270
|
-
|
271
|
-
|
351
|
+
# Optional amount for partial refunds.
|
352
|
+
"amount": '5.00'
|
353
|
+
}
|
272
354
|
|
273
|
-
|
274
|
-
"tcName": 'HIPPA Disclosure',
|
355
|
+
response = blockchyp.refund(request)
|
275
356
|
|
276
|
-
|
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
|
-
|
283
|
-
"sigWidth": 200,
|
360
|
+
```
|
284
361
|
|
285
|
-
|
286
|
-
"sigRequired": true
|
287
|
-
}
|
362
|
+
#### Enroll
|
288
363
|
|
289
|
-
response = blockchyp.termsAndConditions(request)
|
290
364
|
|
291
|
-
|
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.
|
401
|
+
response = blockchyp.enroll(request)
|
340
402
|
|
341
403
|
puts "Response: #{response.inspect}"
|
342
404
|
|
343
405
|
|
344
406
|
```
|
345
407
|
|
346
|
-
####
|
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
|
-
"
|
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.
|
438
|
+
response = blockchyp.void(request)
|
388
439
|
|
389
440
|
puts "Response: #{response.inspect}"
|
390
441
|
|
391
442
|
|
392
443
|
```
|
393
444
|
|
394
|
-
####
|
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
|
-
"
|
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.
|
485
|
+
response = blockchyp.reverse(request)
|
421
486
|
|
422
487
|
puts "Response: #{response.inspect}"
|
423
488
|
|
424
489
|
|
425
490
|
```
|
426
491
|
|
427
|
-
####
|
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
|
-
"
|
448
|
-
"yesCaption": 'Yes',
|
449
|
-
"noCaption": 'No'
|
564
|
+
"amount": '50.00'
|
450
565
|
}
|
451
566
|
|
452
|
-
response = blockchyp.
|
567
|
+
response = blockchyp.giftActivate(request)
|
453
568
|
|
454
569
|
puts "Response: #{response.inspect}"
|
455
570
|
|
456
571
|
|
457
572
|
```
|
458
573
|
|
459
|
-
####
|
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
|
-
"
|
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.
|
1123
|
+
response = blockchyp.newTransactionDisplay(request)
|
483
1124
|
|
484
1125
|
puts "Response: #{response.inspect}"
|
485
1126
|
|
486
1127
|
|
487
1128
|
```
|
488
1129
|
|
489
|
-
####
|
490
|
-
|
491
|
-
Executes a refund.
|
1130
|
+
#### Update Transaction Display
|
492
1131
|
|
493
1132
|
|
494
|
-
```ruby
|
495
|
-
# frozen_string_literal: true
|
496
1133
|
|
497
|
-
|
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
|
-
|
500
|
-
|
501
|
-
|
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
|
-
|
506
|
-
|
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
|
-
|
511
|
-
|
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
|
-
|
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
|
-
|
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.
|
1201
|
+
response = blockchyp.updateTransactionDisplay(request)
|
544
1202
|
|
545
1203
|
puts "Response: #{response.inspect}"
|
546
1204
|
|
547
1205
|
|
548
1206
|
```
|
549
1207
|
|
550
|
-
####
|
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
|
-
"
|
1234
|
+
"message": 'Thank you for your business.'
|
571
1235
|
}
|
572
1236
|
|
573
|
-
response = blockchyp.
|
1237
|
+
response = blockchyp.message(request)
|
574
1238
|
|
575
1239
|
puts "Response: #{response.inspect}"
|
576
1240
|
|
577
1241
|
|
578
1242
|
```
|
579
1243
|
|
580
|
-
####
|
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
|
-
"
|
1279
|
+
"prompt": 'Would you like to become a member?',
|
1280
|
+
"yesCaption": 'Yes',
|
1281
|
+
"noCaption": 'No'
|
608
1282
|
}
|
609
1283
|
|
610
|
-
response = blockchyp.
|
1284
|
+
response = blockchyp.booleanPrompt(request)
|
611
1285
|
|
612
1286
|
puts "Response: #{response.inspect}"
|
613
1287
|
|
614
1288
|
|
615
1289
|
```
|
616
1290
|
|
617
|
-
####
|
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
|
-
"
|
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.
|
1341
|
+
response = blockchyp.textPrompt(request)
|
640
1342
|
|
641
1343
|
puts "Response: #{response.inspect}"
|
642
1344
|
|
643
1345
|
|
644
1346
|
```
|
645
1347
|
|
646
|
-
####
|
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
|
-
|
1352
|
+
Adds or updates a customer record.
|
655
1353
|
|
656
|
-
|
657
|
-
|
658
|
-
|
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
|
-
|
663
|
-
|
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
|
-
|
1361
|
+
**Customer Ref**
|
668
1362
|
|
669
|
-
|
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
|
-
"
|
693
|
-
|
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.
|
1403
|
+
response = blockchyp.updateCustomer(request)
|
697
1404
|
|
698
1405
|
puts "Response: #{response.inspect}"
|
699
1406
|
|
700
1407
|
|
701
1408
|
```
|
702
1409
|
|
703
|
-
####
|
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
|
-
"
|
1435
|
+
"customerId": 'ID of the customer to retrieve'
|
722
1436
|
}
|
723
1437
|
|
724
|
-
response = blockchyp.
|
1438
|
+
response = blockchyp.customer(request)
|
725
1439
|
|
726
1440
|
puts "Response: #{response.inspect}"
|
727
1441
|
|
728
1442
|
|
729
1443
|
```
|
730
1444
|
|
731
|
-
####
|
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
|
-
"
|
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.
|
1473
|
+
response = blockchyp.customerSearch(request)
|
759
1474
|
|
760
1475
|
puts "Response: #{response.inspect}"
|
761
1476
|
|
762
1477
|
|
763
1478
|
```
|
764
1479
|
|
765
|
-
####
|
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
|
-
"
|
784
|
-
|
785
|
-
|
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.
|
1511
|
+
response = blockchyp.cashDiscount(request)
|
795
1512
|
|
796
1513
|
puts "Response: #{response.inspect}"
|
797
1514
|
|
798
1515
|
|
799
1516
|
```
|
800
1517
|
|
801
|
-
####
|
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
|
-
"
|
1560
|
+
"maxResults": 250,
|
1561
|
+
"startIndex": 1
|
820
1562
|
}
|
821
1563
|
|
822
|
-
response = blockchyp.
|
1564
|
+
response = blockchyp.batchHistory(request)
|
823
1565
|
|
824
1566
|
puts "Response: #{response.inspect}"
|
825
1567
|
|
826
1568
|
|
827
1569
|
```
|
828
1570
|
|
829
|
-
####
|
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
|
-
"
|
1599
|
+
"batchId": 'BATCHID'
|
848
1600
|
}
|
849
1601
|
|
850
|
-
response = blockchyp.
|
1602
|
+
response = blockchyp.batchDetails(request)
|
851
1603
|
|
852
1604
|
puts "Response: #{response.inspect}"
|
853
1605
|
|
854
1606
|
|
855
1607
|
```
|
856
1608
|
|
857
|
-
#### Transaction
|
1609
|
+
#### Transaction History
|
858
1610
|
|
859
|
-
Retrieves the current status of a transaction.
|
860
1611
|
|
861
1612
|
|
862
|
-
|
863
|
-
|
1613
|
+
This endpoint provides a number of different methods to sift through
|
1614
|
+
transaction history.
|
864
1615
|
|
865
|
-
|
1616
|
+
By default with no filtering properties, this endpoint will return the 250
|
1617
|
+
most recent transactions.
|
866
1618
|
|
867
|
-
|
868
|
-
ENV['BC_API_KEY'],
|
869
|
-
ENV['BC_BEARER_TOKEN'],
|
870
|
-
ENV['BC_SIGNING_KEY']
|
871
|
-
)
|
1619
|
+
**Limiting Results**
|
872
1620
|
|
873
|
-
|
874
|
-
|
875
|
-
|
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
|
-
|
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
|
-
|
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
|
-
"
|
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.
|
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)
|