Payee-initiated transactions are payments initiated by a merchant, biller, or other recipient after the payer has established an agreement or mandate. The payer does not take a separate action to trigger each later payment. Common examples include subscription charges, insurance premiums, utility bills, installments, and charges made after a service is used.
The distinction matters because payment initiation affects authentication, transaction classification, customer rights, fraud controls, and the data sent through the payment chain. Under the European Banking Authority’s interpretation of PSD2, the initial mandate may require strong customer authentication (SCA), while later transactions initiated by the payee may fall outside the SCA requirement when the payer is not involved in triggering them.
A payee-initiated transaction is a payment started by the payee under a prior agreement with the payer. The agreement authorizes the payee to initiate one or more later payments through an agreed payment instrument, such as a card or bank account.
The defining feature is the absence of a specific payer action immediately before each payment. A customer may authorize a streaming subscription once, for example, and the merchant may then initiate later scheduled charges under that arrangement.
| Payment type | Who triggers the payment? | Typical example |
|---|---|---|
| Payee-initiated transaction | Payee, under a mandate or agreement | Monthly subscription charge |
| Payer-initiated transaction | Payer at the time of payment | Customer clicks “Pay now” at checkout |
| Direct debit | Payee or biller under a debit mandate | Utility bill collected from a bank account |
A mandate establishes authority, but it does not make every later payment automatically safe. Changes to the merchant, payment credential, billing terms, amount, or customer behavior may require additional review or renewed consent.
These examples can use cards, direct debit, account payments, or other payment instruments. The precise classification depends on the payment method, the agreement, the timing of the payer’s involvement, and the applicable scheme or regulatory rules.
Payee-initiated transactions and merchant-initiated transactions describe closely related concepts, but the terminology depends on the payment context. “Payee initiated” focuses on the recipient starting the payment. “Merchant initiated” is commonly used for card payments started by a merchant after a customer has established an arrangement.
Recurring payments are one common form of merchant-initiated transaction. Other categories may include unscheduled payments, deferred payments, and installments. Payment participants should use the classification required by the relevant card network, payment rail, or regulatory framework.
A card-on-file payment can be either payer initiated or payee initiated. The key question is whether the payer triggers each individual payment.
If a customer stores card details and later clicks a purchase button for each order, the customer is initiating each transaction through the merchant. If the merchant charges the stored payment credential later under an existing mandate, without a specific payer action to trigger that charge, the later payment may qualify as payee initiated.
This distinction affects transaction indicators, authentication treatment, authorization decisions, and dispute analysis. Storing a payment credential alone does not determine who initiated the transaction.
Under the European Commission’s interpretation of PSD2 Article 97, published by the EBA, a transaction initiated by the payee without payer involvement is generally outside the SCA requirement that applies when the payer initiates an electronic payment transaction. The remote setup of the mandate may still require SCA when that action creates a risk of payment fraud or abuse.
The EBA identifies recurring card payments, direct debits, subscriptions, insurance premiums, and similar arrangements as examples of transactions that can be initiated by the payee. Its guidance also distinguishes these transactions from card payments where the payer triggers each individual purchase.
Regulatory interpretation can depend on the payment type, market, transaction data, exemptions, scheme rules, and later legal or supervisory developments. The EBA states that its Q&As are not binding interpretations of EU law and may not reflect every subsequent change. Payment service providers should confirm the current position with the relevant regulator, scheme, acquirer, issuer, and legal advisers. See the EBA guidance on payee-initiated card payments and the applicable PSD2 regulatory technical standards.
Payee-initiated payments reduce the need for a customer to repeat the same action, but the original mandate can become outdated or be abused. A fraudster may compromise an account, alter payment details, exploit a merchant system, or use a legitimate arrangement to collect an unexpected amount.
Fraud controls should therefore assess the payment context, not only the existence of a mandate. Relevant signals can include the payee relationship, amount, frequency, device, location, customer behavior, payment credential changes, and unusual activity across channels.
Entersekt connects authentication and payment risk signals so financial institutions can distinguish expected recurring activity from higher-risk behavior. Mandates in digital commerce explains how consent, payment classification, authentication evidence, and transaction context fit together.
These controls should work across browsers, mobile applications, wallets, payment service providers, acquirers, and issuer systems. A valid mandate can still produce a poor outcome when payment messages are incomplete or fraud signals remain isolated.
Payee-initiated payments support convenient services because customers do not have to repeat the same payment instruction each time. The customer experience depends on accurate consent, predictable billing, clear notifications, and a proportionate response when risk changes.
Authentication should match the payment context. Low-risk activity may follow the established arrangement, while unusual behavior or a high-risk change may justify additional assurance. This approach protects the payment relationship without treating every recurring charge as a new checkout.
For related payment risk, see Entersekt’s resources on real-time payments and authorized push payment fraud. These concepts involve different initiation models, but they show why payment speed, intent, identity, and transaction context must be assessed together.
A payee-initiated transaction is a payment started by the recipient under a prior agreement or mandate with the payer. The payer does not take a separate action to trigger that individual payment. Subscriptions, utility bills, insurance premiums, and later installments are common examples.
The initial mandate may require strong customer authentication when it is created through a remote channel and may create a risk of payment fraud or abuse. The treatment depends on the payment method, applicable rules, exemptions, and market. Later payee-initiated payments may receive different treatment.
Recurring payments can be payee initiated when the payee starts each later payment under an existing agreement and the payer does not trigger each charge. The first transaction or mandate setup is distinct from later collections and should be classified separately.
Payee-initiated transactions may fall outside the PSD2 SCA requirement when the payer is not involved in triggering them. This does not remove all security or customer-protection obligations. The mandate setup, payment context, scheme rules, and current regulatory interpretation still matter.
A payer-initiated payment is triggered by the customer, such as clicking to complete a purchase or sending a bank transfer. A payee-initiated payment is started by the recipient under an existing agreement. The distinction influences authentication, transaction data, risk assessment, and processing.
Financial institutions can reduce risk by combining clear mandate records with transaction monitoring, payee and payment-instrument checks, behavioral analysis, and adaptive authentication. Entersekt connects payment context with authentication decisioning so unusual activity can receive additional scrutiny at the relevant point in the journey.
Payment rules and scheme requirements vary by market and can change. This entry is educational and should not replace advice from a qualified legal, compliance, or payments professional.