Integration and Testing

[interimsol]

We seem to have conflicting information on exactly how the ARB is designed to work when dealing with annual billings.  Our company sells a product that includes an annual reoccurring billing for several years after the original sale.  The first year subscription is included within the initial product purchase.  Subsequent years are billed on the anniversary date of the original purchase.

If the customer makes the original product purchase using a credit card that will expire sometime during the first year (before the ARB will have been initiated) will Authorize.net still be able to automatically set up a ARB?  It is no problem, and setting up a ARB works fine if the customer makes the original purchase using a credit card that expires greater than one year out.  If the card expires before the first annual billing we cannot get it to set up the ARB.  We don't know if this is a coding issue or just the way Auth.net works.

We have had two different explanations of how this is to operate.  1) It is impossible to set up the ARB because Auth.net flags this as a card that has (will) expire and therefore unable to setup and/or process the future charge, or 2) Setting up the ARB is still possible and we will receive the usual notification 30 days prior to the cards expiration date.

Does anyone have experience with this and a definitive answer as to which is correct? 

[Wolfdad]

I have been struggling with this, too.  Saw documentation/posts saying it cant be done but also heard it's possible to set up a subscription starting at a future date which begins after the credit card used for the purchase expires. (Cue "Can I Play with Madness"). :catmad:

Being the empricist, I decided to find out for myself and tried to set up a subscription starting 12 months from now but whith a card that expires 3 months from now.  The response from the API call was a message "Credit Card expires before the start of the subscription." No ARB record was created.

Also being stubborn, I may have come up with work-around (just today) but am still waiting to see how the nightly notification email treats these transactions.  My approach is as follows, but - as I said - take it with a grain of salt because I still need to see what the nightly settlement process does.

• Have a usual purchase process where the product is purchased like any other one (where the payment goes through the standard authorization then nightly settlement process)
• Upon getting the OK response for that purchase, create an ARB record in Auth.net with the start date being one day in the future.  This should allow the subscription to be set up to "start" before the card expires.
• Get the outcome of that subscription response in the XML node: <messages><message><text>______</text></message></messages>.  Hopefully it comes back "Successful." Also, parse through the XML return to get the value of the <subscriptionId>____</subscriptionId> node.
• If the subscription is successfully created, immediately invoke the ARBUpdateSubscriptionRequest function via the ARB API and using the <subscriptionId> value returned above, put the REAL start date (i.e. 1 year from date of purchase) in the node <subscription><paymentSchedule><startDate> _____ </startDate></paymentSchedule></subscription>

The original purchase will be your proof that the current year's subscription is paid for, and the ARB transaction record will be set to start after the expiration of the credit card.

I've tested it repeatedly today in the sandbox and have been able to set up multiple ARB subscriptions where the credit card used was given the expiration date of "2014-01" and the subscriptions were able to be updated to have a start data of "11/12/2014". In all cases the subscription record in Auth.net shows the status as "active."

I must repeat that I still need to see how the nightly 2am processing & summary handles this, but am hopeful.  Please post back if you have suggestions/comments/success/insights about other ways to approach.

Fingers crossed, reaper.