feature: Add Cashfree Payment Provider

[AyushChothe]

Roadmap Task

👉 https://getlago.canny.io/feature-requests/p/payment-provider-add-integration-for-cashfree-payments

Context

Cashfree Payments is India's leading payment gateway, and with Stripe halting the onboarding of new merchants in India due to regulatory constraints, businesses are left with limited alternatives. Ensuring that Cashfree Payments is available to users is essential, as it will expand Lago's accessibility and appeal to Indian companies, broadening its reach within this crucial market.

We at Pyrite Cloud have begun developing the integration with Cashfree Payments. This will help expand our platform's accessibility, especially for Indian businesses, by providing them with a reliable payment gateway as an alternative to Stripe.

Description

Added Cashfree Payment Provider concerning existing Payment Providers. Still Work in Progress.

[vincent-pochet]

Thank you very much @AyushChothe for this great contribution.
We will review it carefully in the coming days and we will come back to you

[AyushChothe]

Hi @vincent-pochet,

Thank you! Please keep me updated on the review process and let me know if any changes are needed.

Also, could you guide me on how to run Rspec locally? I want to get started with writing tests.

[vincent-pochet]

@AyushChothe

To run rspec locally:

• If you have a running lago api docker container (see https://github.com/getlago/lago/wiki/Development-Environment for more details):

lago exec api rspec
# or docker compose -f ./docker-compose.dev.yml exec api rspec 

• In you are running it directly on your local system:

cd api
bundle exec rspec

[AyushChothe]

Hey @vincent-pochet,

I've addressed all the review comments you mentioned earlier and added test cases for the impacted modules.

I wanted to get your thoughts on how we should handle these modules since we aren't creating PaymentProviderCustomers. Would creating a dummy PaymentProviderCustomers make sense, or is there a better approach?

Here's the list of modules in question:

PaymentProviderCustomers::Factory
PaymentProviderCustomers::CreateService
Customers::GenerateCheckoutUrlService

I am looking forward to hearing your thoughts!

[vincent-pochet]

Hey @vincent-pochet,

I've addressed all the review comments you mentioned earlier and added test cases for the impacted modules.

I wanted to get your thoughts on how we should handle these modules since we aren't creating PaymentProviderCustomers. Would creating a dummy PaymentProviderCustomers make sense, or is there a better approach?

Here's the list of modules in question:

PaymentProviderCustomers::Factory
PaymentProviderCustomers::CreateService
Customers::GenerateCheckoutUrlService

I am looking forward to hearing your thoughts!

Thank you for the update.
To be fully compatible with the other providers, I think yes we should handle a Customer as well even if it is not attached to any external resource

[AyushChothe]

Hey @vincent-pochet,
I've addressed all the review comments you mentioned earlier and added test cases for the impacted modules.
I wanted to get your thoughts on how we should handle these modules since we aren't creating PaymentProviderCustomers. Would creating a dummy PaymentProviderCustomers make sense, or is there a better approach?
Here's the list of modules in question:

PaymentProviderCustomers::Factory
PaymentProviderCustomers::CreateService
Customers::GenerateCheckoutUrlService

I am looking forward to hearing your thoughts!

Thank you for the update. To be fully compatible with the other providers, I think yes we should handle a Customer as well event if it is not attached to any external resource

Thanks, that's what I was thinking as well. I'll start working on it now!

[vincent-pochet]

It start to look great!
Here a few other minor comments

[AyushChothe]

Hi @vincent-pochet, please review this PR again, including the respective frontend PR at getlago/lago-front#1720.

[vincent-pochet]

Thank you for the update. Here are few small comments but I think we are close to something that could be merged 👍

[vincent-pochet]

Last comments regarding the Invoices::Payments::CashfreeService class :)

If you have some questions around this implementation, we can discuss about it.

[vincent-pochet]

With other payment provider, this service emits/creates the payment attempt via the service provider API. It looks like this one is only creating a Payment resource in Lago database. Is it something that is missing or does it behave differently?

[AyushChothe]

I referred to GoCardless and Adyen providers, they create the Payment in the create method the same way and then update the status with the update_payment_status when the webhook is captured. Am I misunderstanding something?

[vincent-pochet]

For example, in the Gocardless service, we are first emitting a payment on the service (https://github.com/getlago/lago-api/blob/main/app/services/invoices/payments/gocardless_service.rb#L43C29-L43C54) and then creating the payment inside Lago's database with provider_payment_id: gocardless_result.id. In this case gocardless_result.id is the ID of the payment on gocardless side.
Here it seems that the create method is not emitting a payment on Cashfree

[vincent-pochet]

With stripe integration, this metadata value is passed when creating the payment on stripe. Does it apply the same way here?

[AyushChothe]

Yes, you are correct. I am not using the metadata because I am creating the Payment object using the create method. Therefore, I can safely remove it along with the create_payment method.

[vincent-pochet]

This method is used to update the status of the payment inside Lago's database when receiving a webhook from the third party service. It means that the format of the metadata even its presence will depend of each service.