[PB-6857]:feat/enable payments in INR & BRL

[jaaaaavier]

Description

The purpose of this PR is to implement everything we need on the backend to enable payments in both INR and BRL.

To do this, the first step was to add INR and BRL to AllowedFiatCurrencies and to the allowedCurrency list in the payments controller, so both currencies are accepted by the API.

Second, we introduced the file paymentMethods.ts. Previously the payment methods were decided inline with a ternary that returned ['card', 'paypal', 'klarna'] for EUR lifetime and ['card', 'paypal'] for everything else, also ['card', 'paypal'] for subscriptions. Since we now have a larger list of currencies and methods, we moved this into the PAYMENT_METHODS constant, which defines the methods to offer based on currency and interval, since not all of them are available in every country (for instance, PayPal does not support INR). Continuing in this file both UPI and PIX have per-transaction limits. We define these in PAYMENT_METHOD_LIMITS and apply them in getPaymentMethodTypes. This matters because Stripe validates every method listed in payment_method_types against the invoice amount when the invoice is finalized, regardless of which one the customer actually picked. Leaving upi on a high-value invoice fails the whole invoice with "Invoice amount_due is too large to pay with upi" and takes the card payment down with it. When the limits filter everything out, we fall back to ['card'], so the list is never empty.

We also needed to update the payment.service.ts file:

• For subscriptions we now expand currency_options when retrieving the price, stripe does not return multi-currency amounts unless explicitly requested, and we need the amount in the currency the user is paying, not the base one otherwise we would be comparing, say, a EUR amount against a limit expressed in rupees, and the check would never trigger. We fall back to price.unit_amount when the price has no entry for that currency.
• For lifetime we can't select payment methods all at once because the invoice is created empty, at that point, its total amount is 0, so there's nothing to compare with the UPI/PIX limits. The amount only appears after adding the invoice line item and the coupon. So we create the invoice with the unfiltered list, and just before calling finalizeInvoice, we read again, recalculate the payment methods based on the actual total, and update it if the list has changed. This has to be done before finalizing the invoice, because that’s when Stripe checks the payment methods against the amount, otherwise, a lifetime plan costing 150,000 INR would hit that limit with UPI still on the list, and Stripe would reject the entire invoice, including the card payment. This was a small bug I encountered while testing.

Description

This PR is related with this one so the testing process is explained there

[sonarqubecloud]

Quality Gate failed

Failed conditions
72.3% Coverage on New Code (required ≥ 85%)

See analysis details on SonarQube Cloud