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.
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
It would be convenient if Authorize.net would create and support an npm package that contained the production and sandbox versions of Accept.js.
I am implementing a solution in Angular and currently have copied and pasted the file contents and put them in my application.
Hello Authorize.net Community. We have recently implemented the new Accept hosted mobile optimized forms and we wanted to know if anyone has any success in hiding some of the following fields:
Unfortuantely that function the option to show or not show the billing address options and that is by setting the property for hostedPaymentBillingAddressOptions https://developer.authorize.net/api/reference/features/accept_hosted.html#Requesting_a_Token allows us to disable all of the billing fields and our challenge is that we only want to enable the address fields that are required (i.e. Street Address, Zip & Phone). Based on our research and your responses from your forum, it looks like this is not possible. Hopefully your teams can consider these non-required fields as definable options separately in the future.
Thank you in advance for your consideration.
I have implemented accept hosted form into iFrame and embeded that iFrame into my main payment page.
Now my payment page has a cancel and previous button itself. so, after integration of accept hosted form there are two cancel button in my page.
We are looking for such a feature by which we can show/hide cancel button in accept hosted payment page.
Hi there, we absolutely LOVE the new online invoicing feature - its super simple and most importantly, it makes running our business easier!
Are there plans to add a "recurring" feature - the ability to automatically send the same invoice, to the same person, on a monthly basis? We have a category of payments that we collect on a monthly basis that having a recurring invoicing feature as part of the new invoicing tool would eliminate the manual re-entry every month.
For the developers if they want to control over showing pay, cancel option, they cannot currently.
When the pay option is clicked, customers are selecting cancel option. But, the form is not cancelling the transaction to proceed. But, customers are not unaware and they are submitting another transaction. More details here.
Can we have the following so that developers can have the option to hide in the form? this helps the merchant customers not to cancel after they click pay.
once the pay button is clicked, disable the cancel button so that end-user doesnt have an option to select cancel.
I have a scenario where I'm performing an authorization with a payment nonce, then creating a profile from that successful authorization, and later capturing the authorized amount. This is a nice workflow because I only create a payment profile if the authorization succeeds.
But unfortunately, this workflow is not possible because the authorization is not associated with the payment profile, and doesn't show up under its history. In a scenario where we're using a profile for recurring transactions, it's a big deal to us to have the initial payment in the history.
See this thread for more details as to alternatives that are less ideal.
It'd be very helpful if, when I create a profile from a transaction, if that transaction became the initial transaction in the payment profile's history, and I was able to capture it as though it had been issued from that profile.
We get notifications for a normal subscription transaction, but what of the trial transaction?
Isn't it weird that we have no notifications for this? like it is a ghost transaction. But it exists and we should be notified about it.
Recently I started implementing ARB on application (using php-sdk) and the implementation went smoothly until I hit a road block. I was not able to pull transactions for a subscription. In fact what, I would really prefer is to use the merchantCustomerId to pull all the transactions for that customer. Both, getting transactions for a subscription or getting transactions for merchantCustomerId, is all implemented on the merchant interface, but we are not able to use it through the API. So i know the integration between ARB and CIM is there, just not exposed to us developers.
It would be super useful to allow for an email field within the hosted payment form so that, when we receive the transactionResponse we can receive that data for communicating with the customer. We have some legacy storefronts that don't collect the email address for various reasons.
Software Developer I
College of Southern Idaho
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.
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?