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.
The CIM iframe works great but lacks some display options. For example, I use it at a newspaper where the billing and shipping info are both useful to have. Unfortunately we cannot change the name of "Shipping" to delivery. In the case of a newspaper, this might imply we will mail the subscription which is not the case. It would also be nice to be able show or hide the shipping field if it wasn't needed.
The iframe should also support a responsively designed site. It will position further down on the page by default when viewed on a mobile device.
Just posting here in case someone finds my post before wasting further time on this issue.
I have an app that uses authnet's API to take payments. I also use their fraud detection suite, specifically for many of the IP address-related filters (velocity, shipping mismatch, regional blocking, etc). I'd been conducting business like normal for some time, no issues. I recently had my web host enable IPv6 for my site to get the benefits it providers for mobile shoppers who often see faster performance over v6 due to not having to go through carrier NAT for IPv4 in high density areas. Everything seemed like it was working fine initially, but then I heard from a customer who could not pay.
After some debugging, we found that my payment code was populating the authorize.net API field customerIP / x_customer_ip with the customer's IP, which is obviously what it is intended for. I was populating it with both IPv4 and IPv6 addresses. The field is only usable for IPv4 ;if you pass IPv6, it will decline the transaction.
What's worse, is that since I have fraud suite features enabled, I have to pass an IP. So what to do for an IPv6 shopper? I can't pass a placeholder IPv4 address, such as always passing my site's own IP when the shopper is IPv6, because I'd end up triggering the velocity filter. So ended up having to go back to not having my site IPv6 enabled.
I found someone asking about IPv6 and that field as far back as 2011, and authnet still hasn't caught on. Comcast is IPv6-enabled nationwide, as is nearly every 4g cell network, so this isn't just a fringe customerbase I'm wanting to support.
Would like to be able to customize the pop up for managing payment profiles. It would be great if the Payment Form Fields configuration checkboxes applied to this, so that for example we could turn off the shipping address. A seperate place to configure this would also be fine.
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.
We are using the AuthorizeNet Nuget package in our code base to communicate with Authorize.Net. After the TLS1.2 upgrade at Authorize.Net in the sandbox environment, we have been using
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
So that the communication does not fail. It would be great if the fix was applied on the Nuget Package.
As noted in the FAQ, Authorize.net waits 10 seconds to receive a response from DPM POST requests:
It also notes that "On occasion, timeouts will occur that are outside of the control of your script or our servers. Typical reasons for these timeouts are Internet traffic, merchant server overload or malfunctions, or Internet routing issues. Depending upon your server location and what route is used to send data, it is possible that you may occasionally receive a time out message."
It appears that Authorize.net does not retry a failed POST, even if the 10 second timeout has not been reached. This was confirmed by an admin in the forums ("We currently do not retry failed posts").
I propose that this behavior be changed. If an Authorize.net POST request fails, prior to the 10 second cut-off, the POST should be retried, possibly with a short backoff (e.g., wait a second or two to reinitiate, to prevent a flood of requests).
As background, we have been using DPM successfully for a couple of years now, but we do occassionally see "timeout" errors. Crucially, it does not appear that these are actually caused by timeouts. The first thing we do in handling the response is log receipt of the request. But we see no evidence of having received the requests in our logs. Which suggests that the problem is happening outside of our network.
As it currently stands, Authorize.net's POST request could fail immediately due to some extremely transitory issue (perhaps even within their network). They would immediately receive a "connection reset by peer" error or whatever. And even though virtually none of the 10 second timeout period has been consumed, the customer receives a timeout error.
The DPM process should make more of an effort to communicate the transaction status and prevent this failure scenario.
Possibly related to this request would be additional logging facilities, so that both Authorize.net and its customers could have more insight into what exactly is occuring. IOW, it would be very helpful to have some visibility into *why* Authorize.net's POST request failed, and how long it took. It could provide much needed stats to discover how often the "timeout" problem is happening and whether these suggested changes are actually making a difference.
The ID of a duplicate customer profile is returned, but not when it is a payment profile: "A duplicate customer payment profile already exists." These requests date back to 2009, it forces us to loop through the payments and try to guess at which one is the duplicate and doesn't always work since customers can still generate duplicates anyway by updating existing profiles. It would be nice if there was a way to get the ID of the duplicate payment profile, or if there was a way to disable the duplicate verification check completely, since what some merchants really need is just a "I give you a PAN, you give me a token" level of tokenization instead of futzing with profiles. Thanks.
We'd like to proactively email customers who have credit cards about to expire. It would be very helpful to have one call that would return all those customer ids with payment profile id(s) and expiration date.
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.
how i create ARB subscription using single payment in php
I want to integrate ARB with AIM in core php website.please give me proper intructions with example.
It seems so stupid that this is not already available.
If you have an ARB subscriber for a service you are offering on a monthly basis, you would of course want to know, often and simply, if that subscriber has paid his last bill before you continue to service him.
But instead of a simple API function, I have to parse through mountains of data and, if I dont want to have to do this everytime someone logs in ( to check if they should be able to), i also now have to create a database table to track this status and when it was last checked.
Please Authorize.net, create a simple API to do this simple check!!!
We need the DECLINED / Non-Payments to be EMAILED TO us. I have ALSO asked for this easy and basic functionality for years. We have recieved nothing but a "we are working on it" response for YEARS. It's beyond frustrating.
It's a very simple task. It is ABSURD that you do NOT have this option yet.
We NEED to have the DECLINED Payments (and not just successful payments) EMAILED directly to various admins here at our small business AND the reason for the decline (i.e. incomplete payment or expired credit card).
Please advise on when this will actually be impleted. Thank you.
We are a software developer with an interface to Authorize.net's API for storing card data using Customer Information Manager and issuing transactions based on the saved payment profiles.
A number of our clients separate credit card transactions by card type. To do this we need to know the card type for a payment profile saved in CIM. This information does not appear to be in your CIM documentation. Are there any plans for returning this data?
Currently it doesn't appear that you offer a service like many of your competitors to automatically update card expiry dates that are stored in the system. It would be VERY beneficial for anyone doing recurring payments (either manually or via your automatic system) to be able to get the latest expiry information.
The CIM "Add New Payment Method" hosted form does not show an asterix before billing zip and street even though they are required fields. Card Number expiration date, and Card code are clearly indicated as required via an asterix.
This will be confusing to our customers as the credit card number and expiration date fields are clearly marked with an asterix while street and zip appear optional, yet when customers hit save, they are told that zip and street are required.
Ideally whether or not zip and street are required fields and trigger an error message should be determined from the merchant account AVS settings, or be determined by a setting indicated when requesting the hosted form token.
It's great that now we finally can retrieve card expiration dates via API call. Nevertheless, on https://test.authorize.net/profile/editPayment form expiration date is still displayed as masked. Our clients find this inconvenient. The idea is to show unmasked date on hosted form.
I don't think it's fair to put the status to delivered, (as @cggamer alluded to) as the request was specifically for getCustomerProfileRequest. It's nice that it was delivered for getCustomerPaymentProfileRequest but this means that you have to do multiple requests to show a customer's full profile, which I'm guessing most systems (including mine) would rather not.
It is unclear whether or not Authorize.net supports readers where the manufacturer is able to perform key injection of an encryption key provided by Authorize.net. This seems like a straight-forward concept that should be documented on the mobile reader support page. Forum posts (other than mine) indicate confusion about this issue. Unfortunately, the support reps don't really understand the question and can only answer based on what they read from the site, so calling support does not help.