As a SaaS platform, we have many (100's) of customers who use our platform to connect to Authorize.net 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 Auth.net accounts through the gateway.
We use .NET for our development and use the .NET SDK provided by Anet.
https://github.com/AuthorizeNet/sdk-dotnet
Looking at a common example, submitting a payment for settlement,
https://developer.authorize.net/api/reference/index.html#payment-transactions
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.
https://community.developer.authorize.net/t5/Integration-and-Testing/C-DLL-and-IIS-Hosting-Using-man...
Example,
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 Authorize.net 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.
