adityanandanx / adityanandanx/raftaar
9. Trip Charging & Transaction Logging
- Ngôn ngữ chính
- Python
- Star
- 0
- Fork
- 0
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Mô tả
## 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)
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- python
- Lĩnh vực
- backend, database, payments
- Loại issue
- Tính năng
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 35/100