Reply
Highlighted
Contributor
Posts: 18
Registered: ‎06-30-2011
Accepted Solution

ARBCreateSubscription question

I am using the CIM API to manage customer profiles, payments etc. One of the requirement is automatic recurring billing (ARB). In my code, I retrieve the customer based on the customerprofileId. This returns a GetCustomerProfileResponseType object. From this object I read the payment info like this...

 

svcRef.GetCustomerProfileResponseType cust = client.GetCustomerProfile(auth, id);

            NameAndAddressType addr = null;
            svcRef.PaymentType payType = null;

            if (cust != null)
            {
                if (cust.profile != null)
                {
                   
                    if (cust.profile.paymentProfiles != null)
                    {
                        if (cust.profile.paymentProfiles.GetUpperBound(0) >= 0)
                        {
                            addr = cust.profile.paymentProfiles[0].billTo;
                           
                            svcRef.PaymentMaskedType mPmt = cust.profile.paymentProfiles[0].payment;

                            if (mPmt != null)
                            {
                                payType = new CreditCard.svcRef.PaymentType();

                                payType.Item = mPmt.Item;
                            }
                           
                        }
                    }
                }
               
            }

 

then I assign the payType to the payment property of the subscription object (of type ARNSubsciptionType) like so....

sub.payment = payType;

 

ISSUE: The payType is now of type CreditCardMaskedType.

 

Will this work for ARBCreateSubscription?


Accepted Solutions
Highlighted
Solution
Accepted by topic author TK
‎08-21-2015 01:58 AM
Contributor
Posts: 18
Registered: ‎06-30-2011

Re: ARBCreateSubscription question

I dug through harder this time and found the CreateCustomerProfileTransaction method. This method takes an object of ProfileTransactionType. One of the properties on this object is of type Item that we can use to denote what type of transaction it is (auth, authAndCapture, Refund etc). On this object is a property called recurringBilling which is of type bool. I think this will do the trick. I am gonna try this and see if it helps.

 

Thanks for staying with me and help me sort this out.

View solution in original post


All Replies
Highlighted
Regular Contributor
Posts: 72
Registered: ‎07-06-2011

Re: ARBCreateSubscription question

The CIM will only return the last 4 digits of a credit card number, preceeded by four X's, from a customer payment profile.

 

Example:

Actual card number is 4111111111112345

Response from CIM will be  XXXX2345

 

So if you are asking if you can use that response information to populate the cardNumber element in ARBCreateSubscriptionRequest the answer is probably no.

 

In addition to that,  the ARBCreateSubscriptionRequest also requires the expirationDate of the credit card.

The CIM system doesn't return any of that at all.. it only returns four X's (XXXX).   So you couldn't use that data either.

 

WHeis

 

 

 

Highlighted
Contributor
Posts: 18
Registered: ‎06-30-2011

Re: ARBCreateSubscription question

Thanks for the response. This is my specific question.

 

Consider the scenario where you have a created a customer profile previously with payment information. You now would like to use the same customer and payment information that you have already stored on AuthNet servers to create an automatic recurring billing subscription.

 

Is there any way of achieving this using the CIM SOAP API?

 

Thanks!

Highlighted
Regular Contributor
Posts: 72
Registered: ‎07-06-2011

Re: ARBCreateSubscription question

The last I read the system is not integrated with ARB to use the CIM's stored customer payment profile data.

 

The 'short answer' to your specific question is:  Since the CIM system will not provide you with the full credit card details of any payment profile,  you can't use it with ARB because ARB requires the full card number and expiration date.

 

Longer answer:

None of the AuthNet APIs let you to retrieve a customer's credit card information. You can store the credit card information in the CIM but that only allows you to make future CIM based payments with it, not actually retrieve it or use the CIM record for an ARB/SIM/AIM payment.  If you need to 'recreate' a new payment system on something other than CIM (ARB/SIM/AIM)  you have to either get that information 'again' from the customer,  or have already stored it in your database prior to sending it through to any of the API's.

 

WHeis

 

Highlighted
Contributor
Posts: 18
Registered: ‎06-30-2011

Re: ARBCreateSubscription question

So, the moral of the story is you really cannot create a ARBSubscription for an existing customer without providing the payment information all over again. That sucks, since most of the applications shy away from storing credit card information in their db due to all the hassles with PCI compliance.

 

