The current payment flow relies on a real Entur Sales API and Vipps redirect. For a fully self-contained demo, we need a mocked payment API that simulates card-based payments without any external dependencies.
This is a separate API from both OMSA and the customer system — it handles payment method management and transaction processing.
Mock payment API should support:
- Listing saved payment cards for a customer
- Adding/removing saved cards
- Processing a payment against a saved card (instant mock success/failure)
- Transaction history for a customer
Vipps should be excluded entirely from the mocked context since it requires real external redirects and cannot be meaningfully simulated.
BFF work:
- New routes for payment method CRUD and payment processing
- Replace Vipps redirect flow with direct mock card payment confirmation
- In-memory storage for saved cards and transactions
Flutter work:
- Update purchase flow to use saved card selection instead of Vipps redirect
- Saved cards management in profile (add/remove)
- Remove or hide Vipps as a payment option when running against mock
- Simplify the payment return flow (no external redirect round-trip)
Relates to #48 (mock OMSA server) and #50 (customer system) — a customer's saved cards should be tied to their customer identity.
The current payment flow relies on a real Entur Sales API and Vipps redirect. For a fully self-contained demo, we need a mocked payment API that simulates card-based payments without any external dependencies.
This is a separate API from both OMSA and the customer system — it handles payment method management and transaction processing.
Mock payment API should support:
Vipps should be excluded entirely from the mocked context since it requires real external redirects and cannot be meaningfully simulated.
BFF work:
Flutter work:
Relates to #48 (mock OMSA server) and #50 (customer system) — a customer's saved cards should be tied to their customer identity.