Payment consent, SCA and agent mandates: what is the difference?
Payment consent records permission for a payment. Strong Customer Authentication (SCA) checks the payer using the applicable authentication process. An agent mandate limits what software may request on an owner’s behalf. OAuth carries API authorization. None of these, on its own, proves that money reached the recipient.
Scope: An engineering comparison for product, development and risk teams. Legal references explain the distinction; the applicable rules depend on the payment service and transaction. The worked example is synthetic.
Compare the five layers
| Layer | Question it answers | Evidence to inspect |
|---|---|---|
| Payment consent | Did the payer agree to this payment or defined series? | The agreed scope, payment details, capture method and timing. |
| SCA | Was the required customer authentication performed for this action? | The provider’s authentication result and binding to the relevant transaction. |
| Agent mandate | May this agent propose or initiate this purchase within the owner’s limits? | The mandate version, agent, recipient, budget, expiry and decision. |
| OAuth / OpenID Connect | What may the client access, and who signed in? | Validated token audience, authorization details and identity context. |
| Payment outcome | What happened after submission? | The provider payment reference, status and available reconciliation evidence. |
Keep account-information consent separate too. Permission to read transactions does not automatically authorize a transfer. A generic “consent approved” label hides which resource and action were approved.
Consent and authentication are connected
PSD2 treats payer consent and authentication as distinct subjects. Article 64 concerns consent to execute a payment transaction; Article 97 addresses Strong Customer Authentication. An authentication event should therefore be interpreted in the context of the action it protects. See PSD2, Articles 64 and 97.
Where the remote-payment dynamic-linking requirements apply, the authentication is linked to the amount and payee; changing either invalidates the generated authentication code. A design that approves one recipient but executes another needs more than a “still logged in” check. See Regulation 2018/389, Article 5.
An agent mandate cannot decide for the provider that SCA is unnecessary. Whether an exemption or another treatment applies requires the provider’s rules and the relevant legal context. This comparison is not an exemption decision tree.
Can OAuth express payment authorization?
Yes, if the integration defines and enforces it. OAuth authorization is not limited to a broad scope such as payments:write. RFC 9396, Rich Authorization Requests, defines authorization_details for structured permissions and includes a payment example with an amount, currency and creditor.
The distinction is between a token merely granting access to an API and a system enforcing the owner’s actual transaction terms. A rich authorization request can carry those terms; the authorization server and resource server still need to validate and enforce them. An arbitrary client-supplied amount is not an approval.
OpenID Connect supplies an identity layer. A valid ID token can support the answer to “who signed in?” It should not be repurposed as a payment receipt or unlimited spending authority. Token protection and privilege constraints are covered in OAuth security best current practice.
A worked €30 purchase
- The owner grants bounded authority.An office-supplies agent may spend up to €40 per purchase with a named supplier, within a €200 budget period. This defines the agent’s envelope.
- The service checks the final proposal.A €30 order includes delivery and tax. The authenticated agent, supplier, currency, time and remaining budget must match the current mandate. Reserve budget before concurrent requests can consume it.
- The provider runs its payment flow.The integration obtains the required payment consent and follows the applicable authentication process. An earlier website login does not settle these questions.
- The application checks the outcome.A browser return can say that the user completed a step. The payment status still needs confirmation from the provider. Keep the mandate decision and payment result separately.
Change one fact: the supplier adds €15 delivery after review. The €45 total exceeds the €40 mandate cap. The agent needs revised authority before proceeding; repeating the same login does not fix the limit. If transaction-bound authentication was already performed, the changed details must also be handled under the provider’s flow.
Questions for a design review
- Does “approve” mean account access, one payment, a series, or ongoing agent authority?
- Can you reconstruct the exact amount and recipient that were presented?
- Where are the mandate terms checked, and can the agent bypass that service?
- What happens when consent expires, the mandate is revoked, or a token is replayed?
- Which provider status permits your product to display “paid,” and what evidence supports it?
Turn those questions into checks with the agent payment test pack. For the last question, use the payment pending after SCA guide.
A SEPA Direct Debit mandate has a separate scheme meaning. Avoid using the same unqualified “mandate” label for both a direct debit authorization and your software-agent policy.
Put the questions to a sandbox.
ZILLQ is an independent European payments sandbox with synthetic accounts and funds, agent mandate mechanisms, OAuth2/OpenID Connect authentication and EUDI wallet emulation. Use these references to frame your investigation; they do not certify that every control described here is implemented.
See the platform and its boundaries → · Open the synthetic sandbox →