# Capturing Sales There are two common flows used to capture sales: “Authorization and Capture” or “Straight Capture.” The capture method used depends on the merchant’s business model and/or your interface’s design. ## Authorization and Capture An Authorization and Capture flow is used when the final amount of the transaction is unknown at the time of authorization or when a merchant needs to guarantee funds before completing a transaction. Below are some common examples of Authorization and Capture scenarios: - A guest checks in to a hotel and the final amount of the bill is unknown because the length of stay may change and incidental charges may occur. When the guest checks out, the sale is captured for the final amount. - A consumer makes an e-commerce purchase for an item that has yet to be shipped. Due to industry regulations, the merchant will authorize the transaction amount to guarantee the funds for the purchase and then capture the sale when it’s prepared for shipment. - A consumer makes a purchase at a food and beverage establishment and the tip is unknown, so the merchant will authorize the check before requesting a tip and capturing the sale. There are two basic steps to an Authorization and Capture flow prior to settlement: - An [Authorization](/apis/payments-platform-rest/openapi/transactions/transactionsauthorization) request is sent to Shift4's Gateway to request a hold be placed on the cardholder’s funds. - When appropriate, a [Capture](/apis/payments-platform-rest/openapi/transactions/transactionscapture) request captures the transaction. This can happen one of two ways: Trickle Flow or Batch Flow: - In a Trickle Flow, each sale is captured by the interface on an individual basis after authorization, such as when an item is shipped, a rental car is returned, or a hotel guest checks out. - In a Batch Flow, the sales are captured in groups. This is usually done at the end of the business day or at shift changes. This is sometimes performed by a centralized auditing account or corporate location instead of the interface. Not every card type supports an Authorization and Capture flow. For example, debit authorizations are not supported for an Authorization and Capture flow because the funds are immediately captured. ## Straight Capture A Straight Capture flow is used when a merchant knows the final amount of the sale at the time of the request. Below are some common examples of Straight Capture scenarios: - A consumer makes a purchase at a retail location and leaves the store with their merchandise (e.g., a shoe store). - A consumer makes an e-commerce purchase, such as a software download, that is immediately fulfilled. - A consumer makes a purchase at a food and beverage establishment where a tip is known in advance, the PIN pad will prompt for a tip, or no tip isexpected (e.g., fast food). In a Straight Capture flow, a [Sale/Purchase](/apis/payments-platform-rest/openapi/transactions/transactionssale) immediately captures the transaction and gets approval for it. At the time of approval, the transaction is ready for settlement. ## Settlement Settlement is the last step to complete before a sale is finalized with the banks. When a merchant’s batch is closed, all of the captured transactions completed during the specified date range are sent to the processor. This triggers the movement of funds from the cardholders’ banks to the merchant’s bank account as well as the calculation of processing fees. There are three ways in which a batch can be closed. ### Lighthouse Transaction Manager A merchant's auditor can log in to [Lighthouse Transaction Manager](https://ltm.shift4test.com/) and view the transactions awaiting settlement. The auditor chooses a date range and then can perform any review process the merchant has requested. Once satisfied with the transactions' status, the auditor can close the batch. ### Automatic batch close by Shift4 A merchant can notify Shift4 staff which days/times they wish their batches to close automatically. Shift4's systems will close the batches at the specified times for that merchant. ### Programmatic batch close by an interface An interface can send the [Submit Batch](/apis/payments-platform-rest/openapi/batches/batchessubmit) request to initiate a batch close. # Use Cases for Capturing Sales The following use cases demonstrate capturing sales. For incremental authorizations, please see the Incremental Authorizations section under [Understanding Invoices](/guides/core-concepts/understanding-invoices) in this document. The use cases provided below are examples and do not replace the flows outlined in your Shift4 Integration Plan. By including [API Options](/guides/appendices/api-options) in a request, many of the flows illustrated below will be altered; for example, the ability to manually enter a card can be forced or restricted. To improve card data security, Shift4 strongly recommends that all merchants use a P2PE device for all card-present transactions. ## Use Case: Authorization ##### Actors: Consumer, Merchant ##### Preconditions: A merchant is ready to send an [Authorization](/apis/payments-platform-rest/openapi/transactions/transactionsauthorization) request for a transaction that will later be captured as a [Capture](/apis/payments-platform-rest/openapi/transactions/transactionscapture) request. ##### Main Flow: This flow illustrates an approval response. 1. The consumer’s card is captured or a previously stored card token is retrieved. 2. An [Authorization](/apis/payments-platform-rest/openapi/transactions/transactionsauthorization) is sent. 3. The request is sent to the processor. 4. A response indicating approval is returned. ##### Alternate Flow 1: This flow illustrates a decline response. (Main Flow; Step 4.) No further action is required. Shift4 automatically voids transactions that receive a 'D' response. ##### Alternate Flow 2: This flow illustrates a referral response. (Main Flow; Step 4.) Follow the steps in Use Case 6: Handling Voice Referrals. ##### Post Conditions: An approved authorization awaits settlement at the end of the day. ## Use Case: Authorization with a UTG-Controlled PIN Pad ##### Actors: Consumer, Merchant ##### Preconditions: A merchant is ready to process an [Authorization](/apis/payments-platform-rest/openapi/transactions/transactionsauthorization) request for a payment using a UTG-controlled PIN pad. The transaction will later be captured as a [Capture](/apis/payments-platform-rest/openapi/transactions/transactionscapture) request. ##### Main Flow: This flow illustrates an approval response. 1. An [Authorization](/apis/payments-platform-rest/openapi/transactions/transactionsauthorization) request is sent. 2. The PIN pad prompts the consumer to insert, swipe, tap, or key the card and walks the consumer through the steps to complete the transaction. 3. The request is sent to the processor. 4. A response indicating approval is returned. ##### Alternate Flow 1: This flow illustrates a decline response. (Main Flow; Step 4.) No further action is required. Shift4 automatically voids transactions that receive a 'D' response. ##### Alternate Flow 2: This flow illustrates a referral response. (Main Flow; Step 4.) Follow the steps in Use Case 6: Handling Voice Referrals. ##### Post Conditions: An approved authorization awaits settlement at the end of the day. ## Use Case: Capturing a Previous Authorization ##### Actors: Consumer, Merchant ##### Preconditions: A merchant is ready to capture a sale for apreviously authorized amount. ##### Main Flow: This flow illustrates an approval response. 1. A [Capture](/apis/payments-platform-rest/openapi/transactions/transactionscapture) is sent with the invoice number for the previously authorized amount. The previously stored card token is specified in the `card.token.value` field. 2. The invoice is updated in Shift4's Gateway. 3. A response indicating an approval is returned. ##### Post Conditions: An approved transaction awaits settlement. ## Use Case: Straight Capture ##### Actors: Consumer, Merchant ##### Preconditions: A merchant is ready to process a [Sale/Purchase](/apis/payments-platform-rest/openapi/transactions/transactionssale) request for a retail purchase, straight F&B purchase, or an e-commerce transaction that will be immediately fulfilled. ##### Main Flow: This flow illustrates an approval response. 1. The consumer’s card is swiped or keyed, or a previously stored card token is retrieved. 2. A [Sale/Purchase](/apis/payments-platform-rest/openapi/transactions/transactionssale) request is sent. 3. A response indicating approval is returned. ##### Alternate Flow 1: This flow illustrates a decline response. (Main Flow; Step 3.) No further action is required. Shift4 automatically voids transactions that receive a 'D' response. ##### Alternate Flow 2: This flow illustrates a referral response. (Main Flow; Step 3.) Follow the steps in Use Case: Handling Voice Referrals. ##### Post Conditions: An approved transaction awaits settlement. ## Use Case: Straight Capture with a UTG-Controlled PIN Pad ##### Actors: Consumer, Merchant ##### Preconditions: A merchant is ready to capture a straight sale. ##### Main Flow: This flow illustrates an approval response. 1. A [Sale/Purchase](/apis/payments-platform-rest/openapi/transactions/transactionssale) is sent. 2. The PIN pad prompts the consumer to insert, swipe, tap, or key the card and walks the consumer through the steps to complete the transaction. 3. The request is sent to the processor. 4. A response indicating an approval is returned. ##### Alternate Flow 1: This flow illustrates a decline response. (Main Flow; Step 4.) No further action is required. Shift4 automatically voids transactions that receive a 'D' response. ##### Alternate Flow 2: This flow illustrates a referral response. (Main Flow; Step 4.) Follow the steps in Use: Handling Voice Referrals. ##### Post Conditions: An approved transaction awaits settlement. ## Use Case: Voiding an Invoice ##### Actors: Interface, Shift4 ##### Preconditions: A merchant has an invoice that needs to be voided. ##### Main Flow: This flow illustrates voiding an entire invoice. 1. The interface sends a [Void](/apis/payments-platform-rest/openapi/transactions/void) request. 2. The entire invoice is voided in Shift4's Gateway. 3. A response is received with an HTTP status code equal to ‘200’. ##### Exception Flow: This flow illustrates an error response. (Main Flow; Step 3.) Follow the [Transaction Flow Diagram](/guides/response-handling/transaction-flow) to determine the proper resolution. ##### Post Conditions: The requested transaction has been successfully voided.