I guess it will take a long time (years?) to implement the smart rules as requested by different people. Although, I think that providing a text rule based on transaction description (which usually includes the merchant’s name, as well) would probably cover 90% of most people’s needs.
However…
If you really want to give flexible tool for people that need it (and are willing to pay for it), consider doing the following:
Just have an option for an (internal or external) web-service through an URL. Provide all the available transaction data in an XML format, then POST this XML to a user-provided URL. Read the reply and parse the answer from the returning XML, then act upon it.
Here’s an example:
<transaction id="hjsd732abd623">
<amount>12.35</amount>
<currency>EUR</currency>
<description>Amazon.de</description>
<MCC>34</MCC>
<time>2022-06-17T12:40:33.183</time>
<categoryId>6</categoryId>
</transaction>
And the webservice would answer with something like this:
<selection id="hjsd732abd623">
<cardIndex>2</cardIndex>
<categoryId>8</categoryId>
</selection>
Needless to say, one could do just about anything with this approach. You just provide every bit of transaction data that can be safely shared (of course, underlying use of SSL encryption is expected), and then just leave it to the user to choose the underlying card under whatever algorithm he chooses to implement.
You could also provide a small hosting service for people who do not own (and do not wish to own/rent) any webserver space by simply letting people upload their algorithm source code through the app, and then executing the simple if-then-else script on your own server. You could use Javascript, PHP, or whatever is the simplest for you.
But in general, I think you should let people (who know how to) provide their own decision logic, to be implemented however they choose and hosted wherever they choose - you only need to know the URL where to post the transaction. Of course, for safety reasons and execution speed, you should treat any such script with some care:
- if the called webservice doesnt return in, say, 500 milliseconds, you stop waiting and proceed as normal (as if there was no script)
- if the returned content is longer than, say, 100 characters, you simply drop it (somebody is trying something funny)
- if the returned content is not parsable as XML, you simply ignore it
- if the returned content doesn’t adhere to specified XML schema, you also ignore it
I think this approach would be great. It would give everybody a chance to do whetever he wants and enable to few of those out there, which would like some more complex logic (based maybe on some external data, like, whether the available amount on some underlying card is sufficient or not, which could be gotten in real time by calling some other webservice in the background, etc…) the ability to really push this, if needed. Just give me 500 ms of timeout and let me work out the answer for you, ok?
The answer, of course, is the network-safe id of the underlying card which should be selected and possibly the Curve category under which the transaction should be filed. Both pieces of data in the response are optional, one would be allowed to use either one of those, or both at the same time.