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

Refunds after 120 days without ECC: Suggestion

Status: New
by on ‎05-12-2020 08:54 AM

For those of you who aren't aware, Authorize.net has cancelled the Expanded Credit Capability/"ECC" program that allowed for unlinked refunds. This was the only way to issue a refund after 120 days, since Authorize.net does not retain cardholder information for the original transaction past that.

 

ECC is a very old program and it frankly sounds like a terrible idea, particularly with security standards today. It has no requirement that the refund has anything to do with the original transaction, so there is an obvious problem with anybody who has access to merchant credentials having a lot of opportunity to misbehave.

 

Our use case is pretty different and I believe that there is a lot of possibility here for Authorize.net and its customers without any additional exposure to risk, and that is the use of the Customer Proiles feature to enable the option for refunds after 120 days.

 

In an ordinary, non-profile transaction, Authorize.net has got to save the customer credit card number for every transaction. They don't want to do this a second longer than they have to, which is why the 120 day limit is there. OK, no problem. But with a customer profile transaction, they don't have to save anything that they don't already have: the customer provided their card info in a secure manner and Authorize.net will hang on to it until the customer deletes it. 

 

The API already accepts the use of payment profile IDs to issue refunds. So why not carve out an exception that allows merchants using customer profiles to issue refunds for any period of time, so long as the payment profile is still active? If the customer deletes the profile, you wouldn't be able to do this; but if they don't, the argument that "we don't have the card info to issue a refund" just isn't true. There's not a lot of potential for abuse because the transaction is still a linked refund; you're not holding on to anything you weren't already going to hold on to; and you have none of the security problems of unlinked refunds.

 

We talked to your service department about this and the suggestion was 'escalated' but not taken seriously. They thought we were asking for something just for our account. We're not. We're asking for something for everybody's account, because the current configuration of refund options is based on assumptions from ten years ago and the use of ECC to resolve the problem. Both of those things should get a fresh look with all of the new tools that Authorize.net has added since then. We are happy to assist with this process as our customers (who are sports leagues for which people sign up 8-12 months in advance) are pretty grumpy about having to write hundreds of checks when refund time comes.

Top E-Commerce Development Company

Status: New
by on ‎11-14-2019 11:04 PM

Today there are a lot of E-commerce web development companies who are been providing the e-commerce web development service. And if you are looking for the best e-commerce web development or website design companies for your website I would recommend you to go with WebClues Global. 

 

Know more abouTop E-Commerce Development Company

Top Mobile App Development Company in USA

Status: New
by on ‎09-26-2019 05:51 AM
Enhance your business with the state-of-the-art Android appdevelopment services & solutions.

 

Best Android App Development Company - WebClues Global has ahighly talented and skilled pool of Android developers who are capable of implementingthe power-packed functionality and deliver seamless apps with irresistible features to suit your business needs.
 

“Mark as spam” button on forums

Status: New
by on ‎09-21-2019 12:49 PM
The integration forum is getting inundated with spam and bots. Can we have a “mark as spam” button to get rid of them? Ideally the agents IP address could be blocked once marked as spam.

There should be a way to retrieve transaction details by their invoice number. If there is a network failure the only identifying information we have is the invoice number (not the Authorize.net generated transaction id).

 

Using the getUnsettledTransactionListRequest call is a bad choose since it only returns the last 1000 records.

Status: Accepted

Changing to Accepted, also it is now possible to return more than 1000 rows using paging.

As mentioned in the following post:

 

http://community.developer.authorize.net/t5/Integration-and-Testing/Masked-Expiration-Date-in-Hosted...

 

The card expiry date is masked when returned in the getCustomerProfileRequest.  As the card number is masked, there is no PCI requirement that the expiry date of the card also be masked.  Without the expiry date, it makes it impossible for us to automate the process of notifying our customer's clients that their card will be soon expiring.  The reason for us going this route is to offer an ARB solution managed completely from within our application.  It is imparative for us to have access to this date.

 

The idea is a simple one.  Return the expiry date in the CIM getCustomerProfileRequest unmasked.

 

Thanks.

Status: Delivered

When a webhook notification is recieved there is no way to trace it back to a customer/event/action.

 

In the case of hosted forms (i.e. Accept Hosted), none of the values (e.g. invoice number) submitted in the request for a form validation token appear in the webhook notification, so there is no way to immediately know what the webhook notification is in regards to.

 

This forces us to always query authorize.net for the transaction details to see what the transaction applies to (e.g. invoice number) and confirm the transaction is completed.

 

I imagine that a webhook notification alone is not especially useful unless it provides access to a correlation token and status. Because these values are small in size and almost definitely required by any merchant software, I feel the very small increase in payload could greatly reduce the need for subsequent queries - saving merchants as well as Authorize.net a lot of extra processing and network traffic.

Status: Accepted

Subscription Transactions?

Status: Delivered
by on ‎04-12-2017 01:15 PM

