Payment Gateway Module implementation OpenSource / GitHub
Budget: €250 – €750 EUR
Develop a payment gateway module that integrates with multiple Payment Service Providers (PSPs) via a standardized interface (PSP Adapter), enabling payment processing across arbitrary platforms. The module should support multiple payment methods, configurable through an external configuration file. Payments are processed on behalf of tenants, with tenant-specific PSP configurations stored in the database and linked to tenant IDs. For this scope, PSP Adapters will be implemented for Stripe, PayPal, and a dummy “No-Op Provider,” with the module designed to allow easy addition of new PSPs in the future. It must support recurring payments and ensure that all transactions are fully traceable and auditable.
Full payment gateway specification (TO BE FOLLOWED - READ CAREFULLY):
https://github.com/Labs64/labs64.io-docs/tree/master/payment-gateway
Deliverables
- OpenAPI Spec: Fully specified YAML file for the RESTful API.
- Java Module: Implementing the functionality described above; including PayPal, Stripe and NoOp PSP adapters.
- Unit Tests: Covering all major functionalities.
- Configuration:
- Structured application.yaml for integrated payment methods.
- PSP-specific configuration instructions/templates/examples for a tenant.
- Database: Flyway migration scripts in resources/db/migration.
- Dockerfile: For containerizing the module.
- Create docker-compose for local development including HA config with multiple instances.
- Documentation: Setup, configuration, usage guide, contributor guide.
- CI/CD: .github workflows pipeline to build, test.
Start your bid with the hashtag #IWILLCOMMITDAILY
Bids submitted within the first 20 minutes after the job is posted will be disqualified
Milestones
- Total workload will be split into milestones defined as below.
- At the beginning of each milestone, a new PR must be created targeting the main branch of the Payment Gateway repo.
- Daily work progress must be frequently committed (one daily commit at minimum).
- Early & timely communication via GitHub Issues and PRs only. Expect on-the-fly comments to the commits.
- Each milestone must be approved and merged before proceeding to the next one.
- Scope review and adjustments may be done at the end of each milestone if necessary. Additional work beyond the defined milestones will be treated as out-of-scope and must be agreed separately.
- Approved and merged milestones PRs are considered as completed and entitled for payment.
- Failure to complete a milestone within the agreed timeframe may result in project termination.
Milestone 1: Project Setup & Basic Architecture
- Setup Spring Boot project with necessary dependencies.
- Design OpenAPI specification with generated Java interface and create API stubs with log output.
- Dockerfile and basic CI/CD pipeline.
Milestone 2: PSP Abstraction Layer & NoOp Implementation
- Implement PSP Abstraction Layer using Strategy Pattern.
- Create NoOp PSP adapter for testing.
- Create needed database entities and Flyway migration scripts.
- Implement all endpoints with basic logic.
Milestone 3: Stripe Integration
- Implement Stripe PSP adapter.
- Complete payment flow for Stripe.
- Unit tests for Stripe integration.
Milestone 4: PayPal Integration
- Implement PayPal PSP adapter.
- Complete payment flow for PayPal.
- Unit tests for PayPal integration.
Release Condition: The Pull Request to the Payment Gateway repo must be accepted and merged into the main branch to release the freelance payment feature.
Acceptance Criteria
- Code follows standard Java best practices (consistent with checkout/auditflow modules) and is well-documented.
P- SP Abstraction Layer is implemented using the Strategy Pattern (e.g., StripeProvider, PayPalProvider, and NoOpProvider implement a common PaymentProvider interface).
- Integrated PSPs:
- Stripe (latest API) - https://docs.stripe.com/api
- PayPal (latest API) - https://developer.paypal.com/api/rest/
- None (NoOp for testing)
- One-time and Recurring payment can be demoed with all integrated PSPs using sandbox accounts.
- Async Messaging: RabbitMQ producer is implemented for payment.finalized events with transaction payload.
- Distributed Environments / Kubernetes safety:
- All functionality can run reliably on Kubernetes
- Execution is idempotent to prevent duplicate processing
- Components are safe to run in parallel across multiple pods
- Coordination and state handling support distributed execution without race conditions
- Traceability: Every log entry and RabbitMQ message must contain a correlationId traceable across ecosystem modules.
- Docker container builds successfully and runs without errors.
- All unit tests pass with >80% code coverage.
- API endpoints function exactly as specified in the OpenAPI documentation.
- Logging Policy: no sensitive information in the logs, such as PAN/PII, credentials, etc.
- Payment methods are configurable via YAML and retrievable via API.
- Vulnerability Scanning: no High and Critical vulnerabilities (static code analysis, dependencies, docker, etc.) with GitHub Code scanning / CodeQL, Trivy for Docker
Full payment gateway specification (TO BE FOLLOWED - READ CAREFULLY):
https://github.com/Labs64/labs64.io-docs/tree/master/payment-gateway
Deliverables
- OpenAPI Spec: Fully specified YAML file for the RESTful API.
- Java Module: Implementing the functionality described above; including PayPal, Stripe and NoOp PSP adapters.
- Unit Tests: Covering all major functionalities.
- Configuration:
- Structured application.yaml for integrated payment methods.
- PSP-specific configuration instructions/templates/examples for a tenant.
- Database: Flyway migration scripts in resources/db/migration.
- Dockerfile: For containerizing the module.
- Create docker-compose for local development including HA config with multiple instances.
- Documentation: Setup, configuration, usage guide, contributor guide.
- CI/CD: .github workflows pipeline to build, test.
Start your bid with the hashtag #IWILLCOMMITDAILY
Bids submitted within the first 20 minutes after the job is posted will be disqualified
Milestones
- Total workload will be split into milestones defined as below.
- At the beginning of each milestone, a new PR must be created targeting the main branch of the Payment Gateway repo.
- Daily work progress must be frequently committed (one daily commit at minimum).
- Early & timely communication via GitHub Issues and PRs only. Expect on-the-fly comments to the commits.
- Each milestone must be approved and merged before proceeding to the next one.
- Scope review and adjustments may be done at the end of each milestone if necessary. Additional work beyond the defined milestones will be treated as out-of-scope and must be agreed separately.
- Approved and merged milestones PRs are considered as completed and entitled for payment.
- Failure to complete a milestone within the agreed timeframe may result in project termination.
Milestone 1: Project Setup & Basic Architecture
- Setup Spring Boot project with necessary dependencies.
- Design OpenAPI specification with generated Java interface and create API stubs with log output.
- Dockerfile and basic CI/CD pipeline.
Milestone 2: PSP Abstraction Layer & NoOp Implementation
- Implement PSP Abstraction Layer using Strategy Pattern.
- Create NoOp PSP adapter for testing.
- Create needed database entities and Flyway migration scripts.
- Implement all endpoints with basic logic.
Milestone 3: Stripe Integration
- Implement Stripe PSP adapter.
- Complete payment flow for Stripe.
- Unit tests for Stripe integration.
Milestone 4: PayPal Integration
- Implement PayPal PSP adapter.
- Complete payment flow for PayPal.
- Unit tests for PayPal integration.
Release Condition: The Pull Request to the Payment Gateway repo must be accepted and merged into the main branch to release the freelance payment feature.
Acceptance Criteria
- Code follows standard Java best practices (consistent with checkout/auditflow modules) and is well-documented.
P- SP Abstraction Layer is implemented using the Strategy Pattern (e.g., StripeProvider, PayPalProvider, and NoOpProvider implement a common PaymentProvider interface).
- Integrated PSPs:
- Stripe (latest API) - https://docs.stripe.com/api
- PayPal (latest API) - https://developer.paypal.com/api/rest/
- None (NoOp for testing)
- One-time and Recurring payment can be demoed with all integrated PSPs using sandbox accounts.
- Async Messaging: RabbitMQ producer is implemented for payment.finalized events with transaction payload.
- Distributed Environments / Kubernetes safety:
- All functionality can run reliably on Kubernetes
- Execution is idempotent to prevent duplicate processing
- Components are safe to run in parallel across multiple pods
- Coordination and state handling support distributed execution without race conditions
- Traceability: Every log entry and RabbitMQ message must contain a correlationId traceable across ecosystem modules.
- Docker container builds successfully and runs without errors.
- All unit tests pass with >80% code coverage.
- API endpoints function exactly as specified in the OpenAPI documentation.
- Logging Policy: no sensitive information in the logs, such as PAN/PII, credentials, etc.
- Payment methods are configurable via YAML and retrievable via API.
- Vulnerability Scanning: no High and Critical vulnerabilities (static code analysis, dependencies, docker, etc.) with GitHub Code scanning / CodeQL, Trivy for Docker