Capture

View as Markdown
The capture request is the second step the merchant POS will call when the customer hangs up the pump and the fuel transaction is completed. 1. Ensure the `transaction_id` and `payment_code` pair match a previously authorized transaction. 2. The `transaction_time_ms` should be the epoch time in millis of when the customer completed the transaction. 3. The amounts (volume and retail costs) are within the bounds of the authorization response. 1. If the volume or retail costs are outside of the authorization response amounts, the capture will be **declined**. 4. A transaction may only be captured once. Additional captures will error out (except in the case where the request body is identical). 1. Duplicate requests for the same transations and capture amounts will return identical responses. Since pumps are not precise instruments, we suggest that the volume and cost amounts are capped (i.e. via `min(auth_volume, actual_volume)`), and the pump hardware is configured to release less than the authorized amounts (e.g. 0.5G less). **Using the Merchant Initiated Flag** You may do a capture without an explicit authorization by using the `merchant_initiated`flag. This is useful in cases when there's an overfill, or as part of a refund + recapture flow. To ensure this works correctly, send the same `payment_code` as original transaction but a new `transaction_id`.

Authentication

AuthorizationBearer

Bearer authentication of the form Bearer <token>, where token is your auth token.

Request

This endpoint expects an object.
merchant_idstringRequired
site_idstringRequired
transaction_idstringRequired
transaction_time_msintegerRequired
transaction_amtdoubleRequired
merchant_initiatedbooleanRequired
fuellist of objectsRequired
payment_codestringRequired

Response

OK
merchant_idstring
transaction_idstring
authorized_amtdouble
authorized_flagboolean
authorization_codestring

Errors

400
Bad Request Error