Concept: Federated Payment Standard
Overview
Federated Payment Standard (FPS) is an open, lightweight, and low-cost payment protocol designed to eliminate intermediaries, simplify transactions, and make true micropayments economically viable.
It leverages existing banking infrastructure — such as ELIXIR settlements or mobile banking apps — instead of relying on card networks or payment gateways. FPS creates a direct, federated network of banks and merchants, enabling fast, secure, and extremely cheap electronic transactions.
Key Features
| Feature | Payment Standard | Traditional Operators |
|---|---|---|
| Transaction Cost | Fixed, ultra-low (< 0.01 PLN) | % Fee + Flat Fee |
| Intermediaries | None | Multiple layers of processors |
| Integration Effort | Minimal (bank API / SDK) | Complex, vendor-specific |
| Chargebacks / Reserves | Not required | Mandatory and costly |
| Micropayment Support | Fully viable | Economically infeasible |
| Customer Flow | Instant, no redirects | Multi-step with payment gateways |
| Instant Confirmation | Yes | Yes |
| Funds Settlement | Direct to merchant | Aggregated, delayed |
| Small Business Flexibility | High | Limited |
| Transparency | Full — customer sees who they paid | Opaque operator references |
| Contract Requirement | None | Required with strict policies |
Core Components
1. Registry
A federated directory of participating banks and payment providers. It manages:
- Payment link validation
- Transaction signature verification
- Bank endpoint discovery
A single bank can support multiple registries — ensuring no vendor lock-in.
2. Payment Link Generation
Merchants or payment providers use SDKs to generate payment links or QR codes. When a user clicks or scans the link:
- Their banking app recognizes the payment schema.
- It opens directly in the user’s bank app with all payment fields prefilled.
- The transaction can be approved instantly.
Each SDK-encoded link contains cryptographic parameters validated through the Registry.
3. Two-Step Confirmation
Every transaction emits two webhook-based confirmations to the merchant:
- Complete – triggered when the user finalizes payment in the banking app (UX confirmation).
- Confirm – emitted once the funds are settled by the bank (irrevocable confirmation).
Both events are signed and verifiable through the Registry.
Transaction Model
| Model | Transaction Fee | Percentage Fee |
|---|---|---|
| Traditional methods | ~0.25 PLN | 1–3% |
| Payment Standard | < 0.01 PLN | 0% |
Execution Time
- The transaction notification is instant after user confirmation.
- Actual funds arrival depends only on the standard interbank session times.
Security
- Funds always move directly between the user’s bank and the merchant’s bank.
- The Registry never handles money — only verifies transaction metadata and signatures.
- Security is maintained at institutional level (Banks, Merchants).
Main Risks & Mitigations
| Risk | Description | Mitigation |
|---|---|---|
| Transfer cancellation | User cancels after confirmation | Two-step verification: complete (UX) + confirm (final) |
| Key leakage | Exposure of checksum or signing keys | Bank- and Registry-side key rotation |
| Spoofed payment link | Altered target account | Signature and checksum validation |
| Faulty implementation | Skipped checksum verification | Official SDK enforcement |
| Client key extraction | Reverse engineering | Key rotation, backend relocation |
Conclusions & Call for Collaboration
Federated Payment Standard introduces a long-awaited, cost-efficient, and simple standard for digital micropayments — built on top of the existing banking ecosystem.
It empowers small merchants, developers, and banks to implement fast, direct, and open digital payments without intermediaries.
We invite banks, service providers, and developers to join in shaping the future of open, federated payment infrastructure.