Have your own great idea for a new API feature?

or maybe a suggested improvement to an existing one? Share it and become a god of the developer world.

New Idea

Hi

 

Following our recent Gap Analysis for PCIDSS Compliance, it was suggested that at the point of entering the Credit/Debit card details for payments, the PAN should be masked. This would then take away the opportunity for screen scraping where the user could screen shot the full details, or copy and paste them somewhere else.

 

After getting in touch with the dev team at Authorize, they have advised that this would be a good idea to get rolling and the best way to do this is to add it here. So here we are!

 

Many thanks

Amber

Status: Under Review

Include ACH in Accept.Js

Status: Accepted
by dnsBuffaloNY on ‎10-01-2016 12:26 PM

Accept.Js works great!  It allows my website to capture Credit Card information without that data ever posting back to my servers.  I don't any PCI Compliance headaches.

 

My suggestion would be to enhance Accept.JS to also allow for ACH payments.  That is, have accept.JS allow for the capture of a Routing and Account Number.  It could look like this:

 

var secureData = {}, authData = {}, bankData = {};
	
	bankData.routingNumber = document.getElementById('ROUTINGNUMBER_ID').value;
	bankData.accountNumber = document.getElementById('ACCOUNTNUMBER_ID').value;

	secureData.bankData = bankData;

	authData.clientKey = '6WrfHGS76gHW3v7btBCE3HuuBukej96Ztfn5R32G5ep42vne7MCWZtAucY';
	authData.apiLoginID = 'my_api_login_id';
	secureData.authData = authData;
	
	Accept.dispatchData(secureData, 'responseHandler');

Here's a related communit post.

 

https://community.developer.authorize.net/t5/Integration-and-Testing/Accept-JS-and-ACH/m-p/55887#M30...

 

Thank you for your consideration!

Status: Accepted

As mentioned in the following post:

 

http://community.developer.authorize.net/t5/Integration-and-Testing/Masked-Expiration-Date-in-Hosted...

 

The card expiry date is masked when returned in the getCustomerProfileRequest.  As the card number is masked, there is no PCI requirement that the expiry date of the card also be masked.  Without the expiry date, it makes it impossible for us to automate the process of notifying our customer's clients that their card will be soon expiring.  The reason for us going this route is to offer an ARB solution managed completely from within our application.  It is imparative for us to have access to this date.

 

The idea is a simple one.  Return the expiry date in the CIM getCustomerProfileRequest unmasked.

 

Thanks.

Status: Delivered

Approve Held Transactions via API

Status: Delivered
by andrewskaggs on ‎03-17-2016 05:48 AM

Currently, transactions flagged as suspicious and held for review by the Fraud Detection Suite can only be approved via the Merchant Interface.

 

It would be much more convenient if we were able to approve these held transactions via the API without requiring our admins to log into the Merchant Interface.

There should be a way to retrieve transaction details by their invoice number. If there is a network failure the only identifying information we have is the invoice number (not the Authorize.net generated transaction id).

 

Using the getUnsettledTransactionListRequest call is a bad choose since it only returns the last 1000 records.

Status: Accepted

Changing to Accepted, also it is now possible to return more than 1000 rows using paging.

Notice of Change reports via API

Status: Under Review
by ddri-rlevesque on ‎10-06-2016 08:27 AM

From what I understand getTransactionDetails will not provide the same information as the Notice Of Change report that is accessed via the website, i.e. corrected account and/or routing number.

 

The result of getTransactionDetails for a transaction in the NOC report is a “returned item” after the original transaction is settled successfully.  It is not until several days later that the returned item is generated. 

 

If the information provided by the NOC report could be accessed programmatically, one could correct the transaction and resubmit. 

 

Status: Under Review

Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/How-to-set-billing-info-in-CIM-...

 

Add ability to pre-load billing information into CIM hosted form.   Our customer's billing information is already stored in our system, and we do not want to force them to enter it a second time when adding a payment profile.  We would prefer instead to show the current billing information as the default values and allow them to modify the displayed information if the billing infomration is different for the credit card than what is already on file.

 

================================

 

 

In our system the user complete billing information, and when we show the form of the CIM hosted API, we need such data are loaded in the form, as we do that?

 

First we call to createCustomerProfileRequest,  with merchantCustomerId and email.

 

