Set Up a New Go Microservice for Payment Processing

Problem/Feature Description

A fintech startup needs a new Go microservice to handle payment processing. The service will receive payment requests via a REST API, validate them, store transaction records in SQLite, and return payment status. It needs to integrate with an external payment gateway (Stripe-like) but for now the implementation can be a stub.

The team wants the project scaffolded properly from the start with clean separation of concerns, proper configuration management, and a solid test foundation.

Output Specification

Produce a complete project structure with:

• go.mod with a proper module path (e.g., github.com/acme/payment-service)
• cmd/server/main.go -- entry point that wires all dependencies and starts the HTTP server with graceful shutdown. No business logic in this file.
• internal/config/config.go -- Config struct loaded from environment variables (PORT, DATABASE_URL, STRIPE_API_KEY, LOG_LEVEL) with sensible defaults
• internal/domain/models.go -- Domain types: Payment (ID, Amount, Currency, Status, CustomerID, CreatedAt), PaymentStatus constants (pending, completed, failed, refunded), CreatePaymentRequest
• internal/domain/errors.go -- Domain error types: AppError base type, NotFoundError, ValidationError with HTTP status codes
• internal/handler/ -- HTTP handler struct with constructor, route registration using a router (chi or standard mux), payment endpoints (POST /payments, GET /payments/{id}, GET /payments), response helpers (writeJSON, writeError)
• internal/service/payments.go -- PaymentService with business logic, defines PaymentRepository interface, validates payment requests
• internal/repository/payments.go -- SQL-based PaymentRepo implementing the repository interface
• internal/gateway/stripe.go -- Stub payment gateway interface and implementation
• Makefile with build, run, test, lint, fmt, tidy targets
• .gitignore for Go projects (bin/, coverage.out, .env, IDE files)
• At least one test file placed alongside its source code (e.g., internal/service/payments_test.go) using table-driven tests

Focus on project structure and layered architecture. Business logic can be minimal but the separation must be correct.