Home / Issuing / Handle Transactions
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:
AUTHORIZATION with a separate
AUTH AND CLEARING combined
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:
Highnote provides a Response Code explaining why a Payment Card’s verification was not approved.
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:
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:
|In the event that the original Authorization amount cannot be approved, Highnote will approve a partial amount and send this back to the merchant.
|Automated Fuel Dispenser (AFD) transactions
|Automated fuel dispensers (AFDs) typically have an authorization amount defined by card brand rules and the authorization is removed once the
CLEARING response is received.
|Merchants may send an Authorization for a zero dollar amount to validate card details. This Authorization typically happens when a card is saved for future payments. It can also be by another Authorization for the full amount of the purchase.
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:
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:
CLEARING event with no authorization for the amount to be refunded as a credit
AUTH AND CLEAR event for the amount to be refunded as a credit