Then I call createCustomerShippingAddressRequest with customer billing address

 

and then, I call getHostedProfilePageRequest.

Status: Accepted

Level 3 Support Feature request

Status: Accepted
by thill on ‎02-05-2016 09:50 AM

I have just recently wrapped up an integration with Auth.net to our website and erp system using CIM and the Payment Transaction API.  Our system is passing the Level 3 data to Auth.net, but Auth.net doesn't pass this information to the processor.  I was curious about the decision for Auth to hold onto the data and not deliver it to the processors and if this feature is on the roadmap?  I would love to have the L3 data passed around, we could realize an incredible amount of savings from this (fees can be cut by up to half with this information, That's huge!). 

 

If this isn't on the roadmap, please consider adding support for this.

 

Status: Accepted

Soft Descriptor and Contact Information

Status: Accepted
by jbracken1973 on ‎11-18-2014 08:38 AM - last edited on ‎01-15-2015 11:23 AM by Administrator Administrator

The ability to set the soft descriptors for a transaction. 

 

These are the fields that a customer sees on their statements, it allows for the customer to quickly ID the transactions reducing disputes and customer service.  For obvious reasons I hope.

 

Dynamic Descriptors include:

Business Name

Phone (Best Practices says this should be a Customer service number)

City and/or State

Status: Accepted

We plan to support Soft Descriptors when supported by the processors we connect to, and have plans to add support for TSYS and Global Payments.

Idea: A read-only key that can be generated specifically for the Transaction Details API.

 

Background:

We are developing an app that only uses the Transaction Details API.

Which means we are only reading information.

 

From a liability standpoint, we want to avoid saving a write-capable transaction key.

 

Ideally a separate "read-only" transaction key could be created when a user turns on the Transaction Details API.

Status: Accepted

As we build out our integration we noticed it would nice to have some additonal search types added to the getCustomerPaymentProfileListRequest endpoint. The most useful for us would be to search by customerProfileID.  Also an expiration date range would be nice along with a paymentType (credit card or bank account)

 

A future request i could see is having the ability to have multiple searchTypes like customerProfileID and and an expiration month/year or range, or customerProfileID and paymentType.

 

Thanks,

-Nick

Status: Accepted

Support for EMV (Chip and PIN)

Status: Under Review
by paladinlogic on ‎02-11-2015 10:03 AM

We presently use Authorize.net with Iconic, our mobile ERP and point of sale solution for iOS.  As of October 2015, merchants are being required to support Chip and PIN to avoid new liabilities imposed by the major credit card companies (including VISA, which appears to own the company that provides the Authorize.Net service)  It would seem imperative that payment gateways allow for Chip and PIN transactions.  From everything I see--though I hope I am mistaken--Authorize.Net does not yet support Chip and PIN in its AIM interface (even for Card-Present transactions) despite its close ties with VISA.  All of the searching I have done through the forums and developer documentation have not produced any results.

 

We need to be able to develop our Chip and PIN solution now, well in advance of the October deadline.  Please implement this (if it does not already exist) and/or direct us to the documentation on how to pass ARQC (or equivalent cryptogram) data to the Authorize.Net payment gatway to support EMV/Chip and PIN transactions.

Status: Under Review

Hi Guys,

      Today We have faced one situatuion in my software for online payment process, i need to process the $102.00 amount using Authorize.net, but We need to get the $100.00 for One Merchant ID and $2.00 (Convenience Fee) for another Merchant ID.

 

Thanks,

Vijay.K

Status: Under Review

Despite using best security practices to protect passwords, we consider the single form authentication to the Authorize.net portal to be a critical security concern.

 

The concern is especially high with regard to CIM. When CIM is enabled, anybody breaking into the Authorize.net account can do a lot of damage (like creating transactions).

 

We are in 2015 and two form factor authentication is widespread and easy to implement. It does not have to be a full blown 2-factor with MFA devices. A simple solution - for example using a mobile phone access code - would already be a huge improvement over the current system.

 

 

Status: Under Review

Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/refundTransaction-requires-expi...

 

Currently, to refund a transaction, you must provide both the masked credit card number and expiration date.   Yet this information adds nothing to the request -- in fact, if you no longer have this information, you must issue a separate getTransactionDetail transaction to fetch this information.   Rather than requiring two separate transactions to perform a single task, only require the original transaction id.

 

