v1

latestOpenAPI 3.0.02026-07-24226294602.4 KB
Transaction

Get Transaction by ID

Get a Transaction by ID.

get/financials/transactions/{transaction_id}

Path parameters

transaction_idinteger required

The transaction identifier

Headers

x-api-keystring required

A valid API key. If you don't have one, please request one through the Web Integrations screen.

Response

Transaction Data

idinteger

Transaction Id

namestring

Transaction Name

invoice_idinteger

invoice_header_id

payment_method_idinteger

Payment Method Identifier

location_idinteger

Location Identifier

amountnumber

Amount

feesnumber

Fees

net_amountnumber

NetAmount

check_numberstring

Check Number

transaction_type_idinteger

Transaction Type Id

transaction_typestring

Transaction Type

transaction_result_idinteger

Transaction Result Id

transaction_resultstring

Transaction Result

order_idstring

Order Identifier

error_codestring

Error Code

error_textstring

Error Text

auth_textstring

Auth Text

reference_numberstring

Reference Number

parent_transaction_idinteger

Parent Transaction Identifier

has_settledboolean

Has Settled

status_updated_onstring date-time

Status Updated On Date Time

credit_card_typestring

Credit Card Type

transaction_datetimestring date-time

Transaction Date Time

is_pendingboolean

Is Pending

settle_datetimestring date-time

Settle Date Time

effective_datetimestring date-time

Effective Date Time

passed_feesnumber

Passed Fees amount

wodify_validation_resultstring

The purpose of this attribute is to save any UserException message, that is, and user friendly message that should be shown to the end user. All methods should have, just like service actions:

  • an UserException with Abort Transaction = Yes, and a Log Error = No
  • an AllExceptions with Abort Transaction = Yes, and a Log Error = Yes With this, any known issue that we don't consider an error log, like a business validation, we raise it to be catch in the UserException and we don't log it. Then, in the OnResponse of the full REST service, the Build_Response_JSON action will take care on the output json format. An Exception will have the default formatted error message. If its an AllException, it will log the error so that we can fix it. If its a UserException, it will deliver as an error but it won't log it as an error. A success output will not have this attribute, the Build_Response_JSON will remove it from the final output.

Example response

{
  "id": 1234567891234567,
  "invoice_id": 1234567891234567,
  "payment_method_id": 1234567891234567,
  "location_id": 1234567891234567,
  "amount": 0.1,
  "fees": 0.1,
  "net_amount": 0.1,
  "transaction_type_id": 1234567891234567,
  "transaction_result_id": 1234567891234567,
  "parent_transaction_id": 1234567891234567,
  "status_updated_on": "2014-12-31T23:59:59.938Z",
  "transaction_datetime": "2014-12-31T23:59:59.938Z",
  "settle_datetime": "2014-12-31T23:59:59.938Z",
  "effective_datetime": "2014-12-31T23:59:59.938Z",
  "created": {
    "created_by_id": 1234567891234567,
    "created_on_datetime": "2014-12-31T23:59:59.938Z"
  },
  "updated": {
    "updated_by_id": 1234567891234567,
    "updated_on_datetime": "2014-12-31T23:59:59.938Z"
  },
  "passed_fees": 0.1
}