kyyberi
commented
2 months ago Enabling use of Chargebee would bring along multiple payment gateways. Of course that would be vendor specific still.
Option here is to define of common features needed in the payment gateway activity, and based on that define the standard inside ODPS to describe it vendor free. Then additional application would be developed to interpret and convert the specification to vendor specific solutions like Stripe, Chargebee or alike.
The direct enablement of vendor specific solutions in the specification would lower the barrier to use ODPS right away, but would tie us to vendors and we would depend on their versioning as well.
HAving a middle ware application in between would decouple the specification from vendors, but then the needed application has to be developed.
Which problem is this feature request solving?
I've been brainstorming and experimenting with the concept of Pricing Plans as Everything as Code, and a few ideas have started to take shape.
Imagine this scenario: Once a product mockup or prototype is good enough for the customer, including predefined pricing plans, the next step in the sales process is to connect the selected pricing plan to a payment gateway (e.g., Stripe). As the product evolves—whether through updates or eventual retirement—the payment gateway settings would need to be updated accordingly to reflect the current state of the product.
Describe the solution you'd like
I’ve drafted a partial definition of this in ODPS, specifically using Stripe as a reference. While this is just a vendor-specific mockup, the goal is to eventually create a more general "integration format" in ODPS. This would prevent the promotion of any particular vendor in the specification. Instead, the generic format could be interpreted and converted into rules for specific vendors.
Drafted something already to https://github.com/Open-Data-Product-Initiative/dev/blob/main/source/examples/Pricing/pricing.yml
Describe alternatives you've considered
None.
Can you submit a pull request?
Yes.