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

Test Opaque Token

Status: New
by mlunn01 on ‎02-15-2017 12:55 PM

It would be great if there was a test token that could be used to test the server side code that transmits the AcceptJs token to the Gateway, similiar to the way one uses test credit card numbers.

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
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.

0 Votes

Full name support

Status: Under Review
by treii28 on ‎01-09-2017 10:16 AM

I see a number of posts asking about this and it's somethign we are now looking at as well. Some address database systems just store the full name to a single field. Authorize addresses seem to want separate fields for first name and last name.
Would it be possible to have this be an either/or where one of the fields (e.g. 'last name') could also be used as 'full name' and the other left blank?

Status: Under Review
0 Votes

We would like to be able to bill our clients in one currency, and have the funds settled into our account in another.  

 

As an example, we would like to charge our UK clients in GBP, and then have the funds converted, and deposited into our Australian bank account in AUD. I think it's important that our clients always know exactly how much will be deducted from their credit cards, as opposed to having it fluctuate each month based on that days exchange rate.

 

I contacted Authorize.net to see if they offer this service, and they suggested that I post the suggestion here. If this option was available, we would be happy to have multiple Authorize.net accounts - one for each country/currency that we have clients

 

Thanks

Status: Under Review
0 Votes

I'm currently working on a solution where our customers have requested a migration-tool, to tie existing CIM entries to their business partners in their ERP system.

 

In this case a method to retrieve all CIM profiles along with their corresponding payment profiles would be helpful.

 

Currently the only option is to query the API for all CIM profile IDs and then iterate them and call the API for each one.

In the sandbox environment this takes roughly 20 minutes for 4000 entries, using multi-threaded requesting. This performance is obviously pretty poor, and I imagine the method I described above would allviate this problem.

Status: Accepted

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

The Authorize.net API currently requires the cardholder's first and last names to be sent separately.

As HTML forms commonly only request the cardholder name using a single text field, rather than divided into two fields for a separated first and last name, I would recommend providing an optional field for the combined cardholder name.

Until that time, or if this suggestion is declined, I would recommend adding some additional code to the API.  If only the first name or last name is given, then take that variable and split it into two, such as shown in the code below, which is assuming that the form field "name_on_card" has both the first and last names.  The code does not take a middle initial into consideration, nor a first name with a space (such as "Mary Jo").

 

<?php
	if($name_on_card>'')
	{
		$name_on_card = post('name_on_card');
		$card_name_arr = explode(' ', trim($name_on_card));
		$card_first_name = $card_name_arr[0];
		$card_last_name = trim(str_replace($card_first_name, '', $name_on_card));
		
		$billto->setFirstName($card_first_name);
		$billto->setLastName($card_last_name);
	}
?>
Status: Under Review
0 Votes

Direct Deposit

Status: Under Review
by jays on ‎10-10-2016 02:24 PM

There are many solutions providers that are trying to integrate with a payment processors to give their clients a robust system - not only for people paying them, but for paying their employees as well - via direct Deposit. For example non profits (and many for profits) need to accept money via online (donations or payments for products and services). Authorize.net has this portion down - Hooray!!! The part we need in a full CRM - Enterprise system is the ability to make payroll direct deposits to our employees. Churches and other companies use software like what we offer to keep all their systems running but we need a processor in the back end that can handle any type of money movement ie - one bank to many banks (direct deposit), receiving money from multiple banks to one bank (paying for something online from multiple clients), making payments to vendors, and so on.

Thanks for listening.

Jay 

Status: Under Review

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

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

Many stores need an automatic return to register the conversion for Google eCommerce.  By limiting the SIM method to a manual click by the customer causes a high degree of abandonment at the payment completion stage and therefore, no conversion registered with Google eCommerce.  It does work as it should if authorize.net's domain is excluded in the Google eCommerce settings AND the customer clicks on the authorize.net receipt page button.  HOWEVER, many times, they don't.

This is aggravated by the fact that the receipt page proclaims "Thank you for your order!" in bold text that is hard-coded and cannot be changed by the merchant.  This reinforces the impression to the customer that he is done and exacerbates the abandonment issue.

The Relay Response method DOES NOT WORK correctly when using SIM, and Silent Post URL does not send the information needed to clear the customer's cart in the store. 

 

DPM is out of the question due to issues regarding that approach not actually lessening scope of PCI compliance.  Officers at companies like Trustwave state that it puts the store completely in-scope and is no different than AIM, regardless of claims that by Authorize.net that DPM lessens scope.

There are 2 things that need to be addressed and modified in the SIM receipt page:

1. There should be an option for the post back to the merchant store using SIM be automatic and not wait for user input on a receipt page. (Again Relay Response does NOT work!)

2. The field that states success on the receipt page ("Thank you for your order!") should be editable text by the merchant for situations where the receipt page IS displayed but a different message is desired.

Please consider these two minor modifications to the SIM platform.  They would be a great benefit to many, many merchants, especially those using conversion tracking systems.

Thank you.

Status: Under Review
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

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

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

It seems so stupid that this is not already available.

 

If you have an ARB subscriber for a service you are offering on a monthly basis, you would of course want to know, often and simply, if that subscriber has paid his last bill before you continue to service him.

 

But instead of a simple API function, I have to parse through mountains of data and, if I dont want to have to do this everytime someone logs in ( to check if they should be able to), i also now have to create a database table to track this status and when it was last checked.

 

CRAZY!

 

Please Authorize.net, create a simple API to do this simple check!!!

 

 

Status: Accepted

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

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

Abiility to fetch the list of required field names in the payment form  via API

Status: Under Review
0 Votes

Hi AuthorizeNet,

 

With the complexities of SAQ A, EF, D and the opportunities of globalization (i.e. en-CA, fr-CA, en-US, es-US, es-MX; North America + Mexico) it would be great to have localizable capabilities offered in your HostedForm and DirectPostMethod implementations.

 

This would simplify product integration (Redirect, IFRAME, DirectPost, and JavaScript) and allow a SAQ A or SAQ EF implementation.

 

My thought is to add hidden text fields i.e.;

 

For fields like;

 - input type="hidden" name="x_invoice_num" value="dpm3-inv3-123"

Add a new tag like;

- input type="hidden" name="x_invoice_num_label" value="Invoice Number:" .

 

This would go a long way to improving/solving localization and keeping PCI DSS to a minimum for the companies building solution with AuthorizeNet's SDK. 

 

Regards,

Rocklin Software

Status: Accepted