Push versus pull payments

Payments can be grouped into push and pull models, and the difference is who initiates the movement. In a push payment, the payer initiates the transfer and pushes money to the payee. A credit transfer, a standing order, and a real time payment are all push payments. The payer controls the timing and the amount, and once the payment is sent, the payer cannot easily recall it without the cooperation of the receiving bank. Push payments are therefore safer for the payee, because the money arrives only when the payer has chosen to send it, and they are the standard for most business to business payments. In a pull payment, the payee initiates the collection and pulls money from the payer account under a prior mandate or authorisation. A direct debit and a card recurring payment are pull payments. The payee controls the timing, within the terms of the mandate, and the payer relies on the mandate, on pre notification, and on refund rights to stay protected. Pull payments are efficient for recurring collections, but they create a different risk profile. A wrong amount, a duplicate collection, or a cancelled mandate can all cause a pull to fail or to be disputed, and the handling of those exceptions is a major part of direct debit operations. From a systems perspective, push and pull also change the message flow. A push payment starts with a customer instruction to the debtor agent, while a pull payment starts with a mandate and a collection instruction from the creditor agent. The screening, the validation, and the return and refund flows are all different. When you analyse a payment product, always identify whether it is push or pull, who holds the mandate or authorisation, what happens when funds are insufficient, and how a payer can stop or reverse the payment. Those answers shape the customer journey, the exception handling, and the regulatory disclosures. Take two payments from the same household. An employer pays a salary of Rs 85,000 by credit transfer on the last working day of the month. That is a push payment. The employer decides the timing and the amount, the money moves once, and the employee cannot pull it early. The same household pays its electricity bill of Rs 2,300 by direct debit. That is a pull payment. The electricity company collects the money under a mandate the customer signed, and the customer relies on advance notice and refund rights for protection. Now watch what goes wrong in each model. If the employer sends the salary twice by mistake, the recovery depends on the employee agreeing to return it, because a push payment cannot be pulled back unilaterally. If the electricity company collects Rs 2,300 twice in the same month, the customer claims a refund under the scheme rules and the duplicate collection is reversed, because a pull payment carries refund rights that a push payment does not. An analyst documents push and pull as two different products, not as one payment flow with a flag. The requirements for a pull product must cover the mandate, how it is set up, where it is stored, how the customer cancels it, and what happens to a collection that arrives after cancellation. They must cover pre notification: how many days before the collection the customer is told, and what the notice must say. And they must cover the return codes: insufficient funds, mandate cancelled, account closed, each with its own handling and customer message. The test pack should include a collection sent after the mandate was cancelled, a duplicate collection, and a collection for the wrong amount, because those three cases are where pull payments generate most of their complaints and scheme fines.