Pull Payment

What Is a Pull Payment?

A pull payment is a payment model in which the recipient of funds (the payee) initiates a transaction to withdraw money from the sender's (the payer's) account. The payer provides authorization in advance, granting the payee permission to "pull" funds at agreed-upon times and amounts. This stands in contrast to a push payment, where the payer actively sends money to the recipient.

Pull payments are the dominant model in traditional consumer finance. When you hand your credit card to a merchant, you are authorizing them to pull funds from your account. When a streaming service charges your card each month, it is executing a pull payment against your stored credentials. The entire subscription economy, from SaaS platforms to gym memberships, runs on pull payments.

The model traces back to check-based payments and evolved through direct debit systems, ACH transfers, and credit card networks. Today, pull payments process trillions of dollars annually across card networks like Visa and Mastercard, SEPA Direct Debit in Europe, and ACH in the United States.

How It Works

A pull payment follows a general pattern regardless of the specific payment rail being used:

1. The payer provides authorization to the payee, sharing account credentials such as a card number, bank routing and account numbers, or a direct debit mandate
2. The payee stores these credentials securely (or with a payment processor) for future use
3. When a payment is due, the payee submits a payment instruction to their financial institution or payment processor, specifying the amount and the payer's account details
4. The financial institution routes the request through the appropriate network (card network, ACH, SEPA) to the payer's bank
5. The payer's bank verifies the account has sufficient funds and processes the debit
6. Funds are transferred from the payer's account to the payee, typically after a settlement period

Merchant-Initiated Transactions

Card networks distinguish between customer-initiated transactions (CITs) and merchant-initiated transactions (MITs). Both are pull payments, but MITs are processed without the cardholder being present. Once a customer approves an initial transaction, future MITs are linked to that prior authorization.

MITs typically do not require real-time authentication, which makes them convenient for recurring billing. However, merchants must document and store the customer's prior authentication to avoid declined transactions. Common MIT scenarios include subscription renewals, installment payments, no-show fees, and delayed charges like post-ride tips.

Authorization and Mandates

The legal framework for pull payments varies by rail. Credit card payments rely on cardholder agreements and PCI-DSS compliance for credential storage. Direct debit systems like SEPA and ACH use formal mandates: signed documents authorizing the payee to debit the payer's account. These mandates specify the parties, amounts (or ranges), and frequency.

Without valid authorization, a pull payment is considered unauthorized, and the payer can reverse it through their bank. This reversal mechanism is central to consumer protection in pull payment systems but creates significant risk for merchants.

Common Examples

Credit and Debit Card Payments

Every card transaction at a point of sale or online checkout is a pull payment. The merchant submits the transaction to their acquirer, which routes it through the card network to the issuing bank. The issuing bank debits the cardholder's account or credit line.

Direct Debit and ACH

Direct debit is a bank-to-bank pull payment where the payee instructs their bank to collect funds from the payer's bank account. In the US, this happens over the ACH network. In Europe, SEPA Direct Debit serves the same function. These are commonly used for utility bills, rent, insurance premiums, and loan repayments.

Subscription and Recurring Billing

Subscription services store customer payment credentials and charge them on a schedule: monthly, annually, or at custom intervals. The customer authorizes the initial charge, and the merchant pulls subsequent payments automatically. This model powers streaming services, SaaS platforms, membership programs, and buy-now-pay-later installment plans.

Risks and Considerations

Chargeback Exposure

Because the merchant initiates pull payments, customers can dispute charges they don't recognize or no longer want. These disputes result in chargebacks: forced reversals where the merchant loses both the payment and incurs a fee. Subscription businesses face elevated chargeback rates because customers may forget about recurring charges, struggle to cancel, or simply not recognize the billing descriptor on their statement.

Excessive chargebacks can trigger severe consequences. Card networks may place merchants on monitoring programs, increase processing fees, or terminate their ability to accept card payments entirely. The chargeback system exists to protect consumers, but it creates an asymmetric risk for merchants operating pull payment models.

Fraud and Unauthorized Charges

Pull payments require the payer to share sensitive credentials: card numbers, bank account details, or authorization mandates. If these credentials are compromised through a data breach, attackers can initiate unauthorized pull payments. The 2013 Target breach, for example, exposed 40 million card numbers precisely because pull payment systems require merchants to handle sensitive payer data.

"Friendly fraud" is another significant risk. This occurs when a legitimate customer authorizes a charge, receives the goods or service, and then disputes the transaction anyway. In subscription billing, friendly fraud is often driven by forgetfulness rather than malicious intent, but the financial impact on merchants is the same.

Failed Payments

Pull payments can fail if the payer has insufficient funds, if the card is expired or cancelled, or if the bank rejects the transaction. For subscription businesses, failed recurring payments create involuntary churn: customers who intended to stay but whose payments silently fail. Managing payment retries, dunning communications, and card-on-file updates adds operational complexity.

Pull Payments vs. Push Payments

The fundamental difference between pull and push payments is who initiates the transaction. In a pull payment, the payee initiates. In a push payment, the payer initiates. This distinction has profound implications for security, trust, and payment design.

Real-time payment systems like RTP, FedNow, and Faster Payments are primarily push-based, representing a shift in traditional finance toward the push model. Open Banking initiatives are also blurring the line by enabling "request to pay" flows where the payee requests funds but the payer must explicitly approve each transaction.

Why Bitcoin Uses Push Payments Instead

Bitcoin is a pure push payment system. Only the holder of a private key can sign a transaction to move funds from their wallet. There is no mechanism for a merchant to "pull" Bitcoin from a customer's wallet without the customer creating and signing each transaction. This property is mathematically enforced by the protocol and has no exceptions.

This design eliminates entire categories of fraud that plague pull payment systems. A data breach at a Bitcoin merchant cannot expose credentials that allow unauthorized withdrawals, because no such credentials exist. There are no chargebacks, no unauthorized recurring charges, and no need for the complex dispute resolution infrastructure that card networks maintain.

However, Bitcoin's push-only model creates a genuine limitation: native recurring payments are impractical. A subscription service cannot automatically debit a customer's Bitcoin wallet each month. The customer must actively sign and broadcast every payment. Solutions at the application layer, such as custodial accounts and Lightning-based automation using protocols like LNURL-Pay, are being developed to bridge this gap while preserving the security benefits of the push model.

Layer 2 solutions like Spark inherit Bitcoin's push payment architecture. Transactions on Spark require the sender to initiate and authorize each transfer, maintaining self-custody guarantees. For businesses that need recurring billing, this means integrating payment request workflows rather than storing and charging customer credentials: a fundamentally different (and arguably more secure) approach to subscription commerce.

Why It Matters

Understanding the pull payment model is essential for anyone building or evaluating payment systems. Pull payments remain the backbone of consumer commerce: they power subscriptions, enable frictionless repeat purchases, and provide the consumer protection mechanisms (like chargebacks) that shoppers expect. The economics of card networks are built around facilitating and managing pull payment risk.

At the same time, the limitations of pull payments: credential exposure, fraud, chargebacks, and the overhead of dispute resolution: are driving innovation toward push-based alternatives. Real-time payment networks, Open Banking APIs, and cryptocurrency systems all represent a movement toward giving payers more control. As the merchant payments landscape evolves, the most effective payment strategies will likely combine both models: pull payments for convenience where trust is established, and push payments for security where it matters most.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.