A transaction is an electronic message sent when a cardholder tries to pay online or in a store. These electronic messages are sent to Highnote based on logic set by merchants and networks. When Highnote receives these messages, the platform interprets them using transaction event objects. This guide explains how transaction events are displayed on the Highnote dashboard.

Transaction events

Highnote interprets transaction messages from the network as transaction events. The Highnote dashboard displays the following transaction event types: 

Transactions appear throughout the Highnote dashboard as debits or credits. This indicates the direction of funds movement: 

• Debit: Funds are moving out of a Highnote financial account.
• Credit: Funds are moving into a Highnote financial account.

View transactions

The Transactions page of the dashboard displays all transactions for your card product. This includes transactions across all account holders, financial accounts, and payment cards. Click any transaction on this page to review its details and a timeline of related events: 

Verifications

A verification event usually occurs when a cardholder stores a payment method or initiates an online transaction. When either action occurs, the merchant requests Highnote to verify that the payment card is active and accurate. Verification confirms that the account holder and card information match the expected values. 

The Highnote dashboard's transaction detail page shows the verification event value and which verifications passed or failed: 

Verifications may decline for several reasons. Examples include, but are not limited to:

• Incorrect name or address provided
• The payment card or card product has blocked the Merchant Category Code (MCC)
• The wrong zip code was provided

Authorizations

Authorization transaction events are approved or declined by Highnote based on several factors, including but not limited to:

• Bank and Highnote risk, compliance, and regulation policies
• Authorization controls, such as spend rules or velocity controls

Authorizations may reflect different requested and approved amounts. When an authorization is approved, the amount reflected on the Highnote ledger is the approved amount. These amounts are defined as follows: 

• Requested amount: The amount of funds requested from the network for the transaction.
• Approved amount: The amount of funds approved and posted to the Highnote ledger for the transaction. 

Approvals

Approved authorizations act as a hold for the authorized amount for the transaction. 

Authorizations have an expiration period set by the merchant or your card product rules. Typically, authorizations expire after seven days. Some authorizations, like hotel stays or car rentals, may have more extended expiration periods. When an authorization expires, the funds are automatically reflected in the available cash ledger.

If you use collaborative authorization for your card product, Highnote responds to a transaction with a pre-authorization. This pre-authorization temporarily funds the authorization requested until your collaborative authorization response is received. For more information on collaborative authorization, see Collaborative authorization.

Declines

If an authorization is declined, Highnote displays the decline reason on the transaction details page. For a full list of decline reasons, see the Transaction Event Response Code reference. 

Reversal

Sometimes, a transaction needs adjusting or is no longer valid. For example, if an account holder places an order, but one of the items is not in stock, the original authorization needs to be reduced. In this scenario, a merchant uses a reversal to undo the total amount of the original authorization and submits a new authorization.

Highnote does not have control over how reversals are implemented. Reversal decisioning is driven by rules set by the merchant and often varies across merchants. In some cases, reversals are done on cleared transactions. In these scenarios, we recommend handling these reversals as refunds. 

Clearing

Once a merchant has confirmed the full purchase amount, an event is sent to Highnote to clear the authorization. In the dashboard, these events are called clearing events. Clearing events take place in one of two ways:

• An authorization, followed by a separate clearing event
• An authorization and clearing event executed at the same time, also known as an authorization and clear event

There are exceptions when a clearing event is received without authorization, for example, when the issuer doesn't respond to the network. These vents are typically called forced posts, and Highnote monitors them to ensure fraud does not occur. 

Once a clearing event is received, the authorization ledger is updated, and the cash ledger reflects the reduction of funds. The reduction of funds from the cash ledger represents the outgoing funds to the merchant. 

Refunds

Refunds are issued when a merchant needs to reverse a purchase but a transaction has already cleared. Refunds are typically sent in the following ways: 

• The merchant sends a new authorization event with the refund provided as a credit
• The merchant sends a clearing event with no authorization with the refund provided as a credit
• The merchant sends an authorization and clear event with the refund provided as a credit

The Highnote ledger records a refund as the transaction type sent by the merchant. For example, if Highnote receives a refund as a clearing event, the financial account's ledger will reflect a "Clearing" transaction for the refund. 

Pre-authorizations

The Highnote dashboard uses pre-authorization events to represent collaborative authorization preliminary authorizations. Collaborative authorization allows you to approve or decline transactions in real-time based on your business logic. 

Timeline of a pre-authorization event and its associated authorization event are displayed on the transaction detail page: