Ideas
A place for community members to contribute product ideas and suggestions.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Options
- Mark all as New
- Mark all as Read
- Float this item to the top
- Bookmark
- Subscribe to RSS Feed
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.
... View more
As mentioned in the following post: http://community.developer.authorize.net/t5/Integration-and-Testing/Masked-Expiration-Date-in-Hosted-CIM-s-getCustomerProfileRequest/m-p/32333/highlight/true#M16895 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.
... View more
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.
... View more
Status:
Delivered
Submitted on
04-12-2017
01:15 PM
Submitted by
dnsBuffaloNY
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.
... View more
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.
... View more
Status:
Delivered
Submitted on
09-10-2018
11:27 AM
Submitted by
menudrive-myles
on
09-10-2018
11:27 AM
Hello all, We operate as a service provider, rather than a single merchant. A lot of our merchants are not too tech savvy so asking them to generate a public key (we're switching almost all merchants to Accept.JS from AIM) is like pulling teeth most of the time. Maybe when a merchant signs up a public client key is automatically generated for them or there could be an API request that generates a key for them so we can obtain the key from a 'getMerchantDetailsRequest'. Also once again: love your service, your API is much better documented than a lot of your competitors, it's much more robust and the Accept.js library is easy to handle. Myles
... View more
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.
... View more
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!
... View more
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.
... View more
Status:
Accepted
Submitted on
11-18-2014
08:38 AM
Submitted by
jbracken1973
on
11-18-2014
08:38 AM
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
... View more
Proposing that the webhook events functionality be expanded to include eCheck returns, chargebacks, and refunds. Currently these transaction types do not generate any webhook events and thus require calls back to Authorize API.
... View more
Status:
Comments Requested
Submitted on
04-06-2017
10:28 AM
Submitted by
InnovAdam
on
04-06-2017
10:28 AM
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.
... View more
Status:
Delivered
Submitted on
10-01-2016
12:26 PM
Submitted by
dnsBuffaloNY
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#M30714 Thank you for your consideration!
... View more
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
... View more
Status:
Under Review
Submitted on
08-05-2016
10:15 AM
Submitted by
vijaykalaiselva
on
08-05-2016
10:15 AM
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
... View more
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.
... View more
Since when you call the getCustomerProfileRequest and it will list all the payment profiles can you please add a field as to which one is the default one? This would be extremely useful when showing a user a list of all their profiles and which one they have set as default. Otherwise it takes a lot more unecessary coding to show all the payment profiles and then have to determine which one is the default by making additional API calls.
... View more
Created from previous thread: http://community.developer.authorize.net/t5/Integration-and-Testing/Account-updater-like-Stripe-Braintree-and-others-have/m-p/45527
... View more
Status:
Under Review
Submitted on
02-11-2015
10:03 AM
Submitted 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.
... View more
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.
... View more
Idea Statuses
- New 330
- Under Review 26
- Comments Requested 4
- Accepted 22
- Delivered 29
- Duplicate 1
- Declined 3
