Designing Approval and Consent Flows for Payments

Design payment approval and consent flows so the user authorises the exact amount and payee, never a vague “confirm.” Show what is being agreed, bind the authentication to those specifics, separate data-access consent from payment mandates, and make withdrawal as easy as granting. Under PSD2, GDPR, and Regulation E, ambiguity is a compliance failure, not just poor UX.

What does dynamic linking require you to show at approval?

Under PSD2, when a payer authenticates a payment, the authentication code must be specific to the exact amount and the exact payee, and the payer must be shown both. This is dynamic linking. The practical design rule follows directly: never ask a user to authenticate a screen that says only “confirm.”

The four properties the code must have

Dynamic linking is set out in Article 5 of the EBA Regulatory Technical Standards on Strong Customer Authentication (Commission Delegated Regulation (EU) 2018/389, eba.europa.eu). It requires four things at once: the payer is made aware of the amount and the payee; the authentication code generated is specific to that amount and that payee; any change to the amount or payee invalidates the code; and the confidentiality, authenticity, and integrity of the amount and payee are protected through every stage of authentication.

For a product team, that means the amount and payee are not decoration on the approval screen. They are the thing being signed. The authentication step, whether a biometric in a banking app or a passcode, must be bound to that specific transaction. If a user could approve one payment and have the credential apply to another, the flow fails the standard.

What this looks like on screen

The approval screen shows the amount, the currency, and the payee name in the same view where the user authenticates, not a step earlier. On a native app doing out-of-band authentication, the challenge itself restates the amount and payee. Our guide to SCA and 3DS UX that doesn’t kill conversion covers how the challenge channel affects abandonment; here the point is narrower. Whatever the channel, the figures the user sees must be the figures the credential signs.

How is data-access consent different from a payment mandate?

Data-access consent lets a third party read account information; a payment mandate authorises money to move. They are governed differently and should never share one screen or one toggle. Data consent needs scope, duration, and purpose plus easy revocation. A mandate needs the specific amount, payee, and dynamic linking described above.

Two consents, two mental models

In open banking, account information access and payment initiation are separate regulated activities. Conflating them is a common and dangerous shortcut: a user who agrees to “connect your account” may believe they have shared read-only data when they have in fact authorised a payment, or the reverse. Keep the two flows visually and structurally distinct, with different language, different confirmation, and different records.

Data-access consent should always name three things: what scope of data is being shared, for how long the access lasts, and for what purpose. It should be discoverable and reversible from a consent dashboard where the user can see every active connection and revoke any of them in one step. A payment mandate, by contrast, is about a specific movement or a specific recurring arrangement, and its screen should show amount and payee, not data categories.

A reference table

Consent type	What must be shown	How to revoke
Data-access (AIS) consent	Data scope, access duration, third party, purpose	Consent dashboard; single-step disconnect, no email or call
Single payment approval	Exact amount, currency, payee, dynamic-linked auth	Not applicable once executed; cancel before authentication
Recurring mandate	Amount or amount rule, frequency, next date, end date	Cancel from mandate list; effective immediately, confirmation shown
Pre-authorized transfer (US)	Amount or amount range, timing, payee, written authorization	Stop-payment request to bank up to three business days prior
Marketing or data-processing consent	Specific purpose, controller, plain-language request	Withdraw as easily as given, per GDPR Article 7

The reducing drop-off in account funding discipline applies to the connect step: the clearer the consent, the fewer users abandon at the bank redirect, because they understand what they are agreeing to.

What does Regulation E require for US electronic transfers?

For US consumer electronic fund transfers, Regulation E (12 CFR 1005) governs authorization and pre-authorized transfers. A pre-authorized transfer from a consumer account must be authorized in writing and signed or similarly authenticated, and the consumer must get a copy of the terms. This shapes both the mandate screen and the record you keep.

Authorization, records, and stop-payment

Regulation E, which implements the Electronic Fund Transfer Act, sets rules for consumer transfers that have no direct PSD2 equivalent (ecfr.gov, 12 CFR 1005). Section 1005.10 requires that a pre-authorized transfer recurring at substantially regular intervals be authorized only by a writing signed or similarly authenticated by the consumer, with a copy provided to them. “Similarly authenticated” covers electronic authorization, which is what most fintech flows rely on, so your consent screen is also your legal record.

Three design consequences follow. First, capture and store the authorization in a form you can reproduce: what the consumer agreed to, when, and how they authenticated. Second, give the consumer the copy of terms the rule requires, not buried in a receipt but as part of the flow. Third, support stop-payment: under Section 1005.10(b) a consumer can stop a pre-authorized transfer by notifying the institution up to three business days before the scheduled date, so a US recurring mandate needs a cancel path that respects that window.

US and EU are not the same flow

