Home / Guides/ Handle Transactions
Transaction Lifecycle
Transaction Events have a predictable lifecycle and occur when a Payment Card is used by an Account Holder online or in-store. Understanding the lifecycle helps you answer questions from your Account Holders and design your user experience.
There are two types of transaction events you may receive: AUTHORIZATION with a separate CLEARING or AUTH AND CLEARING combined. Transaction events are sent to Highnote (the issuer) based on logic set by the merchant and the merchant’s processor.
Online transactions typically begin with a Verification Event as a means of preventing 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. The verification step confirms that the basic information about the Account Holder and the Card, 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 blocked for Card or Product
- Wrong zip code provided
Highnote provides a response code explaining why a Card’s verification was not approved.
AUTHORIZATION and AUTH AND CLEAR Transaction Events must be decisioned by Highnote (the issuer). Authorizations may be approved or declined.
The decision is based on a number of rules set by the Issuer and Processor, including:
- Balance on the Payment Card or Financial Account associated with the Payment Card
- MCC (Merchant Category Code) associated with the transaction
- Spend Control and Velocity limits set at the Card Product and/or Payment Card level
You can optionally participate in the Authorization flow using Collaborative Authorization.
Declines
When an Authorization is declined, the merchant will receive a Transaction Event Response Code that corresponds to a predefined list of reasons an Authorization may not be approved. These response codes are typically used by the merchant and displayed during the payment lifecycle.
Declines occur for several reasons such as:
- Insufficient funds in the Card’s Financial Account
- Incorrect PIN or CVV
- Expired Card
Highnote maintains a comprehensive list of response codes to assist in your communications with your Account Holders.
Special Types of Authorizations
| Type | Description |
|---|---|
| Partial Authorization | In the event that the original Authorization amount cannot be approved, Highnote will approve a partial amount and send this back to the merchant. |
| AFD (Automated Fuel Dispenser) transactions | Automated fuel dispensers (AFDs) streamline fuel purchases by allowing Account holders to operate the fuel pump and complete the payment process without fuel station personnel interaction. Typically these have an authorization amount defined by card brand rules and the authorization is removed once the Clearing is received. |
| $0 Authorization | Merchants may send an Authorization for a zero amount in order to validate card details. This authorization is typically experienced when a card is saved to for future payments or followed by another Authorization for the full amount of the purchase. |
Authorizations and Pending Funds
When an Authorization is approved, it acts as a hold for the amount authorized. You can see the authorization amount appear in an Authorization ledger and a decrease in Cash Available ledger.
Authorization have an expiration period set by the merchant or, if not included, set by the card brand rules. Typically most Authorizations expire after 7 days, but some Authorizations, like for hotel stays or car rentals, may be for a longer period of time. When an Authorization expires, the funds are automatically decreased on the Authorization ledger and increased on the Cash Available ledger.
When participating in the Authorization flow via Collaborative Authorization, Highnote immediately returns an IssuerPreliminaryAuthorizationEvent, or Pre-Authorization, to temporarily fund the requested Authorization while the system awaits your Collaborative Authorization response.
When making a payment, it’s possible that the original Authorization needs to be adjusted or is no longer valid. For instance, your Account Holder may have placed an order, however, 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 Authorization. A Reversal can undo the total amount of the Authorization and resubmit a new Authorization or could 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 Post and they are monitored by Highnote 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.
When a merchant needs to reverse a purchase, but a Clearing has already been sent, they do not have a way to update the original Authorization. In some cases, the merchant will send a new Authorization Event with the amount provided as a credit rather than a debit. Occasionally, merchants will send a Clearing with no authorization for the credit amount as well.