While I support this idea (sticky transactions), everyone seems to have his own set of specific requirements for the “rules” they’d like to be able to set. And if everyone was to be pleased, this would probably be a mess to configure in the app (and/or take a while before - if ever- reaching feature completeness).
Why not enable users to to do it their way by providing a callback mechanism (also known as a webhook) to let Curve know which card should be billed on a per transaction basis ?
Geeks would be quick to set it up to their own requirements, and some would probably setup one or more websites to let others do their own configurations.
For instance :
- I provide Curve with my very own callback URL : https://someserver.com/curvecallback
- when a transaction is processed by Curve, the URL is called with the appropriate parameters : curve card number (maybe partial, or some id, whatever is PCIDSS compliant), merchant name, amount…
- my own server would reply with the identifier of the card to use and Curve would process the transaction on that card
- if for whatever reason my server times out (after 500ms or so), or the reply is invalid, or whatever, Curve would just process the transaction as usual on the default card.
It doesn’t look very complex to me as that wouldn’t even require a complex auth mechanism since Curve would be the one initiating the call. And it would be a giant leap in terms of features !
Of and while we’re there, adding another “transaction complete” callback would be nice too !