HistoryItemType: Difference between revisions

From Barion Documentation
Jump to navigation Jump to search
Line 20: Line 20:
| CardPayment || 4|| The initialized payment transaction was paid with a bank card. History items with this type can be reserved<sup>1</sup> or successfully completed transactions.
| CardPayment || 4|| The initialized payment transaction was paid with a bank card. History items with this type can be reserved<sup>1</sup> or successfully completed transactions.
|-
|-
| RefundToCard || 5||
| RefundToCard || 5|| Refund to a bank card after a completed payment transaction. In this case, the funding source of the payment is a bank card. Payment transactions of this type can be failed or successfully completed. Failed transactions are normalized, and the system initializes the refund process. In other cases, the refund was initiated through the GUI or the API.
|-
|-
| PayeeTransaction || 6||
| PayeeTransaction || 6 || If the integrated system works with complex payment scenarios, then one or more payee transactions can be defined for each payment transaction. More details of the Payee transactions can be found [[Payee_transactions | here]].
|-
|-
| GatewayFee || 7||
| GatewayFee || 7||

Revision as of 08:28, 14 November 2022

History item type enumeration

This enum indicates the type of history items.

Included in

History item types are used in the following structures:

Enum list

Enum value Byte / int value Description
InternalTransfer 1 Internal e-money transfer between Barion users.
InternalTransferToExternalUser 2 E-money transfer to a non-existent user. In this case, the recipient has a defined timeframe to get the amount of the transaction.
ElectronicPayment 3 The initialized payment transaction was paid with Barion Wallet. History items with this type can be reserved1 or successfully completed transactions.
CardPayment 4 The initialized payment transaction was paid with a bank card. History items with this type can be reserved1 or successfully completed transactions.
RefundToCard 5 Refund to a bank card after a completed payment transaction. In this case, the funding source of the payment is a bank card. Payment transactions of this type can be failed or successfully completed. Failed transactions are normalized, and the system initializes the refund process. In other cases, the refund was initiated through the GUI or the API.
PayeeTransaction 6 If the integrated system works with complex payment scenarios, then one or more payee transactions can be defined for each payment transaction. More details of the Payee transactions can be found here.
GatewayFee 7
CardProcessingFee 8
CardTopUp 9
UnsuccessfulTransfer 10
WireTopUp 11
CashTopUp 12
Withdraw 13
UnsuccessfulWithdraw 14
RefundToWallet 15
UnsuccessfulRefundToCard 16
IssueFromCustody 17
WithdrawFee 18
RejectedWithdraw 19
RejectedWithdrawFee 20
BankTransferPayment 21
RefundToBankAccount 22
UnSuccessfulRefundToBankAccount 23
BankTransferPaymentFee 24
Commission 40
Donation 41
UnderReview 42
Release 43
Parking 100
AutomaticParking 101

1 Reserved transactions are in progress, they are not finalized, and can be changed in the future. These transactions' amounts can be changed at the time of the completion.