Currently, there is no easy way to get a list of transactions for a given subscription id.  To get a list of transactions for a subscription id. I load the subscription to get the customerProfileId and payentProfileId, call getTransactionListForCustomerRequest(customerProfileId, paymentProfileId), loop over the transactions returned in the response, and evaluate if transaction.subscription.id is equal to the subsciptionId I am looking for.  Furthermore, getTransactionListForCustomerRequest() uses paging, so I may need to call that API multiple times to get the collection of transactions for a subscription.

 

I am requesting there be a new API to get a list of transactions for a subscription id.  The new method would implement the standard paging and sorting.

 

See this Community Forum Discussion

 

Thank you for your consideration.

 

Accept JS Hosted Form Style

Status: New
by on ‎04-17-2019 08:17 AM

Hi,

I have reviewed all documentation and it is apparent that there is no way to style the form in the Accept JS Hosted form.  In order to do so, we would needto create our own form and submit it via JS.  Thus, opening us up to SAQ A-EP requirements; which requires a lot more time investment to manage.

 

I also understand that SAQ A requires any vendor (Authorize)offering CSS manipulation to verify all code submittedfor security. There should be a way to do this programmatically, where only a subset of CSS would be processed, and the rest eaither ignored or appropriate errors raised.

 

Not allowing styling makes for a confusing experience for the end user.  They have spent a long period of time on our site choosing items to buy, only to end up on a page that looks nothing like what they were just on. Even if it appears in a pop up, it is still a little unsettling to the user that they will be putting card data into something that looks so different.

 

It would be greatly appreciated if a method be could created to allow for the styling of the form.

 

Has or is this being considered?

 

I have seen a few other comments with regards to this, but there is no other detail than to create your own form.  There are other vendors offering this fetaure.   I would hope/expectthat Authorize.  Net would offer it too.

 

I look forward to your response.   Thanks!

When creating a customer profile and receiving the E000039 error that tells us there is a duplicate customer profile that already exists it would be useful to get that duplicate profile ID in the response other than inside the error text. While technically possible to pull it out of the error message it would be much easier and less prone to issue if we could get it back somewhere directly, such as the CustomerProfileID filed that already exists on the createCustomerProfileResponse object. 

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

Include ACH in Accept.Js

Status: Delivered
by 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: Delivered

For those who don't appreciate my efforts to build suspense and excitement, I'll come right out and say it:

 

We've enhanced Accept.js to be able to return a payment nonce incorporating bank account information (for eCheck) instead of just card information. This payment nonce can then be used in exactly the same way as any card-originated payment nonce.

 

The Accept.js documentation hasn't been updated to reflect this yet, but will in the next couple of weeks. In the meantime, the request works just like documented above. You submit a bankData object instead of a cardData object, and the bankData object contains four required parameters. accountType can be either checking, savings, or businessChecking.

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

Accepted Hosted

BillTo and ShipTo Fields that are submitted through the getHostedPaymentPageRequest are discarded if the BillingAddress or ShippingAddress is not shown on the form.

 

In my opinion, these form fields are redundant for implementations where the customer has already entered this information and do not need to be shown again. It also jumbles and overwhelms the page. What is the benefit or purpose in discarding this information when the fields are not shown?

 

The address details are critical for avs matching among other things. Also, if the customer makes changes to the shipping fields, it is important that those changes sync up on my server, which is no easy task. 

 

Please allow the BillTo and ShipTo information to pass to your system for avs processing, even if the BIlling and Shipping Fields are not shown on the Hosted Form. Thank you

 

 

Status: Delivered

Recently we had an issue where a merchant (we act as a service provider) had already refunded a transaction via the merchant portal then when attempting to refund it through our service we encountered error code 55.

We had no other way to determine if the transaction was refunded/settled other than walking our way back through settled batches closed after the initial capture's date (or calling A.net support).

So, my proposal is this: add an array of refund transaction IDs (complete/partial) to the `getTransactionDetailsRequest` response

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

Soft Descriptor and Contact Information

Status: Accepted
by on ‎11-18-2014 08:38 AM - last edited on ‎01-15-2015 11:23 AM by Administrator Administrator

The ability to set the soft descriptors for a transaction. 

 

These are the fields that a customer sees on their statements, it allows for the customer to quickly ID the transactions reducing disputes and customer service.  For obvious reasons I hope.

 

Dynamic Descriptors include:

Business Name

Phone (Best Practices says this should be a Customer service number)

City and/or State

Status: Accepted

We plan to support Soft Descriptors when supported by the processors we connect to, and have plans to add support for TSYS and Global Payments.

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

Hello,

 

The issue is that Authorize.Net is not providing a « Company Name » field on the payment form for « Accept Hosted ».

Also, sending this info through the API under the “billTo > company” tags has no effect on transaction details on Authorize.Net (the Company name is not shown on the invoice).

This is a blocking issue for my customer (and yours).

Could you please be able to provide any relevant details regarding the following issue?
Thank you in advance for your prompt response.

Regards,

Benjamin C.

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