What are “push” payments?
Push payments are those in which the paying party’s DFSP first enters the payment order into the payment platform. The receiving party’s DFSP then receives the payment order and credits the payee’s account. Wire transfers and ACH payroll transactions are examples of push payments.
Push payments contrast with pull payments. In pull payments, the receiving party’s DFSP enters the payment order into the payment platform, and then the paying party’s DFSP receives the payment order and debits the payer’s account. Checks, debit cards, and direct debit transactions are examples of pull payments.
Push payments are superior to pull payments for risk control issues of many kinds. A push transaction can’t bounce and doesn’t need an authorization message; the DFSP who knows the payer’s account balance is sending the payment instruction. Push address credentials, if stolen, can’t be used to fraudulently “pull” money out of a consumer’s account. For these reasons, Level One supports a “push-payments-only” design.
Are “pull” payments necessary to support merchant and biller payments?
No. The functionality of pull payments, in which the receiver of funds wants to “ask” for the payment, can be fulfilled using “request-to-pay” messaging. This request message is not a financial transaction; the payment transaction is sent to the switch by the consumer’s DFSP so that the risk benefits of push payments are maintained.
Legacy systems developed pull payments because the technology at the time did not permit real-time push payments. Today, enabling technology is in the hands of every user. A Level One platform can handle multiple use cases. There is no reason for modern payments systems to support these higher-risk, higher-cost transaction types.
Confusion Alert: In some new systems, request-to-pay messaging is referred to as “pull.” The important distinction is which DFSP—the paying or receiving party—is entering the transaction into the system.
Next Topic in this Section: Transaction Irrevocability