What Happens After the Customer Leaves

Once the customer has left, the merchant's work is not finished. The authorised transaction sits in the merchant's terminal or system as an open item, waiting to be captured. Capture, sometimes called batching, is the process where the merchant confirms that the goods or services were actually provided and submits the transaction for clearing. In a shop, this usually happens automatically at the end of the day, when the terminal sends a batch of all the day's authorised transactions to the acquirer. Online, capture may happen when the goods are shipped, which could be hours or days after the authorisation. The gap between authorisation and capture is important for several reasons. The final amount may differ from the authorised amount, for example if a restaurant adds a tip, or if a hotel adjusts the bill. The merchant may decide not to capture a transaction at all, for example if an order is cancelled before shipping, in which case the authorisation hold is released and the customer sees the funds become available again. The acquirer and the scheme set rules for how long an authorisation remains valid, typically seven days for most purchases and longer for hotels and car rentals, after which it expires and must be reauthorised. For a business analyst, the authorisation to capture gap is a source of many edge cases. What happens if the card expires between authorisation and capture. What happens if the customer disputes the transaction before it is captured. How should the system handle a partial capture, where only part of the authorised amount is taken. Each scheme has detailed rules for these cases, and the acquirer and issuer systems must implement them consistently. Getting them wrong leads to failed clearings, customer complaints and unnecessary chargebacks. Take a hotel stay and an online order. A guest checks in and the hotel authorises Rs 15,000 against the card. At check out the bill is Rs 18,400, because room service was added, so the hotel captures Rs 18,400, which is more than the authorised amount. Most schemes allow a capture above the authorisation within a tolerance, but the hotel must be able to justify the difference if the cardholder disputes it. Now take an online order for Rs 5,000. The customer authorises at checkout on Monday, then cancels on Tuesday before the goods are shipped. The merchant never captures, the authorisation hold is released, and the Rs 5,000 becomes available to the customer again, usually within seven days. The edge case that catches merchants out is expiry. A transaction is authorised on 28 March, the card expires on 31 March, and the merchant tries to capture on 2 April. The capture fails, because the card is no longer valid, and the merchant must contact the customer and reauthorise on the new card, or lose the sale. For a business analyst, the authorisation to capture gap is a list of test cases waiting to be written. Capture below the authorised amount, capture above it, partial capture where only part of the order ships, capture after the authorisation has expired, and capture after the card has expired. Each case should state the expected system behaviour, the customer communication, and the scheme rule it follows, because the acquirer and the issuer must implement the same rule or the clearing will fail. The requirements should also state the capture window for each merchant type, since a hotel may hold an authorisation for 30 days while a grocery store captures the same day, and a single window for all merchants will be wrong for both.