Open aseigo opened 7 years ago
Yes this definitely makes sense to have, especially if we start implementing features that some payment providers do not support.
I too have been thinking about automatic routing based on pricing, however I am yet to come up with a good way to keep the pricing data up to date without manual maintenance.
I am yet to come up with a good way to keep the pricing data up to date without manual maintenance.
Probably requires some use case gathering to understand what is actually required and useful to know. As this will hopefully be a (largely?) internal calculation based on configuration data it should be possible to implement a "naive" calculation mechanism which can improve / be obfuscated by reality ;) over time.
But just having the metadata there as a first step would be good.
I think there would need to be some research into how the different providers charge, some are per transaction (e.g. PayPal), some per batch of transactions (e.g. SagePay) and possibly some other forms that I have yet come across. Although I'm sure we could come up with an easy way normalise these structures into something that would allow the module to easily compare the costs of a given request.
But just having the metadata there as a first step would be good.
Absolutely, small steps lead to big gains :smiley:
Would it make sense to allow gateways to return what features they support? e.g. a simple map like:
%{ methods_accepted: [:mastercard, :visa, :ec, :maestro ], currencies: :all, regions: :global, subscriptions: true, ... }
This would allow automatic routing/deciding in future, as well as being able to know which gateways support things like subscription services? Could be extended in future to include preferences and/or cost information to allow choosing "cheapest, most preferred, available gateway" for a given purchase?