...
In this solution we would have the flexibility of a more dynamic change, but we would be linking the feature to the feature flag and adding another flag to the system.
The change needed to add the flags is just a change in the paycomet-credit-card-form.tsx file. To do this, you need to create a component to add the flags and call it after paymentJetId is enabled, as it defines when the form is ready to be displayed to the user.
Expand | ||
---|---|---|
| ||
|
Expand | ||
---|---|---|
| ||
|
Feature Flag
Variations |
---|
["MASTERCARD", "VISA", "AMEX"] |
✅ Pros:
Quick implementation / less complex
Ease of changing card type values
...
The number of feature flags (eg: dev plk es, dev plk pt, dev bk es, dev bk pt and etc) created for each region/environment is high due to the way the frontend FD is created.
Solution #3 - Get accepted cards in the backend with launch-darkly
...
Ease of changing card type values
Endpoint already implemented
Scalable solution for all countries of a given Brand
Cons:
Added another request to userAccounts to obtain feature flag data
✅ Proposed Solution
Solution #2 - Get accepted cards in the launch-darkly
The change needed to add the flags is just a change in the paycomet-credit-card-form.tsx file. To do this, you need to create a component to add the flags and call it after paymentJetId is enabled, as it defines when the form is ready to be displayed to the user.
Expand | ||
---|---|---|
| ||
|
...
title | payment-method/index.tsx |
---|
...
Addition of the feature flag value request, which would increase the endpoint delay a little.
✅ Proposed Solution
Solution #3.3 - Get accepted cards in the launch-darkly
...
To configure the feature flag correctly, it is necessary to enable the feature flag and configure the variations to add the values of the accepted card types. For example:
Solution #2 - Get accepted cards in the launch-darkly
...
Variations
...
Solution #3.3 - Get accepted cards in the launch-darkly
...