All AuthorizeNet probably would have to do is to provide an overload that would take a paymentprofileId in the ARBCreateSubscription request and expose it via SOAP or whatever, since most other relevant customer information can be retrieved from CIM using GetCustomerProfile.

 

Of course this is all based on my idyllic assumptions.

 

Thanks for the response tho!

Highlighted
Contributor
Posts: 18
Registered: ‎06-30-2011

Re: ARBCreateSubscription question

This also begs the question - why CIM? Why would you store customer, address, payment information with AuthorizeNet if you cannot use it for future transactional purposes.

Then again, there is a severe disconnect between CIM and AIM (used mainly for transaction management - authorization, capture, void, refunds etc). Whereas the purpose of AIM is stated as above, CIM manages only customer related information. On the other had all ARB functions are in the ARB SOAP API.

Do I understand this correctly? If yes, it is just plain crazy to have so many flavors of API each doing something different and nothing that does it all. Is my frustration totally pointless and misdirected or the whole API deal is a big Kludge?

 

Sorry to sound so cynical....it maybe my lack of understanding.

 

Thanks!

Highlighted
Regular Contributor
Posts: 72
Registered: ‎07-06-2011

Re: ARBCreateSubscription question

Question: Why CIM?

 

We use the Hosted CIM system because we don't have a need to store our customer credit card information.  Our customers pay for invoices we generate on our site.  

 

With the CIM system,  the customer enters their credit card payment method(s) only once.  That data is then stored in the CIM system forever, or until it gets deleted by the customer/us.

 

When the customer is going to pay an invoice,  we grab all of their payment methods from the CIM system and let them pick which one they want to use.   We don't need to get their credit card number or anything else.. because we don't need it.   We do go ahead and use the 'last four digits' of the response so we can present that to the customer on the invoicing/payment screen.

 

If a customer has a CIM payment record,  we basically present it this way, after grabbing all of the customer's current CIM payment profiles:

 

Choose which payment method you want to use for this transaction:

A.  Credit card ending in 2345

B.  Credit card endin gin 2533

C.  Bank account ending in 8382

 

(here we would show a copy of the invoice being paid)

(here we would put a 'Pay Now' button)

 

The customer chooses A, B or C and clicks 'Pay Now'.    We then send the request off to Authnet with the ID of the payment profile the customer chose and the amount they are paying.    AuthNet responds with a success or failure and we're done.

 

To use the AuthNet ARB system,  you'd have to get that information 'again', or get it initially to send to the ARB process.

 

Or..  just write some code that allows you to handle the recurring billing on your own site using the CIM payment profile.  Not too difficult to do that.

 

If you want to use AuthNet's ARB system,  then you have to do it their way - and you cant use CIM.

If you want to use CIM, and have recurring billing,  you have to write your own ARB system.

 

Personally,  after the week it took me to sort through all the insanity to get CIM to work,  I dont know why anyone would use anything else... unless you are unable to write your own software to do ARB or something like that,  CIM is perfect. If for no other reason than not having to ever worry about PCI compliance again.

 

WHeis

 

Highlighted
Solution
Accepted by topic author TK
‎08-21-2015 01:58 AM
Contributor
Posts: 18
Registered: ‎06-30-2011

Re: ARBCreateSubscription question

I dug through harder this time and found the CreateCustomerProfileTransaction method. This method takes an object of ProfileTransactionType. One of the properties on this object is of type Item that we can use to denote what type of transaction it is (auth, authAndCapture, Refund etc). On this object is a property called recurringBilling which is of type bool. I think this will do the trick. I am gonna try this and see if it helps.

 

Thanks for staying with me and help me sort this out.

Highlighted
Member
Posts: 3
Registered: ‎10-23-2011

Re: ARBCreateSubscription question

Hi,   I am evaluating Authorize.net for our web site application to use CIM to take care of CPI compliance and to use ARB for our recurring payment needs.  I am running into the same issue of not able to use arbCreateSubscription from customerPaymentProfile stored in CIM. Was there any updates from Authorize.net development on this issue? Looking at your post it seems like you wrote your own ARB and use CIM to store CC data to workaround the issue. Did that work well for you?  I am thinking of going the same path.

 

Thanks for your posts on this issue.

Shirley

Highlighted
Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: ARBCreateSubscription question

In my opinion it's much easier to just have an automated routine do your billing for you, especially if you're already dealing with CIM profiles as it is.