A place for community members to contribute product ideas and suggestions.
A place for community members to contribute product ideas and suggestions.
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.
I was advised to submit an idea here.
When printing a receipt in Google Chrome, clicking on "Print using system dialog" closes the window. This happens in production as well as the sandbox.
Account Updater deletes Payment Profiles stored in CIM due to the fact that they are marked as "closed" by the issuing bank. However, some customers continue to re-enter the same card details month after month showing that this is fact a false positive.
When attempting to process a payment against these cards, they are succesful, and don't return a closed status. There is a flaw in the data passed by the banks to account updater, or in updater itself.
In my limited testing, I discovered this was happening to several % of my cards every single month costing me thousands in revenu in a pretty short amount of time.
Several other Authorize.net users have noticed the same problem
My guess is that if everyone who used CIM and account updater looked at their monthly updater report, and checked the last 4 of cards deleted, they would find that it's deleting some of the same customers credit cards every single month!
The account updater sales page states that, "It costs 7 times more to get a new customer than to keep a current one." yet account updater is deleting active card data every single month.
Three potential solutions:
Since I've been told by customer support that this can't be fixed, I would like to point out that Stripe does not have this same problem with their account updater, and in my testing, my card churn rate was much lower with Stripe.
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!
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.
When a customer does not enter the correct credit card details, there is a warning sign added next to the credit card as well as the field's underline becomes red. This is fine but when customers are on smaller displays, they need to know to scroll back up the form to find the error.
The suggestion here is to add an error message just above the "Pay" and "Cancel" buttons (just like some of the system errors like the "declined" messages) which describes to the customer what the problem is so they know to scroll back up to fix the issue.
We are seeing significant problems with our customers and they wind up canceling the transaction!
I'm trying to find out if there is an API call that will return whether or not CIM has been enabled on an account or not.
Right now we have the occassional customer who has initial issues with our payment implementation, and it often is a result of them (our customer) not having CIM enabled in their Authorize.net account. I would very much like to be able to programatically do a check for whether or not CIM is enabled.
Oh, and it would be ideal if the call didn't return a response that "implied" the anwser of whether or not CIM was enabled, but rather explicitly stated it.
There needs to be a way to quickly get any "returned" eChecks. By law, a consumer has 60 days to dispute a charge, and normal ACH transactions can take several business days to return NSF (or any other number of errors).
I can think of two ways to solve this
1) Include the Original Transaction ID in the new Transcation.
2) create new API getReturnedTransactions(startDate, endDate)
As it stand currently, I have to put transactions in a temporary database with the date performed, and then check every transaction in the temp database every day for a "returnedItems" array in the getTransactionDetailRequest() call, and once it is day 61 after the original transaction, I can delete it from the temporary database. As you can imagine, this leads to thousands of useless calls.
A single transaction, perfomed on 1-Dec 2018 has to be checked 60 times through 29-Jan 2019 to know for sure it never came back disputed.
If 10 Transactions are processed every day, for 60 days, 600 API calls are performed to charge the accounts, and then 35,400 api calls are performed to check each of the 600 transactions (Days 60 has to be checked through day 120). These figures are assuming the charge, settlement, and ACH withdrawel fromt the customer account happen almost instantaneously, which they don't).
Example can be provided to Authorize.net Staff from our production account.
Currently, eCheck deposits to the merchant have the fees taken out. This makes it much more difficult to reconcile on the accounting side. Anything that adds to the daily/monthly grind is something I want to avoid. I'm considering leaving Authorize.Net for this one reason. What would it take to have eCheck deposits be the full amount of revenue received, and take out the fees as a separate transaction?
First, thank you for your amazing products and solutions. The more I use this the more I like it. This may not be the precise purpose of this forum, but I have a suggestion related to your sample apps-
The common theme I notice is that the sample apps often have the maxed out best possible that can be obtained for a given solution i.e. the Accept Hosted Iframe app. I fully appreciate the need to show and the benefit of showing what is truly possible with your products, but in helping others here and also in doing online searches during my own development process I have found that your sample apps are confusing quite a few people, for whom the fully decked out implementation may be an aspirational goal and not what they are immediately looking to acheive.
I would suggest making maybe a few sample apps, with one being a minimal integration that the developer can build on to suit their needs, and then your fully decked out showcase model for the advanced users. I think this would help many developers speed up their development process.
Thank you again. I cannot say enough how great your service is, from your API to the awesome people on the phone and the people on the forum.
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
I have tried to refund amount using ONLY trasaction ID, but i unable to succeed.
I have using following code Please clink on below link.
Please make api for refund only and only using transaction ID. There are no need of any card nunber, customer profile ID, Customer Payment Profile ID etc.
How you think about this IDEA to make refund using ONLY TRANSACTION ID?
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.
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.
It would be nice to have proration invocing feature.
It would be useful in following scenario (which is common in any subscription based payment):
Suppose I've ARB subscriptions that charges for every 3 months and has a trial period of one month. I need to charge for anything(can be features or devices) added in subscription after trial period.
For example, if some feature is added to a plan during second month then I need to charge them for remaining days of that billing cycle (so, charge amount = 30 + extracharge).
I know, I can update subscription in ARB to charge them from next billing cycle and I can do one time charge on customer profile for that extra charge.
But for this, I need to get unit price(charge per day) and since number of days in month varies the unit price also changes.
It would be nice if this calculation is done by authorize.net.
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.
The identifying information that's included in Silent Posts (x_cust_id, x_subscription_id, etc) should always be in webhook transactions, if not just everything in Silent Posts. I know about refId but that's of no use to companies using ARB for recurring billing, which is 99% of our transactions.
This is making my migration to Webhooks difficult. Your support staff has obviously been instructed to push everyone to webhooks if they're using Silent Post right now but the glaring omissions of functionality in webhooks is just absurd.
The only solution is to query the Authnet API for information on the transaction ("getTransactionDetailsRequest"). The response that comes back from that query is very detailed. That detailed response should just be webhook. Why the heck not? Come on now.