How Pull Payment Works
A pull payment follows a defined authorization-then-collection flow. The payer acts once — at the start of the relationship — and the payee controls every subsequent transaction. This inversion of control is what separates pull payments from every other payment model and what makes them structurally suited to recurring billing.
Payer Grants Authorization
The customer provides explicit consent via a signed direct debit mandate, a stored card agreement, or an open banking authorization. This consent document defines the scope: maximum amount, frequency, and expiry date. Without it, no pull can legally proceed.
Payee Submits the Debit Instruction
The merchant or billing platform transmits a debit instruction to their bank or payment processor, referencing the stored authorization ID. The customer is not notified at this stage in most rails — notification obligations are handled at the pre-notification step before submission.
Funds Clear Through the Network
The instruction travels through the relevant payment rail — ACH debit, SEPA Direct Debit, BACS, or a card network. Settlement timelines range from instant (card networks, RTP) to two to three business days (standard ACH and SEPA).
Reconciliation and Exception Handling
Once funds settle the payee reconciles against billing records. Failed pulls return a processor reason code, triggering retry logic or dunning workflows. Both parties typically receive transaction notifications, and any R-codes or return messages are routed to the billing engine for action.
Why Pull Payment Matters
Pull payments underpin a substantial share of global transaction volume, and their structural advantages — no per-transaction customer action, predictable collection windows, and automated retry — become more valuable as subscription and usage-based revenue models scale. The economics of running a recurring billing operation without pull payments are prohibitive.
Nacha reported 8.8 billion ACH debit transfers in 2023, representing over $27.7 trillion in value — the majority of that volume is payee-initiated pull activity. In Europe, SEPA Direct Debit processed more than 5 billion transactions in 2023 according to European Central Bank statistics, covering utilities, SaaS, insurance, and consumer lending across 36 countries. The global subscription economy, almost entirely powered by pull payments, is projected to exceed $1.5 trillion in annual revenue by 2025 based on UBS estimates. These numbers reflect a payments infrastructure that is not niche — it is load-bearing for modern commerce.
For ecommerce operators, the operational case is equally clear. Merchants who implement intelligent retry logic on failed push payment-converted-to-pull flows recover an average of 15–25% of initially declined transactions. That recovery rate is structurally unavailable in models where the customer must actively re-initiate each payment.
Why banks favor pull payment infrastructure
Pull-based instruments allow banks and processors to pre-schedule settlement windows and model liquidity needs in advance. Unlike on-demand push transactions, pulls arrive in predictable batches — reducing real-time liquidity pressure and enabling more efficient clearing operations.
Pull Payment vs. Push Payment
The core distinction between pull and push payment is which party controls initiation. This single design decision cascades into how you handle authorization, failure recovery, customer communication, and chargeback exposure. Getting the choice wrong at the architecture stage is expensive to undo.
| Dimension | Pull Payment | Push Payment |
|---|---|---|
| Initiator | Payee (merchant/biller) | Payer (customer) |
| Customer action per transaction | None (after initial authorization) | Required every time |
| Authorization requirement | Mandate or stored credential required upfront | No pre-authorization needed |
| Common examples | Direct debit, ACH pull, card-on-file | Wire transfer, bank transfer, digital wallet send |
| Failure recovery | Retry logic controlled by payee | Customer must re-initiate manually |
| Dispute/chargeback risk | Moderate — consumer refund rights apply | Lower — payer-initiated reduces disputes |
| Settlement speed | 1–3 days (ACH/SEPA), instant (card/RTP) | Varies widely by rail and geography |
| Best use case | Subscriptions, utilities, installments, SaaS | One-off purchases, B2B invoice payments |
Types of Pull Payment
Pull payments are not a single instrument. They exist across multiple payment rails with different settlement speeds, geographic reach, consumer protection rules, and risk profiles. Choosing the wrong rail for your use case creates compliance gaps, higher failure rates, or unnecessary processing costs.
ACH Debit (United States): The dominant pull mechanism in the US market. Standard ACH settles in one to two business days; Same Day ACH settles within hours. Governed by Nacha Operating Rules, which require revocable written authorization from the payer and advance notice before the first debit.
SEPA Direct Debit (Eurozone and beyond): Two distinct variants. SEPA Core targets consumers and carries an eight-week unconditional chargeback window. SEPA B2B targets businesses, has no chargeback right, and requires pre-validation of the debtor's bank details. Available across 36 countries.
BACS Direct Debit (United Kingdom): A three-day settlement cycle rail for recurring UK payments. Protected by the Direct Debit Guarantee, which gives payers an unconditional and immediate refund right on any erroneous or unauthorized pull.
Card-on-File Pulls: Merchants store tokenized card credentials and charge them on a defined schedule. This is technically a pull payment operating over Visa and Mastercard rails, with the merchant as the initiator. Governed by stored credential frameworks under card network rules.
Variable Recurring Payments (Open Banking): An emerging rail in the UK under Open Banking and in the EU under PSD2. Enables bank-account-level pulls with real-time settlement, stronger authentication, and lower fraud exposure than legacy bank debit rails. Still scaling but gaining traction for high-value recurring payments use cases.
Best Practices
The most common pull payment failures — compliance violations, high dispute rates, poor recovery — are operational problems, not technical ones. Merchants and developers who treat pull payments as a solved problem after integration typically discover their gaps at the worst time: during a chargeback audit or a failed renewal surge.
For Merchants
Obtain clear, auditable authorization. Every pull must trace back to a documented mandate with a timestamp, IP address, agreed terms, and authorization reference. This is not a UX nicety — it is your primary defense in a chargeback dispute. Stores that cannot produce a mandate record on demand lose disputes automatically.
Pre-notify before pulling. Send customers advance notice of the upcoming debit — typically 3 to 14 days before the first pull and before any amount change. This is a regulatory requirement under SEPA and BACS, and it materially reduces disputes even on rails where it is only a best practice.
Build staggered retry logic. Failed pulls should not be retried immediately or on a fixed daily schedule. Use a staggered retry cadence — for example, day one, day three, day seven — and align retry timing to when customers are most likely to have funds available (post-paycheck dates vary by market). Notify the customer at each stage.
Segment failure codes rigorously. Distinguish retriable failures (insufficient funds, temporary bank error) from non-retriable ones (account closed, authorization revoked, invalid account). Retrying on a non-retriable code wastes processor fees, damages your merchant score with the bank, and can trigger fraud flags.
For Developers
Rely on webhooks, not synchronous responses. Pull payment settlement is asynchronous. The API response confirming submission is not confirmation of settlement. Subscribe to return, settlement, and exception webhooks from your processor and update payment status only on confirmed settlement events.
Tokenize immediately, never store raw data. Raw bank account numbers and card PANs must never touch your application layer. Use your processor's vault or payment tokenization service to store references. This applies to every card-on-file and bank debit flow without exception.
Enforce idempotency end-to-end. Retry logic in your billing engine must be idempotent at every layer. Duplicate debit submissions result in double charges, which generate disputes, scheme fines, and regulatory scrutiny. Implement idempotency keys at the API layer and validate deduplication before any submission.
Test the full failure path. Most production incidents with pull payments occur in the failure path, not the happy path. Build and explicitly test the complete failure flow: declined pull → customer notification → retry queue → dunning → subscription pause → reactivation on payment success.
Common Mistakes
Initiating a pull without a valid authorization on file. This is the most serious error — it constitutes an unauthorized transaction under scheme rules and applicable regulation. There is no retry, no grace period, and no defense in a dispute. The payer's bank will return the funds and levy a fee.
Skipping pre-notification requirements. SEPA and BACS have mandatory advance notice periods. Ignoring them is not a paperwork issue — it is a scheme compliance breach that can result in fines, mandate invalidation, and processor account termination. Even on rails where pre-notification is not legally required, skipping it increases dispute rates measurably.
Treating all failed pulls as retriable. Retrying a debit after the payer has explicitly revoked authorization, or after the account has been closed, generates unauthorized transaction disputes with no chargeback defense. Failure reason code interpretation must gate every retry decision — this logic belongs in the billing engine, not as an afterthought.
Using static retry intervals. Fixed retry schedules that ignore customer pay cycles produce lower recovery rates than adaptive schedules. A customer on a bi-weekly paycheck rhythm is more likely to have funds on days 1, 15, and 29 of the month. Ignoring this leaves recoverable revenue on the table.
Underbuilding chargeback window reserves. SEPA Core consumers have eight weeks from the debit date to dispute an authorized pull — no questions asked. Revenue from SEPA pulls is not final for two months. Failing to account for this in cash flow modeling and reserve calculations creates accounting errors that compound at scale.
Pull Payment and Tagada
Tagada's payment orchestration layer is purpose-built for the operational complexity of pull payment flows running across multiple processors and geographies simultaneously. When a pull fails on a primary processor, Tagada can automatically re-route the retry attempt to a secondary processor with higher success rates for that BIN range or bank account type — with no code changes required on the merchant side.
Tagada smart retry for pull payments
Tagada's dunning engine applies adaptive retry scheduling to pull payment failures, adjusting retry timing based on each customer's historical payment behavior and account funding patterns. Merchants using Tagada's pull payment orchestration typically recover 18–22% more failed pull transactions compared to fixed-schedule retry logic, without any additional integration work.
For platforms managing high-volume subscription billing across ACH, SEPA, BACS, and card-on-file rails, Tagada normalizes the full mandate lifecycle — from initial authorization capture through amendment, suspension, and cancellation — into a single unified API surface. Dispute ingestion, failure code routing, and cross-processor reconciliation are handled at the orchestration layer, keeping merchant-side billing logic clean and rail-agnostic.