cancel
Showing results for 
Search instead for 
Did you mean: 

customer profiles without payment profiles

CIM looks excellent for handling our customers' regularly-scheduled but not fixed-value payments.  It will store their payment profiles and let us issue the correct charges as needed, and I don't have to ever see their darn credit card numbers.  Great!

 

Some customers would rather receive an invoice and then come pay it without having their credit card stored, or they'd like to send a check, or pay in some means other than bank transfer or credit card.  It would be very convenient to store these users in CIM, to store their address information (for example) so that our application can just delegate the storage of addresses to one place.  Unfortunately, it looks like I can't store customer profiles without payment profiles.

 

The errors suggest that I must have a payment element, and it needs to have a creditCard, bankAccount, or trackData child.  So:

 

1) Is this a foolish thing that I want, to begin with?

 

2) If not, how can I do it?  Should I just give the non-billed-with-CIM customers the old 42...42 card number?  (Later I can use their stored address to populate a DPM form, then.)

 

3) What the heck is trackData?  I couldn't find it in documentation, nor could I make it work by just faking it up.

 

Thanks.

 

rjbs
Member
7 REPLIES 7

I guess if you wanted to use CIM to store user information only you could although it would be kinda silly since you could do that with a adatbase for free. But you could do as you suggested and store a dummy credit card number in the system and ignore it when you recalled it later on. The only issue I can think of is I am pretty sure the credit card is validated when the profile is credted. I am unsure of how to work around that although I think there is a solution. If there is I'm sure someone will chime in with it before too long.

 

Track data is the card information stored on the magnetic strip on the back of a credit card. Unless you're writing software that reads that kind of information you don't have to worry about that.


-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post
stymiee
Expert
Expert

If using hosted CIM, you can prepopulate a shipping address using regular CIM and then send them to the manage profiles page. See this thread, especially Trevor's reply:

http://community.developer.authorize.net/t5/Integration-and-Testing/Hosted-CIM-and-Customer-Name-amp...

 

I imagine similar options are available for updates if you're using regular CIM all the way.

TJPride
Expert

Thanks.  The reason I'd store non-card customers in CIM is that if I don't, I will be left storing the data in both places.  I'll have a (potentially bidirectional) sync to perform on contact information if it's stored both in CIM and my local application.  While I could certainly tackle that, it seems like it would be easier to just store these always in CIM.  They are needed only rarely, and for a limited number of puposes.

On the documentation on CIM createCustomerProfile, PaymentProfile is optional, what error are you getting. The C# sample code use createCustomerProfile without PaymentProfile and then add one with createCustomerPaymentProfile.

Synch would definitely be a problem if you're using hosted CIM. In that instance I'd keep it all in the billing profiles. If you're using regular CIM, on the other hand, there's really no practical reason (aside from laziness) to not store the information both places, since it's updated on a form on your site. It's just much more convenient if you ever want to do something like, for instance, displaying statistics on what state or city or zip code you get most of your orders from (though I suppose you could prep a table by running through all the profiles one at a time and then run however many stats you want...)

Once it was explained that I didn't need billing profiles, I tracked it down to an error in the Perl client library, which I have subsequently fixed, and I've filed a github pull request.

I do plan on using hosted CIM.  I can't keep the addresses in the billing profile, because I don't have a ccard or bank account to store.  I can store it in the customer profile's ShipTo information for now and I think that will work just fine.

 

As for the value of storing both anyway, the kind of abstraction I'm using for contact information retrieval will let me tackle the "saved both places" problem later without too too much heartache, I think.  It's just that for now I'd like to avoid the question entirely and just get things running.