Status: Accepted

Just posting here in case someone finds my post before wasting further time on this issue.

 

I have an app that uses authnet's API to take payments.  I also use their fraud detection suite, specifically for many of the IP address-related filters (velocity, shipping mismatch, regional blocking, etc).  I'd been conducting business like normal for some time, no issues.  I recently had my web host enable IPv6 for my site to get the benefits it providers for mobile shoppers who often see faster performance over v6 due to not having to go through carrier NAT for IPv4 in high density areas.  Everything seemed like it was working fine initially, but then I heard from a customer who could not pay.

 

After some debugging, we found that my payment code was populating the authorize.net API field customerIP / x_customer_ip with the customer's IP, which is obviously what it is intended for.  I was populating it with both IPv4 and IPv6 addresses.  The field is only usable for IPv4 ;if you pass IPv6, it will decline the transaction.

 

What's worse, is that since I have fraud suite features enabled, I have to pass an IP.  So what to do for an IPv6 shopper?  I can't pass a placeholder IPv4 address, such as always passing my site's own IP when the shopper is IPv6, because I'd end up triggering the velocity filter.  So ended up having to go back to not having my site IPv6 enabled.

 

I found someone asking about IPv6 and that field as far back as 2011, and authnet still hasn't caught on.  Comcast is IPv6-enabled nationwide, as is nearly every 4g cell network, so this isn't just a fringe customerbase I'm wanting to support.

 

Status: Under Review

The CIM iframe works great but lacks some display options.  For example, I use it at a newspaper where the billing and shipping info are both useful to have.  Unfortunately we cannot change the name of "Shipping" to delivery.  In the case of a newspaper, this might imply we will mail the subscription which is not the case.  It would also be nice to be able show or hide the shipping field if it wasn't needed.

 

The iframe should also support a responsively designed site.  It will position further down on the page by default when viewed on a mobile device.

Status: Delivered

Give full customization of email receipts

Status: Under Review
by merpro on ‎12-02-2015 10:17 AM

Please allow us to fully customize the email receipts. You finally allowed us to change the description of the normal recipt. Now expand that to allow customization for recipts from transactions flagged by the fraud filter.

 

In 2015 I can't even comprehend this restriction of not letting the customer dictate what the recipt should say. 

Status: Under Review
There seems to be many companies that have more than a 1,000 unsettled transactions they need to review on a daily basis. Being able to pull this down programmatically is an important feature for us to evaluate/validate unsettled transactions each day. Removing the limit on the Get Unsettled Transactions API function would be a great help! Thanks,
Status: Delivered

We have delivered this capability with an update to the reporting API methods:

 

 

Element

Description

sorting

Contains sorting information

         orderBy

Order of transactions in response:

         id

         submitTimeUTC

         orderDescending

true, false, 1 or 0

Paging

 

         limit

1-1000.

The number of transactions per page.

         offset

1-100000.

The number of the page.

 

Unsettled Transactions

The example request below will retrieve the last 100 unsettled transactions by time submitted.  With this release, sorting can be on either transaction ID or transaction submit time.

 

 

<getUnsettledTransactionListRequest>
    <merchantAuthentication>
        <name>API_LOGIN_ID</name>
        <transactionKey>TRANSACTION_KEY</transactionKey>
    </merchantAuthentication>
    <sorting>
      <orderBy>submitTimeUTC</orderBy>
      <orderDescending>true</orderDescending>
    </sorting>
    <paging>
      <limit>100</limit>
      <offset>1</offset>
    </paging>
</getUnsettledTransactionListRequest>

 

 

The resulting GetTransactionList response is unchanged apart from one new field, totalNumInResultSet.

 

Settled Transactions

Pagination works exactly the same way for settled transactions. Use the paging elements to page through a settled batch of transactions 100 at a time. 

 

<getTransactionListRequest> 
  <merchantAuthentication> 
<name>API_LOGIN_ID</name>
<transactionKey>TRANSACTION_KEY</transactionKey>
</merchantAuthentication>
<batchId>6416551</batchId>
<paging>
<limit>300</limit>
<offset>1</offset>
</paging>
</getTransactionListRequest>

 

The resulting GetTransactionList response is unchanged apart from one new field, totalNumInResultSet.