A team shipping in both regions cannot use one consent screen. The EU flow leans on dynamic linking and SCA; the US flow leans on the written-authorization and stop-payment rules of Regulation E. The overlap is the principle, not the mechanics: show exactly what is being agreed, and keep a record you can defend. The same care that goes into designing KYC flows that convert belongs here, because both are places where a sloppy screen creates a compliance liability, not just friction.

How do GDPR Article 7 conditions shape a consent screen?

Where you rely on consent to process personal data, GDPR Article 7 sets conditions that map directly to UI. Consent must be freely given, specific, informed, and unambiguous, the request must be clearly distinguishable and in plain language, and withdrawal must be as easy as giving consent. A pre-ticked box or a bundled agreement fails.

From legal conditions to screen rules

Article 7 (gdpr-info.eu/art-7-gdpr/) and the definition of consent in Article 4(11) translate into concrete constraints. Freely given means no bundling: a user cannot be forced to accept marketing data use in order to make a payment. Specific means one purpose per consent, not a catch-all. Informed means the user knows who the controller is and what happens to the data. Unambiguous means a clear affirmative action, so no pre-checked boxes and no consent inferred from silence.

The withdrawal rule is the one teams most often break. Article 7(3) says the data subject can withdraw consent at any time, and it must be as easy to withdraw as to give. If granting consent took one tap, revoking it cannot require an email to support or a phone call. This is why the consent dashboard is not optional polish; it is how you satisfy the withdrawal condition. The trust mechanics we describe in designing trust in fintech UX reinforce the point: control that is visible and reversible is what makes users comfortable sharing in the first place.

How should recurring mandates show amount, frequency, and next date?

A recurring mandate screen should state the amount or the rule that sets it, the frequency, the next charge date, and how to cancel, all before the user authorises. Ambiguity about “how much and how often” is where recurring payments generate disputes, chargebacks, and regulatory complaints, so the mandate screen carries real weight.

The fields a mandate must make explicit

List the specifics plainly, in the user’s own terms:

• The amount, or if variable, the rule and any cap, so the user knows the maximum they are agreeing to.
• The frequency in plain language, such as “every month” or “every four weeks,” not a cron-like abstraction.
• The next charge date and, where known, the end date or renewal behaviour.
• The payee name the user will recognise on a statement, matched to the descriptor you actually send.
• A single, obvious cancel path, and confirmation that cancellation took effect.

For a fixed-amount recurring payment under PSD2, SCA typically applies to the first payment and subsequent charges can be exempt, but that is a compliance mechanic, not a licence to hide the terms. The user still agreed to a series, so the series must be legible at the moment of agreement. Keeping the descriptor consistent with what appears on the statement also cuts “I don’t recognise this charge” disputes, which is a measurable operations cost, not only a UX nicety.

What are the anti-patterns that move money by mistake?

The dangerous anti-patterns are the ones that let a user authorise without understanding what they authorised: a vague confirm button, a bundled consent, a mandate with hidden terms, or a revocation path that is harder than the grant. Each one either breaks a specific rule or manufactures a dispute.

Patterns to design out

• Authenticating a “confirm” with no amount and payee in view. This fails PSD2 dynamic linking outright.
• One toggle that grants both data access and payment authority. Users cannot give specific consent to two different things at once.
• Pre-ticked boxes or consent bundled into a required step, both of which fail GDPR Article 7’s freely-given and unambiguous conditions.
• A recurring mandate that shows the first charge but not the frequency, cap, or cancel path.
• Revocation gated behind support: an email, a phone call, or a hunt through settings, when the grant took one tap.
• A statement descriptor that does not match the payee name shown at approval, which reads to the user as an unauthorised charge.

Approval and consent are core product-design work, the kind of flows where a small wording or layout choice has a legal and financial edge. This is exactly what we build with clients through our product design service, from the mandate screen to the consent dashboard behind it.

Key takeaways

• PSD2 dynamic linking requires the authentication code to be specific to the exact amount and payee, and both must be shown to the user. Never authenticate a vague “confirm.”
• Keep data-access consent and payment mandates as separate flows: data consent needs scope, duration, and purpose; a mandate needs amount, payee, and frequency.
• Regulation E (12 CFR 1005) requires pre-authorized US transfers to be authorized in writing or similarly authenticated, with a copy of terms and a stop-payment path up to three business days before the charge.
• GDPR Article 7 requires consent to be freely given, specific, informed, and unambiguous, and withdrawal to be as easy as granting, which is why a consent dashboard is mandatory, not optional.
• Recurring mandates must show amount or amount rule, frequency, next date, and a one-step cancel before the user agrees.

Consent and approval are where a design mistake moves money or exposes data, so they deserve more care than any other screen in a payments product. If you want these flows built to the regulation that governs each transaction, talk to us.