Payments are broadly categorized into push payments and pull payments. When a payer initiates a payment to a specific recipient by debiting his own account and crediting the account of the recipient, that is a push payment. When the recipient invokes a contract (usually a payment instruction or mandate) to debit the payers account and credit his own account that is a pull payment.
Push payments and pull payments serve a specific purpose. A push payment is made each time by the payer at his discretion. It is usually preferred when there is no prior commitment to pay. Peer to peer payments, payments at the merchant’s counter towards a one-time purchase are usually made through push payments. E.g. Real time payments, IMPS in India, Venmo in USA, RTGS payments.
Loan repayments, which are based on prior commitment to pay for a fixed tenure at a fixed frequency are usually made through pull payment. In pull payment, the recipient has a better control over the payment as the payer agrees to a specific term and the recipient invokes this agreed term to automatically debit the payers account. E.g. ACH payments. Both these types are commonly in use and as you can see, serve a specific purpose.
It is important to note here that in Push type payment; the recipient has no means in the payments workflow to either ask for or force the payment by the payer. Whereas, in pull payment, the recipient has all the rights to do so.
Request to Pay is an interesting category of payment which sits in between. In this category of payment, the recipient can send an official request through the payment channel to a specific payer to pay a specific amount and usually towards a specific purpose. The payer, when he receives this request has a few options. She can accept the request and respond with a payment (push payment), refuse to pay, ask for more details or in some cases even ask for an option to make part payments.
Why is Request to Pay even necessary? To answer this question, we need take a slightly deeper look at the push payment and pull payment. Push payment is usually one-time payment and it is done at that very instant.
Imagine a scenario where payment upon delivery is an option chosen by the customer. Here the person delivering the product or service must officially request for payment at the door step of the customer. This request must be recorded and the customer’s response needs to be recorded too. A pure push payment cannot achieve this. Nor can a pull payment achieve this as the mandate to pay cannot be set up to trigger against an event (which in this case is physical delivery of the purchase). The Request to Pay option is ideally suited for such a scenario.
The payment flow in this scenario can be as follows.
The customer has the option to refuse to pay citing pre-configured reasons such as “item is damaged”, “not the item ordered”, “difference in price” etc. The merchant gets the specific response in an official channel which they can use to handle the transaction as appropriate.
In many countries cash payment is made upon delivery. The cost of handling cash and the risk of such payment has been enormous. The request to pay option can be very useful to remove cash from the equation in such scenarios and save a lot of cash handling cost and security risks.
In a few economies, payment on delivery is not so prevalent as the cost associated makes the option unfeasible. This has led to lost business. Request to Pay option can open up business streams where payment on delivery is preferred.
Besides, the ability of the payer to negotiate part payments or split payments also allows 3rd party liquidity providers to influence such transactions by converting such one-time payments into liquidity credit options with convenient repayments.
As it is quite imaginable, the Request to Pay option is a crucial best of both the world option which empowers the merchant and the customer with vital information and options which gives them enormous flexibility.