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

It would be very helpful if the Accept Hosted payment form iFrame Communicator could send a communication indicating when the payment form is fully loaded in the iFrame.

 

We are seeing issues in some browsers (especially Safari) where scrolling while the form is still loading (before the iFrame has been resized) can result in portions of the form being hidden and no scroll bars to bring it back.

 

If we had notification of the form being fully loaded, we could block pointer events and scrolling for the iframe until after the the page is fully loaded.

Status: Under Review

Webhooks for failed transactions

Status: Under Review
by schammy on ‎08-06-2018 12:21 AM

Please add a webhook for failed transactions, no matter the reason (expired, processing error, general error, whatever).

 

I'm not sure what kind of company wouldn't want to know immediately and automatically about a failed transaction, especially if it's for a subscription (ARB).

 

Silent Post does this and we're trying to migrate away from it per customer support advice but glaring omissions like this are making it near impossible.

 

The only solution is to either constantly query the API for unsettled txns to find failures (if we want to know about them immediately, which we do), or if we didn't mind waiting up to 24 hours then we could query once per day for the entire batch for the previous day to get all transactions and find the failed ones - but this is 2018 damnit, everything should be real time.

Status: Under Review

Test Opaque Token

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

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

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

 

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

integration with Zapier

Status: Under Review
by 4aGoodCause on ‎03-03-2017 08:40 AM

Does Authorize net have plans to integrate with Zapier? It is has been listed on their website as "upcoming" for over a year. When will it come? 

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

With Accept Hosted, when a successful transaction is done, a message displays that says, "Thank-you for your business!"

This message should be editable, as it assumes a particular type of transaction just took place, when it could be many things.

 

Thanks,

Mark

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

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

When using Authorize.Net Accept Hosted in an iFrame, the "Description" and "Invoice Number" areas are too narrow to read easily.

For example, see this screenshot: https://monosnap.com/file/HFdx6i4XhyZhoflYF9iE5i6rOkUZPD#

 

We are working around this by forcing the iFrame's container to have a minimum width of 400px, which is sufficiently wide for the Description and Invoice number to look better, but it's not the ideal solution because then mobile users need to scroll left and right to read everything.

 

Ideally, if the iFrame's area is more narrow than 300 px or something, the contents of description should fall BELOW the title "Description", and likewise the invoice number would fall under the title "Invoice Number".

 

Eg, instead of

 

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

Description {contents-of-description}

Invoice Number {invoice-number}

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

 

on narrow screens, it should become

 

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

Description

{contents-of-description}

Invoice Number

{invoice-number}

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

 

This would make better use of the limited horizontal space.

And yes I realize you can customize the form however you like if you use Accept.js, but I think this is a pretty general issue (experienced by anyone who actually tests their payment form on a mobile device) so it would make sense to fix it on the hosted solution. Besides, the fix should only require a few CSS tweaks.

 

 

Status: Under Review
0 Votes

We just started using the in-person iOS SDK. Holy Hell, the UI is bad.

 

Can you make the signature box transparent, so that it matches whatever we set the background color to. Then just give it a border that's the same color as the text font color (if you don't want to add another setting).

 

And can we set the font? Or can you pick a better one, please.

 

 

 

Status: Under Review
0 Votes

 

Currently, AuthNet returns an error if the order of JSON object elements is not exactly as written in the API documentation.  Since the JSON spec allows for object elements to be in any order, standard serialization tools on various development platforms don't construct JSON strings as AuthNet prescribes.

 

Removing the order restriction would greatly simplify the work requried to integrate with the Authorize.Net API.

 

Thanks!

Status: Under Review
0 Votes

We are successfully using the Authorize Accept hosted forms but we have a couple pain points that perhaps might be fixed on Authorize's end. We're not using the iFrame implementation and are sending visitors to the hosted form where when they complete a transaction it takes them to an Authorize hosted Thank you message and a button in the top right to go back to our website.

 

What we would love to happen is the visitor bounces off our site to Authorize to complete the transaction and instead of displaying the Authorize final page, it would email the receipt and redirect the visitor to our site where we could display a more robust thank you message. It appears this is only possible with the iFrame method but could it be engaged for the non-iFrame implementation as well?

 

If that is not possible, could we have the option to move that upper right button so that it gets more focus. Right now, we have our button titled "Complete transaction" (even though the transaction is technicaly already complete) because we rely on people clicking it to send them a more stylized and formal "thank you" for their donation. If we can't automatically redirect a donor to our page, making that button more prominent would help to ensure people are returning to our site.

 

Thanks for any updates!

Status: Under Review
0 Votes

In createTransactionRequest we are able to create a new customer profile from data which was sent in this API call by setting <createProfile>true</createProfile> flag:

 

<profile>
  <createProfile>true</createProfile>
</profile>

Since customer is only being created after transaction is set, and not assosiated with it, any of  GetTransactionList, GetUnsettledTransactionList and GetTransactionDetails API calls will respond with empty customer profile field.

 

Flag <createProfile> only declares that profile will be created, so this is an expected behavior. But also it might be usefull to associate customer profile with transaction where it was created. A new flag might be added to avoid changing <createProfile> strict behavior, and at the same time add more flexibility to this call:

<profile>
  <createProfile>true</createProfile>
  <associateWithTransaction>true</associateWithTransaction>
</profile>

, or something similar.

 

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

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