Payment Methods & Rails

Push Payments

What Are Push Payments? Definition and How They Work

Definition

A push payment is a transaction initiated by the payer, who instructs their own bank or payment provider to send funds to a recipient. The payer pushes money out of their account. This contrasts with a pull payment, where the payee (merchant or creditor) initiates the transaction and pulls funds from the payer's account. The distinction affects fraud dynamics, dispute rights, settlement speed, and the liability framework that governs each transaction type.

How it works

In a push payment, the payer's institution is the transaction originator. The payer authenticates with their bank, specifies the recipient's details and the amount, and their bank transmits a credit transfer instruction to the payment system. The funds leave the payer's account and arrive in the recipient's account. The payer has full visibility and explicit control over each payment: nothing leaves their account without their direct instruction.

Common push payment types include: bank credit transfers (wire transfers, ACH credits, SEPA Credit Transfers, Faster Payments, FedNow); account-to-account open banking payments initiated by a PISP on the payer's instruction; and cryptocurrency transactions where the sender broadcasts a transfer from their wallet. In all cases, the payer is the active party: they initiate the movement of funds.

Pull payments work in reverse: the payee (or a party acting on the payee's behalf) initiates the transaction and requests funds from the payer's account. The payer provides authorisation in advance (a mandate, a stored card credential) but does not actively initiate each individual payment. Pull payment types include: direct debits (the creditor pulls from the debtor's bank account under a standing mandate); card payments at a merchant checkout (the merchant's acquirer pulls the authorised amount from the cardholder's account); and subscription billing using stored card credentials (the merchant initiates a charge against the stored card without the cardholder taking action).

The practical difference at the moment of payment: in a push payment, the payer must be present and active (or have pre-authorised a rule-based push such as a standing order); in a pull payment, the payee initiates and the payer need not be present.

Why it matters

The push versus pull distinction matters because it governs who bears fraud risk, what dispute rights apply, and how quickly settlement is final. Push payments are irrevocable once settled on most instant payment rails: the payer has explicitly instructed the payment, the funds have moved, and there is no chargeback mechanism equivalent to card networks. This makes push payments more susceptible to APP fraud (where the payer is socially engineered into pushing money to a fraudster) but immune to the card fraud chargebacks that cost merchants billions annually.

For merchants, accepting push payments (Pay by Bank, bank transfers) eliminates chargeback risk for the transaction type. A buyer cannot dispute a push payment under the card scheme chargeback framework because no card network is involved. This is a significant advantage for merchants in high-chargeback categories or those selling non-returnable digital goods.

The regulatory treatment of push and pull payments reflects this difference. PSD2's SCA requirements apply differently to push and pull contexts: push payment initiation through a PISP requires SCA from the payer; pull payments under merchant-initiated transaction frameworks have SCA exemptions because the merchant is initiating rather than the cardholder.

With PXP

PXP supports merchants and partners across the payments value chain. To talk through push and account-to-account payments as part of your payment strategy, get in touch with our team.

Talk to a payments specialist

Frequently asked questions

Are card payments push or pull payments?

Card payments at a merchant checkout are technically pull payments: the merchant's acquirer, acting on the cardholder's authorisation at checkout, pulls the transaction amount from the cardholder's account through the card network and issuing bank. The cardholder provides authorisation (by presenting their card and completing authentication) but the merchant initiates the actual fund movement. This pull structure is why card chargebacks exist: the cardholder can dispute a pull that they believe was unauthorised.

What is the main fraud risk in push payments?

Authorised Push Payment (APP) fraud is the primary risk: a fraudster tricks the payer into deliberately initiating a push payment to the fraudster's account. Because the payer authorised the payment, it cannot be disputed under an 'unauthorised transaction' framework. The payment is genuine from the bank's perspective (correctly authenticated, correct credentials) even though the payer was deceived into making it. Traditional fraud controls that detect unauthorised use of credentials are ineffective against APP fraud because the credentials are used legitimately.

Why are push payments often faster than pull payments?

Push payments on modern real-time payment rails (Faster Payments, FedNow, SEPA Instant) settle in seconds because each payment is processed individually and immediately (real-time gross settlement). Pull payments through card networks follow a batch clearing and net settlement process: authorisation is instant but final settlement of funds to the merchant occurs T+1 to T+2 after capture. Direct debits are even slower: collected under advance notice windows with batch settlement cycles. The architectural difference (real-time individual settlement vs. batch netting) explains the speed difference.