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

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

Using a GUID for Customer Profile

Status: Accepted
by KevinS on ‎04-19-2016 09:20 AM

Currently there isn’t a way to create or retrieve a customer’s profile using a GUID.    It would be beneficial to use a GUID in a customer’s profile when created and retrieving the customer’s profile information.  The current API requires the customerProfileId to be known in order to get the customer’s information.  Using a GUID to get a customer’s profile information will allow easier linking from a company’s database to the payment gateway without having to know the customerProfileId. 

Status: Accepted
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
0 Votes

I have been reading about you guys not implementing pin numbers to allow customers to enter a pin number prior to transacting a sale.  I find that makes no absolute sense by no means whatsoever.  Why would you NOT allow pin numbers and only have credit card only transactions?

 

Please, as a U.S. standard for the majority of the states allow pin numbers to be entered so card holders can feel safe that they can enter a pin number.  That should be something standard with any card swiping capabilities.  

 

 

 

Thank You

Status: Under Review
0 Votes

I need to be able to create new payment profiles on existing customer profiles at the same time as a transaction is being done, so I can skip the test transaction step. Currently, I can create new payment profiles with an authCaptureTransaction only if I also want a new customer profile. I am getting lots of complaints about the test transactions, and this would solve the problem.

Status: Delivered

This is now available through the API.

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

The CIM "Add New Payment Method" hosted form does not show an asterix before billing zip and street even though they are required fields.  Card Number expiration date, and Card code are clearly indicated as required via an asterix.

 

This will be confusing to our customers as the credit card number and expiration date fields are clearly marked with an asterix while street and zip appear optional, yet when customers hit save, they are told that zip and street are required.

 

Ideally whether or not zip and street are required fields and trigger an error message should be determined from the merchant account AVS settings, or be determined by a setting indicated when requesting the hosted form token.

 

 

Status: Accepted