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.
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:
And the webservice would answer with something like this:
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.
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.