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.
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.
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.
Currently, transactions flagged as suspicious and held for review by the Fraud Detection Suite can only be approved via the Merchant Interface.
It would be much more convenient if we were able to approve these held transactions via the API without requiring our admins to log into the Merchant Interface.
I have just recently wrapped up an integration with Auth.net to our website and erp system using CIM and the Payment Transaction API. Our system is passing the Level 3 data to Auth.net, but Auth.net doesn't pass this information to the processor. I was curious about the decision for Auth to hold onto the data and not deliver it to the processors and if this feature is on the roadmap? I would love to have the L3 data passed around, we could realize an incredible amount of savings from this (fees can be cut by up to half with this information, That's huge!).
If this isn't on the roadmap, please consider adding support for this.
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.
Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/How-to-set-billing-info-in-CIM-...
Add ability to pre-load billing information into CIM hosted form. Our customer's billing information is already stored in our system, and we do not want to force them to enter it a second time when adding a payment profile. We would prefer instead to show the current billing information as the default values and allow them to modify the displayed information if the billing infomration is different for the credit card than what is already on file.
In our system the user complete billing information, and when we show the form of the CIM hosted API, we need such data are loaded in the form, as we do that?
First we call to createCustomerProfileRequest, with merchantCustomerId and email.
Then I call createCustomerShippingAddressRequest with customer billing address
and then, I call getHostedProfilePageRequest.
Following our recent Gap Analysis for PCIDSS Compliance, it was suggested that at the point of entering the Credit/Debit card details for payments, the PAN should be masked. This would then take away the opportunity for screen scraping where the user could screen shot the full details, or copy and paste them somewhere else.
After getting in touch with the dev team at Authorize, they have advised that this would be a good idea to get rolling and the best way to do this is to add it here. So here we are!
Idea: A read-only key that can be generated specifically for the Transaction Details API.
We are developing an app that only uses the Transaction Details API.
Which means we are only reading information.
From a liability standpoint, we want to avoid saving a write-capable transaction key.
Ideally a separate "read-only" transaction key could be created when a user turns on the Transaction Details API.
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.
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.
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.
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.
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.
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.
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.
Currently, to avoid most PCI compliance, the hosted CIM is the suggested solution. The problem with this solution is that it is very clunky and does not integrate well with any custom interface. It uses an Iframe solution in which you have no control over the appearance of the form fields.
As we build out our integration we noticed it would nice to have some additonal search types added to the getCustomerPaymentProfileListRequest endpoint. The most useful for us would be to search by customerProfileID. Also an expiration date range would be nice along with a paymentType (credit card or bank account)
A future request i could see is having the ability to have multiple searchTypes like customerProfileID and and an expiration month/year or range, or customerProfileID and paymentType.