There's a critical gap between authentication and non-repudiation in payment scheme APIs: how should it be addressed? If you're building or operating financial platforms where disputes over transaction details could shift six-figure liabilities between participants, it's important to grasp why OAuth tokens and mTLS certificates only prove who connected, not what they actually sent. Through a concrete scenario of a disputed €50,000 authorization approval, you'll learn why authentication logs may not hold up under regulatory scrutiny or chargeback arbitration, how JWS (JSON Web Signature) creates verifiable proof of exact message content, and when you actually need cryptographic non-repudiation versus when authentication alone suffices.
We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
NFC Retries Don't Need Re-Auth Under PSD2
Understanding session-based authentication in contactless payments
Should users re-authenticate every time an NFC payment fails due to a quick tap? Most assume PSD2 requires it, but the regulations tell a different story. This article breaks down what Strong Customer Authentication actually means for proximity payments, drawing parallels to chip-and-PIN cards and explaining why a single unlock can legitimately cover multiple tap attempts. If you're building mobile payment experiences, understanding this distinction between authentication and authorization could transform your UX without compromising compliance.
The Tragedy of Fragmented Expertise: Why Your Fintech Will Fail
And Why Your CTO Probably Won’t See It Coming
Your payment engineers and compliance lawyers are having the same conversation
on repeat, and neither understands what the other is saying. Three meetings
later, nothing's shipped and you're bleeding money on coordination. This isn't
a communication problem, it's structural: payment scheme expertise cannot
exist in silos. You need someone who reads regulations
Every time you show your ID to buy alcohol or prove you're a resident for a discount, you're revealing private info that the merchant to answer their simple yes/no question. Here's a thought: your bank already has this information through KYC processes. What if your payment device could simply confirm these facts during the payment itself without exposing any of your personal details?
Converting from Single Message Systems (SMS) to Dual Message Systems (DMS) and back seems deceptively simple, but let's dive in to discover what terrors lie hiding in wait below the calm surface.
Let's look into what exactly the various messages and steps are in payment processsing, and how they differ between Single vs Dual Message Systems as well as the differences between payment networks (e.g., mobile payments vs card networks).
You cannot determine the Personally Identifiable Information classification of data (per GDPR) by looking at the data alone. In fact, non-PII data can become PII when provided to third parties which naturally has significant compliance consequences.
The regulatory language around dynamic linking of authentication codes in remote payments seems to imply that the authentication code must be generated in response to payment creation, but a Q&A clarifies that the authentication code may be created at any stage before the final authorization of the payment transaction by the user.
Whenever a payment is initiated via consumer scan, such as a mobile app scanning a QR code, the payment is considered "remote" according to PSD2 even when the consumer is physically at the merchant's location which is considered a "card present" context for card payments. As a result, certain regulatory considerations come into play, such as dynamic linkin of authorization codes.