Issue 3385: Extract stripe module

[santail]

Issue tracking

Context behind the change

#3385

It was decided to extract payment providers specific logic to separate module as abstraction and Stripe service implementing it. It would be easily to replace Stripe with any other service which should implement respective abstract class.

Now payment service operates with payment provider abstraction.

hmt.users::stripe_customer_id table column was renamed to payment_provider_id

How has this been tested?

Services are covered with unit tests. Some tests were extended, some were added or adjusted.
Verified on local environment by walking through new job creation flow in job-creator.

Release plan

Update env variable names:

PAYMENT_PROVIDER_SECRET_KEY
PAYMENT_PROVIDER_APP_NAME
PAYMENT_PROVIDER_APP_VERSION
PAYMENT_PROVIDER_APP_INFO_URL
PAYMENT_PROVIDER_API_VERSION

Potential risks; What to monitor; Rollback plan

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

5 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
faucet-frontend	⬜️ Ignored (Inspect)	Visit Preview		Jun 26, 2025 6:54am
faucet-server	⬜️ Ignored (Inspect)	Visit Preview		Jun 26, 2025 6:54am
human-app	⬜️ Skipped (Inspect)			Jun 26, 2025 6:54am
human-dashboard-frontend	⬜️ Skipped (Inspect)			Jun 26, 2025 6:54am
staking-dashboard	⬜️ Skipped (Inspect)			Jun 26, 2025 6:54am

[flopez7]

After discussing this with @portuu3, we agreed we should change the approach from creating a separate Stripe module to using an abstract class for the payment provider instead. This way, we can keep general logic in PaymentService and have the Stripe-specific implementation that extend the abstract class. We’re already using this pattern in other parts of the project, like email service with sendgrid in the reputation oracle. This way is easier to maintain or switch providers in the future.

For this, we would define an abstract base class for payment providers that contains any shared logic (if needed) and the abstract methods for the provider-specific actions (like creating a customer, creating an invoice or processing a payment). The Stripe implementation would simply extend this abstract class and provide the Stripe-specific logic. This keeps the PaymentService decoupled from any single provider and makes it straightforward to add or switch payment providers later, since all common code is in one place and each provider only needs to implement the unique parts.

[flopez7]

• Move provider implementation into a dedicated folder inside payment, e.g. modules/payment/providers/stripe.provider.ts
• Place the abstract class in modules/payment/providers/payment-provider.abstract.ts
• Generalize provider method names in the abstract class so they are not Stripe-specific. For example, avoid names like createSetupIntent or handlePaymentIntent unless they are generic enough for all providers.

[flopez7]

We should use camelCase for all interface property names to follow TypeScript and JavaScript conventions. Please update all internal references

[portuu3]

For all the cases where @flopez7 is asking you to change from snake_case to camelCase, you should probably use some kind of intermediate interfaces between the payment service and the provider

[portuu3]

In order to fully encapsulate it:

• Move this enum inside sendgrid module

  human-protocol/packages/apps/job-launcher/server/src/common/enums/payment.ts

  Line 39 in 44d7635

  export enum StripePaymentStatus {

• Rename StripeConfigService to PaymentProviderConfigService (also rename its properties and envs used)