AI-Assisted Fullstack Engineering Program

Architecture deliverables

• Define EventLogRepositoryInterface with store() and findByPaymentId()
• Create EloquentEventLogRepository implementing the interface
• Define PaymentRepositoryInterface with upsert(), findByPaymentId(), and list()
• Create EloquentPaymentRepository implementing the interface
• Bind both interfaces to their implementations in AppServiceProvider
• WebhookService receives both interfaces via constructor injection — no direct Eloquent usage

Feature deliverables

• POST /webhooks/payment — Form Request validates event_id, payment_id, event type, amount ≥ 0, currency (3-letter ISO)
• Migration for event_logs table: event_id, payment_id, event, amount, currency, user_id, timestamp, received_at
• Migration for payments table: payment_id, event (status), amount, currency, user_id, last_event_id, updated_at
• Service flow: always store EventLog, then idempotently upsert Payment only if event_id is new
• GET /payments returns current state per payment_id, newest first
• GET /payments/{id}/events returns all event_log rows for that payment, ordered by timestamp
• Correct HTTP error responses (400, 422) with consistent JSON structure
• Structured logging of each incoming webhook with context (event_id, payment_id, user_id)
• Frontend: payments list page with auto-refresh; clicking a payment shows its event log

Backend deliverables (both paths)

• Authentication: login / logout and protected routes
• Pagination: limit and page params on GET /payments
• Filters on GET /payments: by status (event), date range, user_id, and currency
• Admin: manual refund trigger — POST a payment.refunded webhook internally

Frontend deliverables (both paths); w2-f4–w2-f5 Path A only

• Dashboard with paginated payments table, status badges, and dynamic filters
• Payment detail view: shows all event_log rows for a payment_id, ordered by timestamp, including duplicate deliveries
• Smart auto-refresh: updates payments list without breaking active pagination or filters
• Pinia stores hold all fetched data (payments list, payment detail, event logs) — no component-local API calls (Path A only)
• API module (e.g. api/payments.ts) abstracts all HTTP calls — components never call axios/fetch directly (Path A only)

Core concepts

• Queues and workers in Laravel: how they decouple ingestion from processing
• Retry logic: what happens when a job fails and how to recover
• Rate limiting: protecting the endpoint from traffic spikes
• Structured logging: logs that can be queried and monitored

Required deliverables

• Webhook only enqueues the job — no inline processing
• Job/Worker processes the event from the queue and persists it via repository
• Deduplication handled in the worker — not in the endpoint
• Automatic retry with exponential backoff for failed jobs
• Rate limiting configured on the webhook endpoint
• Structured logging in the worker with queue context and retry count

Request flow — POST /payments/charge

Directory structure

payment-provider/
  Domain/
    Payment/
      Payment.php
      Money.php                   <!-- VO -->
      PaymentRepositoryInterface.php
      WebhookDispatcherInterface.php
    PaymentMethod/
      PaymentMethod.php
      PaymentMethodId.php         <!-- VO -->
      CardFingerprint.php         <!-- VO -->
      PaymentMethodRepositoryInterface.php
  Application/
    TokenizeCard/
      TokenizeCardCommand.php
      TokenizeCardHandler.php
    ChargePayment/
      ChargePaymentCommand.php
      ChargePaymentHandler.php
  Infrastructure/
    Domain/
      PdoPaymentMethodRepository.php
      PdoPaymentRepository.php
      GatewaySimulator.php
      WebhookHttpDispatcher.php
    Resources/
      controllers.php
      routes.php
    Application/
      HandlerBus.php
  config/
    handlers.php                  <!-- Command → Handler wiring -->
    db/
      migrations/