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
0 Votes

Currently, there is no method via the API to validate and reconcile ACH payments from echeck transactions made to our bank account.  Payments received into our bank account do not contain any tracking numbers or relation to which batch(s) are included in the payment.  Therefore, we cannot finilize the confirmation of payment per person based on teh ACH deposit.  According to Authorize.net support, the only way to determine which batches are included in a given payment is to manually review the Funding Calculation immediately prior to the ACH transaction.  We find this cumbersome and unrealistic in a production environment.  Instead, we propose additions to the API.

 

  1. List ACH deposits: to provide a full listing of ACH deposits to the merchant account with deposited amount by date range
  2. List ACH deposit batches: Per ACH deposit, list batches included in the ACH deposit with $ amount per batch
  3. Currently, there is a 9 digit number provided in the ACH deposit info from Authorize.net.  We assume that number is an ACT payment id.  The API should provide a method to query by that number to retrieve included batch id numbers, transaction amounts, and deposit amounts.

Without at lease 1 & 2 above, there is no API (a.k.a. automated) method to validate receipt of funds per batch and transaction which leaves the merchant exposed to missing failed deposits or other ACH issues.

 

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

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

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
0 Votes

Right now, connection details logged from HttpUtility at the debug level include a great deal of useful information along with

 

- the api login and transaction key

- full dump of the xml request including unmasked credit card number, expiration date, etc.

 

Can we move the logging of these two items to a separately-configurable logger like "HttpUtility-sensitive"?

 

I'd like to see the api login and transaction key logging go away completely from the HttpUtility output.

 

ideally, I'd like to see the xml request filtered to not show any <payment> information beyond a generic  <creditCard> output.  (I suppose masked credit card number would be acceptable).

 

I think it would also be wise to not output <billTo> information nor <customer> information with the non-sensitive-data logger other than  <customer><id> even though this is not strictly required by PCI DSS.

 

We want to log when transactions occur with enough context to know what those transactions are without making our logs a security risk.

 

Status: Accepted
0 Votes

One of the problems with using CIM hosted forms is that it's difficult to determine what profile information has changed (payment profiles added or edited).

 

Another issue is that it's difficult to provide an audit trail which identifies who initiated the changes.

 

One possibility that could address these issues is specifying some kind of reference id (not the per-transaction refid field) in the getHostedProfilePageRequest which would be assigned to each payment profile (or shipping address, although this is not something I use) which the end user created or edited using this token.   Or it could be the token itself.

 

Then return that identifier for each payment profile (or shipping address) returned by

getCustomerPaymentProfileListRequest.

 

End-developers can easily identify which payment profiles were modified by a specific token consumer.   We can also provide an audit trail of which token consumer modified a record most recently.Comments?

Status: Under Review
0 Votes

There needs to be a way to verify if a transaction has already been posted or not in order to help eliminate possible payment duplication.  This could work by searching for an invoice number, date, and possibly even a payment amount; and get a list of all transactions where there is a match.  This way I can make sure my application isnt trying to charge a second time when it should not.

Status: Accepted
0 Votes

Support 19 Digit Card Numbers

Status: Accepted
by jmagaro88 on ‎01-24-2017 06:30 AM - last edited on ‎02-13-2017 04:13 PM by Administrator Administrator

A customer on my site just attempted to place an order with a valid Discover card number that is 19 digits long. Apparently, Discover and Visa have begun rolling out valid cards with 19 digits. The card passed my Luhn algorithm validation and was passed to Authorize.NET for authorization. The XML request was sent succefully; however, I received the following error response from Authorize.NET:

 

The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber' element is invalid - The value XXXXXXXXXXXXXXXXXXXXX is invalid according to its datatype 'String' - The actual length is greater than the MaxLength value.

I checked on the Authorize.NET documentation, and it appears that only card numbers between 13 and 16 characters long are supported. When will this be changed to accommodate 19 digit card numbers?

Status: Accepted

Converted community thread to an idea and changed to accepted.

The current minimum 7 day interval for ARB makes testing impossible.

Developers need a shorter interval, for example 1 minute, to be able to test their applications.

Status: Accepted

Currently it doesn't appear that you offer a service like many of your competitors to automatically update card expiry dates that are stored in the system. It would be VERY beneficial for anyone doing recurring payments (either manually or via your automatic system) to be able to get the latest expiry information.

0 Votes

extend refund window past 120 days

Status: Under Review
by mwh on ‎01-24-2017 08:22 PM

A credit card payment can only be refunded for up to 120 days without having to resort to using ECC.  ECC is cumbersome and creates PCI compliance hassles.  Competitor gateways can often refund transactions up to a year after they happen.  

 

Please extend the non-ECC refund window to 365 days.

Status: Under Review

The ID of a duplicate customer profile is returned, but not when it is a payment profile: "A duplicate customer payment profile already exists." These requests date back to 2009, it forces us to loop through the payments and try to guess at which one is the duplicate and doesn't always work since customers can still generate duplicates anyway by updating existing profiles. It would be nice if there was a way to get the ID of the duplicate payment profile, or if there was a way to disable the duplicate verification check completely, since what some merchants really need is just a "I give you a PAN, you give me a token" level of tokenization instead of futzing with profiles. Thanks.

Status: Delivered
0 Votes

Javascript payment integration

Status: Delivered
by Administrator Administrator on ‎10-29-2014 01:57 PM
Status: Delivered

We now offer Authorize.Net Accept.js, a javascript library for accepting payments while reducing PCI scope:  http://developer.authorize.net/api/reference/features/acceptjs.html

0 Votes

Get Refundable Amount for transaction

Status: Under Review
by VitaliyGer on ‎04-04-2016 03:19 AM

Add a feature, that will allow to retrive an amount of transaction, that was not refunded yet.

 

I.e. original order with 5 items was made for 50$ and transaction was authorized and captured.

Customer returned 1 item and refunded 10$.

 

Need an API method, that will allow to retrive the amount, that can be refunded.

 

Right now there are 2 ways to solve this case:

1) POS side tracking. This methods requires huge amount of analytics on server side and may cause the data to be incorrect if system has multiple clients, that has their own storages.

 

2) Cashier tries different amounts to guess which one is available.

Status: Under Review

It is unclear whether or not Authorize.net supports readers where the manufacturer is able to perform key injection of an encryption key provided by Authorize.net.   This seems like a straight-forward concept that should be documented on the mobile reader support page.  Forum posts (other than mine) indicate confusion about this issue.  Unfortunately, the support reps don't really understand the question and can only answer based on what they read from the site, so calling support does not help.

 

Status: Delivered

The list of supported devices is maintained at https://support.authorize.net/authkb/index?page=content&id=A1574

 

Richard

We'd like to proactively email customers who have credit cards about to expire. It would be very helpful to have one call that would return all those customer ids with payment profile id(s) and expiration date.

Status: Delivered

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
0 Votes

I would like to have nested filters with the fraud detection suite.

Status: Comments Requested

We're looking for more input on how you would like this request to work.

Declined Transactions Emailed to Us

Status: Declined
by Liquid on ‎11-13-2014 07:19 PM

We need the DECLINED / Non-Payments to be EMAILED TO us. I have ALSO asked for this easy and basic functionality for years. We have recieved nothing but a "we are working on it" response for YEARS. It's beyond frustrating.

 

It's a very simple task. It is ABSURD that you do NOT have this option yet.

 

We NEED to have the DECLINED Payments (and not just successful payments) EMAILED directly to various admins here at our small business AND the reason for the decline (i.e. incomplete payment or expired credit card).

 

Please advise on when this will actually be impleted. Thank you.

Status: Declined