Transaction Types: Sales, Auths, Voids, and Refunds
Transaction Types: Sales, Auths, Voids, and Refunds
To capture or not to capture?
This blog serves as a guide for the different types of transactions or payment types, as well as the general payment flow. We’ll review five transaction types:
- Sale
- Auth
- Preauth
- Refunds
- Voids
To follow along, note that a TXN is the transaction number assigned to every transaction in the issuing bank online system. In addition to short definitions, we will provide use cases and responses from each payment type.
Understanding the payment flow
Payment flow varies on the medium being used. When you make a card-present payment, you are physically at a POS terminal to pay with a credit or debit card. Within seconds, the Clover server verifies against the cardholder’s bank if there are sufficient funds and the money is scheduled to transfer to the merchant’s bank.
Card-not-present (CNP) transactions take place online or through mobile, for example. CNP transactions use the Clover Ecomm APIs; a credit card is entered into a form, a call is made to the Clover server to tokenize the card, and the encrypted token is later decrypted by the tokenization service so that it can be transmitted through the payment gateway. You can find out more about Ecomm tokens in the Ecommerce Tokenization blog.
A transaction is typically submitted for clearing automatically, or optionally submitted for clearing following closeout. Clover categorizes purchase transactions as Sales, Auths, or Pre-Auths; and reversals as Voids or Refunds.
Let’s jump into the differences.
Auths
Clover auth transactions are used when the final transaction amount is known and there will be no need to adjust for tips or increments later. A single request message with the final amount is sent to the processing network and a response message is returned from the processing network approving the requested amount. The names of sale messages vary by context:
- Semi-integration SDKs: Sale request/response
- Clover payment objects: Auth request/response
- Rapid Connect (a payment gateway): Sale request/response
Transactions with capture set to true (default) are closed by the Clover Server automatically. Clover Auths are best understood as single-message transactions. The term auth is used to help abstract and simplify what’s happening in the payment gateway.
Use case: A retail or invoice-based business often has a fixed price that doesn’t require an adjustable amount for tips or later increments. An invoice could be sent through Clover Hosted Checkout.
Pre-Auths
Clover pre-auth reassures the merchant that the cardholder has the funds for the initial transaction amount, placing a hold against the cardholder’s account; the final amount is not submitted until Clover sends another call asking for the amount. These transactions rely on two separate calls: one to place a hold on (authorize) the customer’s card and another to clear the transaction (capture) for funding. It might be helpful to think of pre-auths as dual-message transactions.
In the US, card-present transactions are treated as pre-auths if the merchant is tip-on-paper capable.
A Clover pre-auth allows merchants to estimate a projected amount and receive authorization for that projected amount. The payment is processed when the merchant closes out all transactions made from credit/debit cards at the end of the work day.
When the payment total is finalized the reserved funds are captured. At this point, the state of the Payment will be CLOSED.
Use case 1: A restaurant will run a pre-auth for the amount of the meal without a tip. The cardholder then adds a tip to their receipt and signs. The restaurant will then provide the amount of the meal plus tip to Clover.
Use case 2: An e-commerce merchant takes a payment but ships the purchased product sometime later; they must do an Auth at the time of payment and complete it only after they have shipped. After this completion will the transaction be captured. In Clover terminology, the messages are called Pre-auth requests/responses and Completion request/responses (or sometimes Capture request/responses).
A note on gateway tipping
Some merchants in the US have tipping enabled at the payment gateway level. When gateway tipping is enabled, all transactions will be processed as pre-auths. In order for a merchant to allow tip-on-paper scenarios, they will need gateway tipping enabled. The following merchant category codes (MCCs) have gateway tipping enabled by default:
- 5810: Not currently in use
- 5811: Caterers
- 5812: Full Service Restaurants
- 5813: Bars
- 5814: Quick Service Restaurants
- 7230: Beauty Salons & Barber Shops
- 7298: Salons & Spas
Otherwise, the transaction could be a sale (Clover auth) or auth+capture (called a pre-auth), depending on the app or your API/SDK calls.
Voids vs. refunds: reversing a transaction
When canceling a transaction, everything depends on whether or not the money has actually been taken from the customer’s account.
Considering sale transactions, the Clover acquiring partner sweeps transactions every 25 minutes to progress the transactions to clearing in order to pay the merchant. Within 25 minutes, the merchant may Void the transaction if the customer changes their mind or wishes to add something else. After 25 minutes, a Refund request is necessary so the host can pass along the refund to negate the payment on the original transaction.
For pre-auths, a void can be issued any time before the merchant’s closeout period. After closeout, a refund request is necessary. The difference occurs because of the difference between Auths and Pre-auths. Pre-auths need to be flexible; if a merchant needs to enter a tip after the card has been swiped, they must do so before the money is moved. Since sale transactions are swept for clearing quickly, the opportunity for transaction reversal is much shorter.
A note on sale, auth, and pre-auth definitions
You may notice that all transactions, no matter whether they’d be considered an auth or pre-auth, have a delay between the transaction and closeout. Even though sales are considered simultaneous, there is always a delay between when the funds are pulled from the customer and when they are disbursed to the merchant. The key difference is that funds pulled via sale/auth are automatic while pre-auth require merchants to close out the transaction before they complete the transaction.
Below is a matrix for convenience of the type of transactions with their respective features.
Naked refunds
A naked refund (AKA manual refund) is a credit to a consumer’s card that is not linked to any previous purchase with that card. Naked refunds are supported by Clover as follows:
- US: supported; reversals not supported. A reversal in this context is defined as voiding a naked refund, or in other words canceling the refund.
- Canada: supported, including reversals of Interac naked refunds (coming soon).
- UK/Ireland: supported, except with international Maestro cards; no reversals; governed by an entitlement.
- Germany/Austria: supported, including reversals.
- Argentina: not supported.
To capture or not to capture? The answer depends on the transaction type. Capturing a payment at closeout or completion is the standard practice. Clover sale transactions are used for known amounts, while Clover Pre-Auth transactions require a later adjusted amount due to tips or increments. Payments can be voided or prevented up to closeout. Now you know the different Clover transaction types, check out our API reference to experiment.
