Authorise a payment with an identity-bound approval that covers amount and payee.
Today
With the EUDI Wallet
The wallet changes how the evidence is collected. The step at the end stays yours.
Why the wallet helps
A wallet authorization ties the confirmation to the payer and to the specific transaction. The consent screen shows amount and payee, and the signature covers both, which is what PSD2 dynamic linking asks for. The result resists phishing and carries an identity binding the issuer can rely on.
01
You create a request with amount and payee
02
The payer gets it by QR or deep link
03
The wallet shows amount and payee
04
The payer approves with their device unlock
05
The wallet returns an approval bound to the transaction
06
Authbound verifies the approval
07
Your backend receives the authorisation result
08
You settle the payment
Step 01
The payer sees amount and payee in their wallet, not a generic approve prompt.
Step 02
The signature covers amount and payee, so an intercepted approval cannot be replayed against a different payment.
Step 03
Your flow receives an authorization tied to a verified identity, with the record attached.
Technical flow
const verification = await authbound.verifications.create({
policyId: 'pol_…', // the claims this flow requests
customerUserRef: user.id,
});
// Your webhook then receives verification.completed
// with the verified result and its audit record.Wallet presents
Terms to know
Regulatory context
PSD2 strong customer authentication and dynamic linking, eIDAS 2.0
PSD2 requires strong customer authentication and dynamic linking of the approval to amount and payee. eIDAS 2.0 lets the wallet serve as an SCA method, but wallet payments are still being specified, with EU roll-out expected around 2027 to 2028. Scheme rules, fraud liability and dispute handling remain with the payment provider.
Wallet-native payment authorization with identity-bound dynamic linking.
What it asks the wallet for
What the business gets back
PulsePay is a fictional company built by Authbound. The wallet integration in it uses the real Authbound SDK.
The authentication code has to be specific to the amount and the payee, and any change to either must invalidate it. A signature over the transaction details does this directly, which is awkward to achieve with a generic one-time code.
Not on day one. It is an authentication method that runs inside your SCA flow. How far it displaces existing challenges depends on scheme support and issuer adoption.
Only what the flow needs. The authorization can confirm a valid identity-bound approval happened without disclosing the payer’s full attributes.
Not at scale. The EU expects wallet payments around 2027 to 2028, and Authbound’s payments product is on the roadmap. The demo shows the target flow.
Yes. The wallet runs as an extra authentication method inside your SCA flow, and existing methods stay as the fallback.
An approval bound to the amount and payee, the payer’s identity binding, and a verification ID for your audit trail.
They authenticate with your current method. Nothing in the payment flow depends on the wallet being there.
That is the aim. Wallets use the same protocols everywhere, so a cross-border payer would not need a separate method.
Liability rules under PSD2 and your scheme do not change. A stronger, identity-bound approval helps with disputes but does not move liability on its own.
The payment request, the step that triggers authorisation, and settlement. Authbound would handle the wallet interaction and verify the approval.
Banking & fintech
Runs on the same Authbound API key.
iGaming
Runs on the same Authbound API key.
E-commerce
Runs on the same Authbound API key.
Built on Authbound Payments. One API key covers every flow you add later.
Tell us what you are trying to build. We will map the user journey, the credentials and the wallet interaction to an implementation.