Important Information for Automated Recurring Billing Developers

by Administrator Administrator on ‎08-26-2015 03:08 PM (30,932 Views)

Recurring Billing Payment Data Converted to Customer Profiles

Many developers have told us they would love to use their Automated Recurring Billing (ARB) data with the Customer Information Manager (CIM). Some have even asked if we could move all their ARB card data over to CIM to provide more flexibility with recurring billing scenarios. The good news is that it’s already underway.

 

As of August 1, 2015, we completed phase two of this project where all recurring billing subscription payment information was converted to customer profiles. In future phases, we’ll add new features to our API, such as the ability to create a subscription from a customer profile.

 

Steps You Should Take Today

If you have an existing ARB integration, you should ensure that you are populating the customer fields (Merchant Defined Customer ID, Email) with real data and passing valid (and most likely unique) information when it is available. Going forward, we plan to use Customer Profiles as the main source of customer data, making it even more important to have accurate information on file.

 

What do you think about these changes? 

 

If you have more ideas on how to improve the Authorize.Net API, visit our Ideas forum and let us know.

 

Richard 

Comments
by vinu3mn
on ‎09-03-2015 12:55 AM

Hi,

Can we make the cvv as not mandatory while doing the payment .

if the vendor did the settings as cvv as mandatory  and if i dont enter the cvv and i wont pass the value then transaction will happen or not?

can any one please let me know how this cvv works.

 

Thanks,

vini

by emedicalfusion
on ‎11-30-2015 07:13 PM

Richard, 

 

We have been waitng years for the ability to create ARB subscriptions using CIM profiles but even with the November 4 update, that ability still isn't there.  Do you have an ETA on the update to the ARB API to allow subscriptions to be created from CIM profiles. Seems like such a logical extension of the functionality. Please advise.

by Administrator Administrator
on ‎11-30-2015 07:24 PM

@emedicalfusion Work is already underway and will be coming in the next release.  That's the best information I have today.

 

Richard

by emedicalfusion
on ‎11-30-2015 07:34 PM

Thanks.  Seems that the first part of the API udpates has broken some existing functionality. I reported this to the help desk today but they didn't have any usable information. Issue we are having is that the new Createpaymentprofile API method is disallowing the creaation of payment profiles if the card exists with same address.  Previously if we submitted new card information and attempted to create a new CIM profile, it would be created as long as the expiration date was different.  Now, the method is failing (and we are not handling that failure as I just learned today what the issue is) and apparently giving the message that profile exists.  Due to this my application with nearly 100 customers using it is failing in this case and giving the error "card is expired".  Behind the scenes, it is attempign to process the transaciton using the card on file that was not updated.  

 

Once we can update and test our code, I know how to handle this, but I am hoping that there is a quick fix for this issue while we re=write our code.  Seems that Auth.net has broken the "rule"  by breaking the tunctionality of an existing interface without telling anyone.   

 

Any suggestions on this issue as it is having serious impact. Our helpfesk is flooded with calls about the expired cards.