Posts: 13
Registered: ‎11-10-2016

Multi-Tennant concurrency issues

As a SaaS platform, we have many (100's) of customers who use our platform to connect to for payment processing. Each customer has their own unique login-id/key for authentication and processing. Put another way, since we have 100's of customers, we are connecting to 100's of accounts through the gateway. 

We use .NET for our development and use the .NET SDK provided by Anet.


Looking at a common example, submitting a payment for settlement,


The C# version uses static methods on an anymous class for authentication (RunEnvironment and MerchantAuthentication).



Console.WriteLine("Charge Credit Card Sample");

            ApiOperationBase<ANetApiRequest, ANetApiResponse>.RunEnvironment = AuthorizeNet.Environment.SANDBOX;

            // define the merchant information (authentication / transaction id)
            ApiOperationBase<ANetApiRequest, ANetApiResponse>.MerchantAuthentication = new merchantAuthenticationType()
                name = ApiLoginID,
                ItemElementName = ItemChoiceType.transactionKey,
                Item = ApiTransactionKey,

            var creditCard = new creditCardType
                cardNumber = "4111111111111111",
                expirationDate = "1028",
                cardCode = "123"



It is my theory that the .MerchantAuthentication is not thread safe and during high usage scenarios, multiple threads can have their authentication information overwriten if they are accessing this method at the same time. This leads to disasterous results, where PII and Payment information is being sent to incorrect merchant accounts for settlement. 

We have opted to instead pass the credentials in as a parameter for each request, as @pepper and @kevinfairchild have indicated here.


merchantAuthenticationType myMAT = new merchantAuthenticationType {
    name = "API Login",
    ItemElementName = ItemChoiceType.transactionKey,
    Item = "Transaction Key"

createTransactionRequest myRequest = new createTransactionRequest { transactionRequest = myTR, merchantAuthentication = myMAT };


If this can be confirmed by official staff, I would appreciate at least a mention of this risk in the official documentation. And mentionining this overload constructor so that folks are aware.


 Thanks again to @pepper  and @kevinfairchild for the tips.