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

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

integration with Zapier

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

Test Opaque Token

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

extend refund window past 120 days

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

Full name support

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

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

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

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