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

Give full customization of email receipts

Status: Under Review
by merpro 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

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

Soft Descriptor and Contact Information

Status: Accepted
by jbracken1973 on ‎11-18-2014 08:38 AM - last edited on ‎01-15-2015 11:23 AM by Administrator Administrator

The ability to set the soft descriptors for a transaction. 

 

These are the fields that a customer sees on their statements, it allows for the customer to quickly ID the transactions reducing disputes and customer service.  For obvious reasons I hope.

 

Dynamic Descriptors include:

Business Name

Phone (Best Practices says this should be a Customer service number)

City and/or State

Status: Accepted

We plan to support Soft Descriptors when supported by the processors we connect to, and have plans to add support for TSYS and Global Payments.

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.

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

Level 3 Support Feature request

Status: Accepted
by thill on ‎02-05-2016 09:50 AM

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.

 

Status: Accepted
0 Votes

Hi AuthorizeNet,

 

With the complexities of SAQ A, EF, D and the opportunities of globalization (i.e. en-CA, fr-CA, en-US, es-US, es-MX; North America + Mexico) it would be great to have localizable capabilities offered in your HostedForm and DirectPostMethod implementations.

 

This would simplify product integration (Redirect, IFRAME, DirectPost, and JavaScript) and allow a SAQ A or SAQ EF implementation.

 

My thought is to add hidden text fields i.e.;

 

For fields like;

 - input type="hidden" name="x_invoice_num" value="dpm3-inv3-123"

Add a new tag like;

- input type="hidden" name="x_invoice_num_label" value="Invoice Number:" .

 

This would go a long way to improving/solving localization and keeping PCI DSS to a minimum for the companies building solution with AuthorizeNet's SDK. 

 

Regards,

Rocklin Software

Status: Accepted
0 Votes

Full name support

Status: Under Review
by treii28 on ‎01-09-2017 10:16 AM

I see a number of posts asking about this and it's somethign we are now looking at as well. Some address database systems just store the full name to a single field. Authorize addresses seem to want separate fields for first name and last name.
Would it be possible to have this be an either/or where one of the fields (e.g. 'last name') could also be used as 'full name' and the other left blank?

Status: Under Review
0 Votes

Direct Deposit

Status: Under Review
by jays on ‎10-10-2016 02:24 PM

There are many solutions providers that are trying to integrate with a payment processors to give their clients a robust system - not only for people paying them, but for paying their employees as well - via direct Deposit. For example non profits (and many for profits) need to accept money via online (donations or payments for products and services). Authorize.net has this portion down - Hooray!!! The part we need in a full CRM - Enterprise system is the ability to make payroll direct deposits to our employees. Churches and other companies use software like what we offer to keep all their systems running but we need a processor in the back end that can handle any type of money movement ie - one bank to many banks (direct deposit), receiving money from multiple banks to one bank (paying for something online from multiple clients), making payments to vendors, and so on.

Thanks for listening.

Jay 

Status: Under Review

integration with Zapier

Status: New
by 4aGoodCause on ‎03-03-2017 08:40 AM

Does Authorize net have plans to integrate with Zapier? It is has been listed on their website as "upcoming" for over a year. When will it come? 

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

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

Idea: A read-only key that can be generated specifically for the Transaction Details API.

 

Background:

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.

Status: Accepted
0 Votes

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

Status: Under Review
0 Votes

The Authorize.net API currently requires the cardholder's first and last names to be sent separately.

As HTML forms commonly only request the cardholder name using a single text field, rather than divided into two fields for a separated first and last name, I would recommend providing an optional field for the combined cardholder name.

Until that time, or if this suggestion is declined, I would recommend adding some additional code to the API.  If only the first name or last name is given, then take that variable and split it into two, such as shown in the code below, which is assuming that the form field "name_on_card" has both the first and last names.  The code does not take a middle initial into consideration, nor a first name with a space (such as "Mary Jo").

 

<?php
	if($name_on_card>'')
	{
		$name_on_card = post('name_on_card');
		$card_name_arr = explode(' ', trim($name_on_card));
		$card_first_name = $card_name_arr[0];
		$card_last_name = trim(str_replace($card_first_name, '', $name_on_card));
		
		$billto->setFirstName($card_first_name);
		$billto->setLastName($card_last_name);
	}
?>
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

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

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