Interesting solution to a pertinent problem. If I want to use this solution in the subscription workflow, is it mandatory that one uses the same APIs for the customer login use case also?
Thats the goal of the post. No solution will cover every problem for scaled up businesses; hence no-code is always a myth and code needs to be written.
The larger goal of the payment solution is not be be fully complete and call itself as the one-and-only no code. It is to create open source and reusable code to avoid the repetitive work for developers..
"Transactional models are flexible pricing where customers only pay for what they have used during the period. In the UB subscription model, customers commit to their desired level of usage."
How does that make usage based pricing better than transactional? Is it because the commitment in UB pricing will reduce the unit price comparatively?
Both transactional and usage-based subscription are usage based models because the metric you are billed on is tied to usage. In one, there's no minimum cost (think twilio) and in another there's tiers of usage (hence subscription) - like Zapier where you can only buy Zaps in specified blocks. So if you want to use 433 zaps, you will still be billed for 500. So it's kinda like a subscription.
