Transaction Lifecycle

Transaction Events occur when a Payment Card is used by an Account Holder online or in-store. These events are sent to Highnote based on logic set by the merchant and the merchant’s processor. Understanding the Transaction Event lifecycle helps you answer Account Holder questions and design your user experience.

The most common Transaction Events include the following:

• VERIFICATION
• AUTHORIZATION with a separate CLEARING
• AUTH AND CLEARING combined
• REVERSAL
• CLEARING
• REFUND

See the TransactionEvent API Reference for a complete list of possible Transaction Events.

Online transactions typically begin with a Verification Event to prevent fraud. When your Account Holder adds their Card to a digital wallet or saves it as a payment method online, the merchant will request Highnote to verify that the Card is active and accurate. Verification confirms that basic Account Holder and Card information, such as name, address, and CVV, match the expected values.

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

• Incorrect name/address provided
• Merchant Category Code (MCC) blocked for Card or Product
• Wrong zip code provided

Highnote provides a Response Code explaining why a Payment Card’s verification was not approved.

AUTHORIZATION and AUTH AND CLEAR Transaction Events must be decisioned by Highnote. Authorizations may be approved or declined based on a number of factors.

When a transaction is approved, Highnote typically returns an APPROVED response code for the full amount of the transaction. Transactions can also be approved for partial amounts or special types of authorizations. For a full list of Response Codes, see the TransactionEventResponseCode API Reference.

You can participate in the Authorization flow using Collaborative Authorization. Collaborative Authorization allows you to approve or decline the transaction before it reaches Highnote for decisioning.

When an Authorization is declined, the merchant will receive a Response Code for the decline reason. These response codes are typically used by the merchant and displayed during the payment lifecycle.

Declines occur for several reasons, including but not limited to:

• Insufficient funds in the Payment Card’s Financial Account
• Incorrect PIN or CVV
• Expired Payment Card

For a full list of Response Codes, see the TransactionEventResponseCode API Reference.

In some scenarios, special types of Authorizations may take place. The following table provides examples of special Authorization types:

When an Authorization is approved, it acts as a hold for the authorized amount. You can view Authorization amounts in two places within Highnote's Dashboard:

• Added in an Account Holder’s Authorization ledger
• Decrease in the Account Holder’s Cash Available ledger

Authorizations have an expiration period set by the merchant or by the card brand rules. Most Authorizations expire after 7 days. Some Authorizations, like hotel stays or car rentals, may have longer expiration periods. When an Authorization expires, the funds are automatically decreased on the Authorization ledger and increased on the Cash Available ledger.

If you participate in Authorization via Collaborative Authorization, Highnote responds to a Transaction Event with a Pre-Authorization to temporarily fund the requested Authorization until your Collaborative Authorization response is received.

When making a payment, the original Authorization may need to be adjusted or is no longer valid. For instance, your Account Holder may have placed an order, but one of the items is not in stock, and the original Authorization needs to be reduced.

In these instances, a merchant can use a REVERSAL to undo the total amount of the Authorization and resubmit a new Authorization. A Reversal can also reduce a partial amount for the original Authorization.

Highnote does not have control over how this is implemented, and the decisioning is driven by rules set by the merchant. This decisioning often varies across merchants.

Once a merchant has confirmed the full purchase amount, an event is sent to Highnote to clear the Authorization. These Transaction Events are type CLEARING, however, an AUTH AND CLEAR has the same impact on the funds in a Financial Account.

Most Clearings are associated with an Authorization, and you can view the association for a given Transaction Event to other related Transaction Events. There are instances where a Clearing is received without an Authorization, for instance when the issuer does not respond to the network. These are typically called a Forced Posts, and Highnote monitors them to ensure fraud is not occurring.

Once a Clearing is received, the Authorization Ledger is updated, and the Cash ledger is decreased. This funds movement represents the outgoing funds to the merchant.

Refunds are made 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 amount provided as a credit
• The merchant sends a CLEARING event with no authorization for the amount to be refunded as a credit
• The merchant sends an AUTH AND CLEAR event for the amount to be refunded as a credit