10-06-2017 03:28 PM
Anyone implemented the new Visa requirement for Stored Credentials on Auth.net?
Trying to find out which fields to use for:
-POS Entry Mode Code
10-23-2017 08:57 AM
I'm looking for documentation related to this as well- 'merchant initiated' vs 'customer initiated' transaction using stored credential.
10-26-2017 04:34 PM
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!
12-18-2017 08:28 AM
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?
02-01-2018 08:10 AM
Trying to implement the below credit card regulations by Visa and MasterCard.
We are in the old system of Authorize.net, sending our transactions to https://secure2.authorize.net/gateway/transact.dll
Can you please let me know how we can adhere to the new regulations. Thank you!
02-15-2019 10:12 AM
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
02-15-2019 02:26 PM
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.
02-28-2019 03:25 PM
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 Auth.net 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.
03-05-2019 07:41 PM - edited 03-05-2019 07:43 PM
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.
03-07-2019 05:14 PM - edited 03-07-2019 05:17 PM
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?