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

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

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

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

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

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

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

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

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

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

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

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

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

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