Help Migrating from SIM to CIM/Form with Recurring

[MalcolmEnt1]

I coded a SIM solution over 10 years ago, and it's been working fine for many clients.  But I now need to add recurring charge capability.  I desperately want to avoid any PCI requirements, i.e.  I never want to see cc#s.

I think I see the solution after digging through the API doc.  But I'm having trouble with the big-picture flow.  Please bear with me on this. I have many years of career coding experience.  But I need a bit of clarification and validation to make sure I am correct in my understanding of how all the piece-parts fit in the overall process.

The first thing I need is to validate that I can indeed do what I want to do, which is:

1. Create a customer account in Authorize.net using the API (without knowing the cc number)
2. Use an Authorize.net hosted form to capture and store the cc#, etc. for my customer where I never see the cc#.
3. Use the Authorize.net API as needed periodically (using my own scheduler) to request a charge transaction on that customer's credit card?

Assuming the above is possible, which from what I can tell, it apparently is.... I don't understand the 'createCustomerProfileRequest'.  It says the cc# is 'required' for that API.  But it says I have to call that API to get a profileId to be used to submit the form to capture the cc# (???).  Is it actually ok to submit the createCustomerProfileRequest API without a cc#?  Or am I totally missing something here?

Once I get past that hurdle above, can you verify my understanding that now I can simply issue a charge on that profile at any time using the API?

How close am I to correct? Again, I'm a professional code developer.  So we can talk as technical as necessary.

Thanks so much for any info you can provide.

Jerry

[Aaron]

Hi @MalcolmEnt1,

I copied and pasted your XML and the exact same request is working fine for me, so there's clearly some difference at the account level.

Just to double check, can you log in to your merchant interface on the account you're testing with and see what's there? In "Settings" under "API Credentials & Keys", there should be something in the "Signature Key Last Obtained" field. Can you make sure that's populated?

[MalcolmEnt1]

Here is the info on the settings page:

API Login ID: 	3ubr4HZ5mvMh
API Login ID Last Obtained: 	11/29/2016 15:47:29
Transaction Key Last Obtained: 	11/30/2016 19:34:00

This is for the sandbox.  The txn key is "27z8pj9hR52wVH9C"

[Aaron]

Okay, it looks like signature key is the problem, then. The Signature Key is something separate than the transaction key, and has to be created for our system to be able to use it to verify these requests. You should be seeing something more like this in your settings page:

If you don't have a value for when the Signature Key was last obtained, just generate a new Signature Key using the form in Settings.

We are looking at improvements in this area, starting with giving you a better error if the Signature Key doesn't exist for the account. Also, the info about Signature Key and how to create it is in the documentation, but I confess that I missed it the first time myself. If you have any better suggestions for how to convey that info, I'm all ears.

Again, thanks for bringing things to our attention. We may ending up writing that book together eventually, but if we do I'll give you full authorship credit and all the royalties!

[MalcolmEnt1]

Aaron,

Well, I definitely did not have a signature key.  I created one.  But now I can't find a place to use it.  I don't see a place to include it in the GetHostedPage API request.  Is this just something that has to been there, but I don't actually send it in?  Or am I overlooking where I'm supposed to include it?

[MalcolmEnt1]

After creating the Signature Key, voila, the getHostedPaymentPage started working.  So I guess I answered my own question that I don't need to put the key into the API call, rather just required that I create one.  But just curious if there are still places that I need to use the Signature Key I was given or if it's just good enough that I have one.

[RichardH]

@MalcolmEnt1

For Accept Hosted, as you have learned, it must be generated to work.  A future release will auto-generate the public signature key if needed.

A signature key is required if you use Accept.js.

Richard

[MalcolmEnt1]

This is kinda urgent.... I have everything coded and working for CIM in the sandbox.  I need to go live now (as in... today....).  I changed all of my login/txnkey/environment/etc to my real account.  But I have one huge problem:  The createPaymentProfile popup doesn't save the card code when I enter it.  (The field is there, and I enter the code). Then when I make the payment, it fails due to no card code.  I'm sure there is something I need to enable.  But I can't find it.

I need to either get it to save the card code or somehow disable the requirement for it when paying.

Help please.... QUICKLY.....

Thanks.

Jerry

[Aaron]

Hi Jerry,

Can you give me any information I can use to duplicate on my end? For example, which end point are you using? Can you give me an example API request to set up the form on my end and see what happens?

[Aaron]

One thing to check off the top of my head...

What are you sending for hostedProfileCardCodeRequired in the token request?

The field for card code will be displayed whether you send that as true or false. However, I'm wondering if any code entered is dropped before submission if that field is set as false.

[MalcolmEnt1]

Hi Aaron,

I'm not sending hostedProfileCardCodeRequired at all.  I guess the default is false. 

However, in the sandbox, payments still went through with this exact same code.  I'll try explicitly setting it to true.  But it's disconcerting that things don't work in production the same as they worked in the sandbox, especially after tons of testing in the sandbox and then a tight deadline to go live.

By 'endpoint' do you mean the url called by the popup?  I'm now using https://secure.authorize.net/

Thanks.

Jerry