adityanandanx / adityanandanx/raftaar
9. Trip Charging & Transaction Logging
- Langage dominant
- Python
- Étoiles
- 0
- Forks
- 0
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
## Parent PRD
#1
## What to build
Payment processing after trip completion. When a trip ends, the calculated cost is automatically charged to the customer's default payment method via mocked Razorpay API. Transaction is logged with status (success/failed) for audit trail and troubleshooting.
Implements Razorpay mock charge API, transaction state machine, idempotency to prevent duplicate charges, and payment failure handling.
## Acceptance criteria
- [ ] `POST /trips/charge` processes payment for completed trip (internal use, called after trip end)
- [ ] Charges customer's default payment method for calculated cost
- [ ] Mock Razorpay charge: 95% success, 5% random failure (simulates real API)
- [ ] Creates transaction record with: trip_id, user_id, amount, razorpay_id, status
- [ ] Idempotency: same trip charged only once (check if transaction exists)
- [ ] On success: transaction.status = 'success', trip.status = 'paid'
- [ ] On failure: transaction.status = 'failed', trip.status = 'payment_pending'
- [ ] Failed payments don't retry automatically (support team handles)
- [ ] Database schema: `transactions` (id, trip_id, user_id, amount, razorpay_id, status, created_at)
- [ ] Response includes: transaction_id, status, timestamp
- [ ] Edge cases: customer has no payment method (error), amount is 0 (free trip), network failure
- [ ] All transactions logged for audit (admin can see transaction history)
## Blocked by
- Blocked by #7 (Trip End - needs trip with calculated cost)
- Blocked by #8 (Payment Methods - needs saved payment method)
## User stories addressed
- User story 14: Charged based on actual trip duration
- User story 15: Itemized receipt (base for receipt generation)
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Piste de recherche
Start at the POST /trips/charge entry point and review the prerequisites described in blocked issues #7 and #8. Trace how completed trips, calculated costs, and saved payment methods are represented, then map the transaction schema, mocked Razorpay behavior, idempotency rules, and success or failure states to the acceptance criteria.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- backend, database, payments
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 35/100