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

Approve Held Transactions via API

Status: Delivered
by andrewskaggs on ‎03-17-2016 05:48 AM

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.

0 Votes

I need to be able to create new payment profiles on existing customer profiles at the same time as a transaction is being done, so I can skip the test transaction step. Currently, I can create new payment profiles with an authCaptureTransaction only if I also want a new customer profile. I am getting lots of complaints about the test transactions, and this would solve the problem.

Status: Delivered

This is now available through the API.

Create transaction and recurring billing subscription with single request

Status: Delivered
by Omkaar1 on ‎02-06-2015 06:25 AM - last edited on ‎02-06-2015 10:21 AM by Administrator Administrator

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.

Status: Delivered

We're marking this idea as delivered but it does require two steps:

 

See https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Recurring-billing-and-... for more details on creating or updating a subscription using a profile

 

Richard

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.

Status: Delivered

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

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.

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
0 Votes

Our store uses WooCommerce (WordPress) and we use Google Analytics to track our transactions. Because users leave our site to make their payment via Authorize.net, Google Analytics is unable to correctly attribute the subsequent conversions (showing as referrals from authorize.net).

We've setup Analytics in Tag Manager and have enabled third party cookies (auto link domains), but without actually adding the code to the authorize.net pages, this is useless. I've seen many places where your customers ask this exact question and yet I've not seen a single workable response. Please create a way customers (or their developers) can enable and implement this tracking continuity. 

Status: Delivered

@annestahl This may be easier now that WooCommerce has released support for Accept.js, which uses a JavaScript library to avoid sending sensitive information through the merchant's server.

 

Richard

Hosted solution similar to stripe, coming?

Status: Delivered
by rreynier on ‎08-05-2014 10:41 AM

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.

 

Stripe offers a javascript solution which basically does the same thing as the hosted CIM but allows for the developer to seamlessly integrate the form folds into an existing system.  I was curious of Authorize.net is planning on any sort of similar solution down the road.

 

Thanks!

Status: Delivered

We now offer Authorize.Net Accept.js, a javascript library for accepting payments while reducing PCI scope:  http://developer.authorize.net/api/reference/features/acceptjs.html

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?

Status: Delivered

CIM Customization

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

As mentioned in the following post:

 

http://community.developer.authorize.net/t5/Integration-and-Testing/Masked-Expiration-Date-in-Hosted...

 

The card expiry date is masked when returned in the getCustomerProfileRequest.  As the card number is masked, there is no PCI requirement that the expiry date of the card also be masked.  Without the expiry date, it makes it impossible for us to automate the process of notifying our customer's clients that their card will be soon expiring.  The reason for us going this route is to offer an ARB solution managed completely from within our application.  It is imparative for us to have access to this date.

 

The idea is a simple one.  Return the expiry date in the CIM getCustomerProfileRequest unmasked.

 

Thanks.

Status: Delivered

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
0 Votes

Javascript payment integration

Status: Delivered
by Administrator Administrator on ‎10-29-2014 01:57 PM
Status: Delivered

We now offer Authorize.Net Accept.js, a javascript library for accepting payments while reducing PCI scope:  http://developer.authorize.net/api/reference/features/acceptjs.html

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.

 

Status: Delivered

The list of supported devices is maintained at https://support.authorize.net/authkb/index?page=content&id=A1574

 

Richard

0 Votes

Using a GUID for Customer Profile

Status: Delivered
by KevinS on ‎04-19-2016 09:20 AM

Currently there isn’t a way to create or retrieve a customer’s profile using a GUID.    It would be beneficial to use a GUID in a customer’s profile when created and retrieving the customer’s profile information.  The current API requires the customerProfileId to be known in order to get the customer’s information.  Using a GUID to get a customer’s profile information will allow easier linking from a company’s database to the payment gateway without having to know the customerProfileId. 

Status: Delivered

Developers can now use Get Customer Profile using either a merchantCustomerID or email if they are unique.

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.

Status: Delivered