Showing results for 
Search instead for 
Did you mean: 

Visa Stored Credentials

Anyone implemented the new Visa requirement for Stored Credentials on


Trying to find out which fields to use for:

-POS Environment
-POS Entry Mode Code


I'm looking for documentation related to this as well-  'merchant initiated' vs 'customer initiated' transaction using stored credential.


Payment Gateway and Merchant Services Consultant



In general terms, there are two kinds of things we do in response to scheme changes like this. When a processor or scheme needs a certain flag set or certain information sent, and we know enough about the transaction or environment to send that for you, then that's what we do. If that's not possible, then we typically expose an additional API field to allow you to pass the information to us.


With this particular set of changes, there are certain things that would be invisible to the merchant. For example a transaction sent using our Customer Profiles features can be flagged by us automatically as a stored credentials transaction, since we know the credentials were stored (we're the ones storing them after all). Another example: subscriptions set up through our Subscriptions API can be properly flagged as recurring.


For other transactions, we do have a recurringBilling flag that a developer can set in the transactionSettings element to indicate recurring.


We're a bit hamstrung by the fact that processor networks are either just barely rolling out support for these mandates or are still in the process of developing support. So, it doesn't necessarily do any good for us to provide new fields to send new information if that new information can't be sent anywhere yet.


Once our supported processor networks have all finished their updates, then we can see what specific fields might need to be exposed to the developer to send further information with the transaction. Stay tuned!



Our e-commerce solution generates its own token so we would need a field that would allow us to notify Visa that we used our token for a transaction.


Are there any updates as to when a "Stored credential" field would be added to the API?


Best regards,, 


Trying to implement the below credit card regulations by Visa and MasterCard.


  • Account Number Verification authorization – so that we can save the credentials in our side. 
  • For transactions initiated using Stored credential,  need to send ‘C’ or ‘R’ based on the transaction –  POS environment field.
  • For transactions initiated using Stored credential,  need to send (Credential on File Value) – ‘10’ - POS Entry mode code field.
  • For Returns, we need to send authorization message (value of ‘20’), for Processing code field.
  • Need to send Transaction Integrity Class (TIC), to send it in settlement.

We are in the old system of, sending our transactions to 


Can you please let me know how we can adhere to the new regulations.  Thank you!

Is there any further update on this subject?


We do not use (or want to use) Customer profiles or the Subscriptions API but still need to get these fields over to the processor somehow



Authorize.Net does not currently support the Stored Credentials rules (aka Card-on-File, Cardholder-Initiated Transactions, and Merchant-Initiated Transactions). We do not have timelines for when we will release such support.


In the interim, please work with your Merchant Services Provider to request an extension from Visa, and other card networks, in regards to any deadlines.


Thank you.

Authorize.Net Developer Authorize.Net Developer
Authorize.Net Developer



Can you clarify a few things for me? I'm currently not using the recurring billing api, but I am setting the recurringBilling flag in the transactionSettings element to indicate recurring as Aaron stated above. In this case is it possible for to set the POS entry mode to "10" for Visa and Mastercard transactions? As the payment facilitator setting that flag to true should indicate that we have the credentials stored and so you can pass on the entry mode code for stored credentials. 


I'm running into an issue with our mutual customers where MasterCard is going to reject all of the orders they think are recurring because the POS entry code is not being sent to them.


If you're not able to automatically send the code as Aaron suggests, could you please provide us a new API field so we can send it to mastercard and Visa. Small businesses asking for an extension is not an ideal solution if there is no known timeline for the solution to be in place.


Thank you



At this time Authorize.Net does not expose the API fields you require nor can we automatically set the appropriate POS Entry Mode (and any other fields) to ensure compliance with Visa/MC Card-on-File/Stored Credentials mandates. We do not have a timeline at this time for when such features will be available.

Your Merchant Services Provider may also be aware of these compliance requirements and may be able to help with getting waivers from Visa and MasterCard for these rules.





Authorize.Net Developer Authorize.Net Developer
Authorize.Net Developer



I was recently tasked by a client to follow up on this topic before they can decide whether they will try to get an extension through their Merchant Service Provider or look into changing payment processors that support this mandate.


The client's project uses the Authorize.Net APIs to allow users to make one-off transactions (auth-capture) as well as use the CIM related APIs to allow user's to setup payment profiles and make payments using those profiles.


I have ready your last couple responses and I know this is probably redundant, but I want to be 100% sure since you were responding to questions about custom integrations and Aaron mentioned something about possibly automatic setup data.   Are you saying that Authorize.NET has no current support for the Stored Credentials mandate at all, even when using the API and the CIM to make payments?  So, even if createTransactionRequest is called with a profile specified, behind the scenes the POS Environment and POS Entry Mode Code fields will not be populated by Authorize.Net?


Thank you