TransactionNumber Property
The transaction number for the current transaction.
Syntax
__property int TransactionNumber = {read=FTransactionNumber, write=FSetTransactionNumber, default=0};
Default Value
0
Remarks
This property is used to specify the transaction number for the current transaction. The valid values are 0 - 999. A TransactionNumber of 0 is only used and MUST be used for AuthOnly transactions, thus all other transaction types must have a TransactionNumber of 1 or greater. The maximum value of TransactionNumber is 999 (note: closing a batch requires an item number and thus the actual number of transactions in a batch is 998).
If a transaction is unsuccessful the TransactionNumber should be re-used.
For Credit Card transactions, the TransactionNumber starts at 1 (provided it is not an AuthOnly transaction) and must increment with each successful transaction.
For Debit/EBT Card transactions, the TransactionNumber starts at 999 and must decrement with each successful transaction.
Note TransactionNumbers for Credit Card and Debit/EBT cards *cannot* overlap and must be unique. Additionally, there must be an open TransactionNumber for the close batch transaction. For example, you can have 1-454 for Credit Card transactions and 456-999 for Debit/EBT cards but TransactionNumber 455 must be left available for the close batch transaction.
Item numbers do NOT have to be processed in sequence (i.e. 1, 2, 3, etc.). However, when a batch is closed all transactions up to the TransactionNumber specified to close the batch must be accounted for. For example; if a batch is closed using TransactionNumber 5, transactions 1, 2, 3, and 4 MUST be accounted for. Additionally, if the batch is closed using an TransactionNumber that is not one more than the number of items in the batch, the Host will delete all records over the close TransactionNumber. For example; if a batch is closed using TransactionNumber 5, transaction records 5, 6, 7, etc. will be automatically deleted by the system.
Each transaction that posts to the Host with an TransactionNumber must keep that TransactionNumber until the batch is closed. Note: the Host accepts two or more transactions with the same TransactionNumber, but the last transaction will overwrite any previous transactions. For example, if a Sale is performed for TransactionNumber 1 and then a Credit is performed, only the Credit will post to the cardholder's account (it will be as if the Sale transaction never happened, with the exception of the reserved funds).
This property is not applicable for the ttRevise and ttVoid transaction types. Thus when GetDetailAggregate is called, the returned aggregate will contain the TransactionNumber specified within the original transaction.
Below is a table of the various transaction types and how TransactionNumber should be handled for Credit Card transactions. Note that the below table is only applicable to Credit Card transactions.
Credit Card Transaction Type | TransactionNumber Handling |
AuthOnly | TransactionNumber = 0 (This is the case for all AuthOnly transactions). |
Sale | Last TransactionNumber + 1 |
Capture | Last TransactionNumber + 1 |
Refund | Last TransactionNumber + 1 |
Revise | Not applicable as the TransactionNumber contained within the DetailAggregate is used. |
Void | Not applicable as the TransactionNumber contained within the DetailAggregate is used. |
Debit/EBT cards are always performed online and thus each successful transaction should have their own unique TransactionNumber that starts at 999 and decrements by 1 for each success transaction performed.
Debit/EBT Card Transaction Type | TransactionNumber Handling |
All | Last TransactionNumber - 1 |
Data Type
Integer