When you semi-integrate your POS system with Clover devices, merchants can conduct different types of customer transactions using these devices.
For instance, at full service restaurants, merchants can charge customers first for the bill amount and then for the tip amount even after the customer credit card has been charged. At retail stores, tips are not expected. At hotels, merchants can place a hold on a customer payment method (physical card or digital wallet) during check-in and then update the transaction with necessary charges during check-out.
To support the wide variety of merchant needs, Clover provides three types of transactions on semi-integrated Clover devices. Our SDKs reflect these distinctions with corresponding classes.
Payment response indicator
Each transaction class inherits from the
TransactionResponse parent classes.
The following sections explain the three transaction types in detail.
A sale is a customer transaction where the purchase amount is authorized and settled at the same time. While a tip amount can be added, it is permitted only before the transaction is authorized and settled.
If a sale is not voided within 25 minutes, the merchant funding process begins for this sale. At this point, the merchant can still refund the customer.
Typical businesses where sale transactions occur include:
- Quick service restaurants, where customers select a tip amount before completing the transaction with a payment
- Retail stores, where tips are not expected
Saletransaction may come back as a tip-adjustable
Auth, depending on the payment gateway. The
SaleResponseincludes boolean fields that indicate whether the transaction is final (
"isSale": true) or will be finalized during closeout (
An auth is a customer transaction where the purchase amount is authorized, and then can be tip adjusted even after the transaction is authorized. Tip adjustment can be made without requiring the customer's payment method (physical card or digital wallet) to interact with the Clover device for a second time.
The merchant funding process for the day begins at closeout when the auth or batch of auth transactions is settled. Before an auth is settled, there is no limit to the number of times a merchant can adjust the tip amount on a Clover device.
Typical businesses where auth transactions occur include full-service restaurants, where customers can use a credit card to authorize an initial value, and then add a tip amount to the receipt after the card has been charged.
It is important to note the following rules about tip adjustments:
- The most recent tip adjustment overrides all previous tip adjust amounts. Tip adjustments are not summed.
- Clover does not place a limit on tip adjustment amounts. However, if merchants tip adjust amounts more than 20% of the bill, funds are not guaranteed subject to the rules set by card schemes (such as Visa and Mastercard) and electronic payment associations.
Closeout is the process of finalizing a batch of auth transactions (including tips) or captured pre-auth transactions and then starting the merchant funding process.
During the boarding process, Clover merchants can be set up for automatic or manual closeout (depending on the merchant's region). If your POS supports manual closeout, the
CloverConnector#closeout method can be used to trigger the closeout process on the device. The
CloseoutRequest includes an
allowOpenTabs indicator of whether tabs without tips should be processed as part of the batch.
For more information about closeouts and time limits for submitting transactions, see best practices for closing out (click Reports and scroll to the Use the best practices section).
A pre-auth is a customer transaction where the merchant can validate that a given amount is available on the customer payment method (physical card or digital wallet), and then also place a hold for that amount. This amount is deducted from the customer account (credit limit or bank balance), but not yet transferred to the merchant.
Once the merchant captures a pre-auth amount, the transaction further continues as an auth transaction and is governed by the same auth transaction rules.
For the merchant to be funded, the pre-auth amounts must be captured before closeout.
Typical businesses where pre-auth transactions occur include:
- Hotels, where a hold is placed on a customer credit card during check-in and may be adjusted at checkout for incidental damages and in-room charges
- Car rental agencies, where a hold is placed on a customer credit card at vehicle hand-off and may be adjusted for incidental damages, late return of the vehicle, or failing to refuel
Merchants must capture pre-auth amounts to have funds transferred to their account. There are 2 important cases for capturing pre-auth amounts:
Capturing a part of the pre-auth amount: When merchants capture a part of the pre-auth amount, the remaining amount is credited back to the customer account. For instance, for a $300 pre-auth transaction, if a merchant captures $180, the remaining $120 is credited back to the customer account.
Capturing more than the pre-auth amount: When merchants capture a pre-auth amount that is greater than the original amount, funds are not guaranteed due to possible insufficient funds in the customer account. In addition, if merchants capture pre-auth amounts more than 20% of the original amount, funds are not guaranteed subject to the rules set by card schemes (such as Visa and MasterCard) and electronic payment associations.
Merchants can void a pre-auth transaction to release the funds held from a customer account.
Card networks limit the time during which a pre-auth can be captured. If a customer uses a debit card for a pre-auth transaction, the transaction may become invalid if it is not captured between one and eight business days (depending on the specific card network's policy). Specific merchants, such car rental agencies, should avoid accepting debit cards since the pre-auth hold can expire before the transaction is captured and settled.
If a customer uses a credit card, the transaction may be held for as long as thirty days (depending on the card network's policy).
A transaction request may return a partial authorization when the customer’s card has insufficient funds to complete the transaction. The POS must compare the request amount with the response amount to determine if a partial authorization occurred. If the amount in the payment response is less than requested, the POS must notify the merchant and then provide either or both of the following options:
- Accept the partial payment and start a second transaction to pay the remaining balance with a different card or other form of payment
- Void the original transaction and allow the customer to pay for the whole order with a different card or other form of payment
See How can I tell whether a Partial Auth has occurred? for sample code comparing the payment request/response amounts.
Updated about 1 year ago