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.

New Idea

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.

Status: Delivered

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.

 

Status: Under Review

ARB subscription details

Status: Accepted
by on ‎01-26-2015 02:02 PM

There needs to be a feature that allows you to get subscription information like when was the last valid payment, all attempt of card processing and whether it failed or went through, etc etc etc. ARB really is tiny with no usefull functions other than create and cancel subscriptions. Even the update is useless with the amount of things u can update about a transaction. So please add some features that gives users some idea of what is going on with their subscription. Is there a better payment processor than authorize.net that does this?

Status: Accepted

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.

 

Thanks,

Mark

Status: Under Review

Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/refundTransaction-requires-expi...

 

Currently, to refund a transaction, you must provide both the masked credit card number and expiration date.   Yet this information adds nothing to the request -- in fact, if you no longer have this information, you must issue a separate getTransactionDetail transaction to fetch this information.   Rather than requiring two separate transactions to perform a single task, only require the original transaction id.

 

Status: Accepted

CIM Customization

Status: Delivered
by on ‎11-18-2014 01:33 AM

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.

Status: Delivered

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.

 

Give full customization of email receipts

Status: Under Review
by on ‎12-02-2015 10:17 AM

Please allow us to fully customize the email receipts. You finally allowed us to change the description of the normal recipt. Now expand that to allow customization for recipts from transactions flagged by the fraud filter.

 

In 2015 I can't even comprehend this restriction of not letting the customer dictate what the recipt should say. 

Status: Under Review

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.

Status: Delivered

Generating Client Public Key

Status: Delivered
by 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

Status: Delivered

 Hi @menudrive-myles

 

 Just to update on it if you are calling the getMerchantDetailsRequest API .

 

and  if the public key is not generated , it will be generated automatically and returned in the response . 

 

You can call the getMerchantDetails API on behalf  of the merchant by using the  OAuth token 

 

https://developer.authorize.net/api/reference/features/oauth.html

 

 

Thanks

Anurag

 

 

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.

As noted in the FAQ, Authorize.net waits 10 seconds to receive a response from DPM POST requests:

http://developer.authorize.net/faqs/#rrcauses

 

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.

 

 

 

 

 

 

Status: Delivered

DPM is now replaced by Authorize.Net Accept.js, a javascript library for accepting payments: http://developer.authorize.net/api/reference/features/acceptjs.html

NPM package for Accept.js

Status: New
by on ‎07-17-2018 08:55 AM

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.

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.

Status: Delivered

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.

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.  

<settingName>hostedCancelButtonOptions</settingName>
<settingValue>{"show": false}</settingValue>

 OR 

once the pay button is clicked, disable the cancel button so that end-user doesnt have an option to select cancel.

 

-Bhavana

 

There seems to be many companies that have more than a 1,000 unsettled transactions they need to review on a daily basis. Being able to pull this down programmatically is an important feature for us to evaluate/validate unsettled transactions each day. Removing the limit on the Get Unsettled Transactions API function would be a great help! Thanks,
Status: Delivered

We have delivered this capability with an update to the reporting API methods:

 

 

Element

Description

sorting

Contains sorting information

         orderBy

Order of transactions in response:

         id

         submitTimeUTC

         orderDescending

true, false, 1 or 0

Paging

 

         limit

1-1000.

The number of transactions per page.

         offset

1-100000.

The number of the page.

 

Unsettled Transactions

The example request below will retrieve the last 100 unsettled transactions by time submitted.  With this release, sorting can be on either transaction ID or transaction submit time.

 

 

<getUnsettledTransactionListRequest>
    <merchantAuthentication>
        <name>API_LOGIN_ID</name>
        <transactionKey>TRANSACTION_KEY</transactionKey>
    </merchantAuthentication>
    <sorting>
      <orderBy>submitTimeUTC</orderBy>
      <orderDescending>true</orderDescending>
    </sorting>
    <paging>
      <limit>100</limit>
      <offset>1</offset>
    </paging>
</getUnsettledTransactionListRequest>

 

 

The resulting GetTransactionList response is unchanged apart from one new field, totalNumInResultSet.

 

Settled Transactions

Pagination works exactly the same way for settled transactions. Use the paging elements to page through a settled batch of transactions 100 at a time. 

 

<getTransactionListRequest> 
  <merchantAuthentication> 
<name>API_LOGIN_ID</name>
<transactionKey>TRANSACTION_KEY</transactionKey>
</merchantAuthentication>
<batchId>6416551</batchId>
<paging>
<limit>300</limit>
<offset>1</offset>
</paging>
</getTransactionListRequest>

 

The resulting GetTransactionList response is unchanged apart from one new field, totalNumInResultSet.

we using this scripts, the problem is in production mode it accepts test card details.
and when charge the card it sends transaction id with the error code as I0001 and message as the success.
 

Webhook for trial transactions

Status: New
by ‎10-12-2017 01:13 PM - edited ‎10-12-2017 01:14 PM

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.