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

Abiility to fetch the list of required field names in the payment form  via API

Status: Under Review
0 Votes

We would like to be able to bill our clients in one currency, and have the funds settled into our account in another.  

 

As an example, we would like to charge our UK clients in GBP, and then have the funds converted, and deposited into our Australian bank account in AUD. I think it's important that our clients always know exactly how much will be deducted from their credit cards, as opposed to having it fluctuate each month based on that days exchange rate.

 

I contacted Authorize.net to see if they offer this service, and they suggested that I post the suggestion here. If this option was available, we would be happy to have multiple Authorize.net accounts - one for each country/currency that we have clients

 

Thanks

Status: Under Review

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

Declined Transactions Emailed to Us

Status: Declined
by Liquid on ‎11-13-2014 07:19 PM

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.

Status: Declined

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.

When creating a customer profile and receiving the E000039 error that tells us there is a duplicate customer profile that already exists it would be useful to get that duplicate profile ID in the response other than inside the error text. While technically possible to pull it out of the error message it would be much easier and less prone to issue if we could get it back somewhere directly, such as the CustomerProfileID filed that already exists on the createCustomerProfileResponse object. 

0 Votes

In createTransactionRequest we are able to create a new customer profile from data which was sent in this API call by setting <createProfile>true</createProfile> flag:

 

<profile>
  <createProfile>true</createProfile>
</profile>

Since customer is only being created after transaction is set, and not assosiated with it, any of  GetTransactionList, GetUnsettledTransactionList and GetTransactionDetails API calls will respond with empty customer profile field.

 

Flag <createProfile> only declares that profile will be created, so this is an expected behavior. But also it might be usefull to associate customer profile with transaction where it was created. A new flag might be added to avoid changing <createProfile> strict behavior, and at the same time add more flexibility to this call:

<profile>
  <createProfile>true</createProfile>
  <associateWithTransaction>true</associateWithTransaction>
</profile>

, or something similar.

 

There should be a way to retrieve transaction details by their invoice number. If there is a network failure the only identifying information we have is the invoice number (not the Authorize.net generated transaction id).

 

Using the getUnsettledTransactionListRequest call is a bad choose since it only returns the last 1000 records.

Status: Accepted

Changing to Accepted, also it is now possible to return more than 1000 rows using paging.

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

Updating ARB status to Suspended

Status: Accepted
by j_gemiini2 on ‎10-07-2014 02:09 PM - last edited on ‎08-12-2015 09:33 AM by Administrator Administrator

Hi,

 

We would like to update the status of an ARB to 'suspended' via the API, but I don't see an obvious way to do this. I'm using the php sdk.

 

I see that there is the ARBUpdateSubscriptionRequest method, but status isn't a member of AuthorizeNet_Subscription, so it gives me a E00003 (unexpected element) error when I try sending 'status' or 'ARBSubscriptionStatusEnum'.

Is there anyone who knows how to do this?

 

Thanks!

Status: Accepted
0 Votes

There needs to be a way to verify if a transaction has already been posted or not in order to help eliminate possible payment duplication.  This could work by searching for an invoice number, date, and possibly even a payment amount; and get a list of all transactions where there is a match.  This way I can make sure my application isnt trying to charge a second time when it should not.

Status: Accepted

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 have been reading about you guys not implementing pin numbers to allow customers to enter a pin number prior to transacting a sale.  I find that makes no absolute sense by no means whatsoever.  Why would you NOT allow pin numbers and only have credit card only transactions?

 

Please, as a U.S. standard for the majority of the states allow pin numbers to be entered so card holders can feel safe that they can enter a pin number.  That should be something standard with any card swiping capabilities.  

 

 

 

Thank You

Status: Under Review

Hi

 

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!

 

Many thanks

Amber

Status: Under Review

CIM: Clone a payment profile from an existing customer profile to a new one

Status: Comments Requested
by ‎01-18-2015 10:38 AM - edited ‎01-18-2015 10:39 AM

We have one client that uses CIM to reduce their exposure risk so that the credit card number isn't persisted locally. If a customer places a sales order as a guest, then a new customer profile (associated with the sales order) is created and the payment is stored under that profile; this allows the client to easily re-authorize the card (for example, to verify an updated billing address or to reflect changes to an order that a customer has requested) without having to ask for the card number again. But a customer who is logged in can also manage and store these credit cards in a digital wallet that's associated with their account. It would be nice if, when a returning customer who is checking out chooses one of these cards that they've already stored in their customer profile, we could copy this payment profile to a new, "hidden" customer profile that's associated with the sales order (in case they have changes or it's a backorder or something). That way, the customer can "delete" the card from their wallet without us having to display a message like "sorry, there's a pending order associated with this card, so you have to wait". I guess we can sort of do this now by authorizing it for $1 and then creating a customer profile from that transaction, but it would be cleaner if there is a mechanism within the CIM API like copyPaymentProfile() that allowed this kind of copying of payment profiles between customer profiles. Just a thought.

0 Votes

extend refund window past 120 days

Status: Under Review
by mwh on ‎01-24-2017 08:22 PM

A credit card payment can only be refunded for up to 120 days without having to resort to using ECC.  ECC is cumbersome and creates PCI compliance hassles.  Competitor gateways can often refund transactions up to a year after they happen.  

 

Please extend the non-ECC refund window to 365 days.

Status: Under Review

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

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

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