Push payment
What is push payment?
Push payment is a transfer the customer starts and authorizes from their own bank or wallet, sending funds directly to the merchant's account. Common examples include bank transfers, wire transfers, , and schemes.
The customer controls both the amount and the moment funds leave their account. Nothing is stored on the merchant side to charge later, which is what separates push payments from card and flows where the initiates the request.
Key facts
- Also known as: credit transfer
- Common rails: ACH, , wire, domestic real-time payment schemes, initiation
- Initiated by: the customer, from their banking app or online banking
- Authorization: given once per transfer, with no mandate or credential stored
- Chargeback rights: limited or none, and recourse depends on the rail and local rules
- Common use cases: high-value invoices, account top-ups, and marketplace flows, markets where bank transfer is a common checkout option
How it works
- Customer picks a push method. At checkout the customer selects bank transfer, a real-time payment scheme, or an open banking option instead of entering card details.
- Merchant supplies the payment details. The returns account details and a unique reference, or generates a payment request the customer's bank can read directly.
- Customer authenticates with their own bank. Authentication happens in the banking app or online banking, not on the merchant's checkout. In the EEA, applies at this step.
- Customer authorizes the transfer. They confirm the amount and the recipient. No credential is stored, so each transfer needs its own approval.
- The bank sends funds over the rail. The transfer clears through ACH, SEPA, a wire network, or a domestic real-time scheme, depending on the currency and country.
- The merchant reconciles the credit. The incoming amount is matched to the order using the reference, and goods or access are released once confirms.
How it compares
The direction of the instruction is what changes: in a push flow the customer's bank sends money out, and in a pull flow the merchant's side requests it against something already on file.
| Method | Who starts it | Standing authorization | Reversal route |
| Push payment | Customer, from their bank | None, authorized per transfer | Bank recall request, no |
| Merchant, against a stored credential | Yes, mandate or credential on file | Chargeback or | |
| Merchant, against a signed mandate | Yes, mandate | Return request under the scheme's rules | |
| Merchant, against card details | Yes, card on file for repeat charges | Chargeback |
applies the same initiate-and-send model to payouts, moving funds from a business to a cardholder's card instead of into a .
Why it matters
- No chargeback exposure. A completed transfer can't be pulled back through the card networks, which closes the route where a customer disputes an order they received.
- Cost sits on bank rails. Push transfers skip and card scheme fees, so pricing follows the bank's transfer fee rather than a percentage of order value.
- Settlement speed follows the rail. Domestic real-time schemes credit the merchant within seconds, while ACH and SEPA batch cycles take longer, so cash flow depends on which rail the customer used.
- Checkout friction costs conversion. The customer leaves checkout to approve the payment in their bank, and each extra step loses some of them. Customers who expect card-style buyer protection often switch back to a card.
- Reconciliation depends on the reference. An incoming credit doesn't carry the order metadata a card does, so relies on the reference travelling with the transfer. A missing or mistyped reference leaves the payment unmatched and the order unfulfilled.
