cancel
Showing results for 
Search instead for 
Did you mean: 

Help Migrating from SIM to CIM/Form with Recurring

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

MalcolmEnt1
Contributor
70 REPLIES 70

Thanks for the response.  My issues are all with the manage form rather than the add payment form.  Have you tried the manage form?  Would love to know if you are getting OK/Cancel buttons on the form.  My problem is that the form comes up fine and allows me to add/delete payment profiles, but no way to commit or cancel the main manage page.  If you're getting buttons, and I'm not, then I'm definitely doing something wrong. 

 

Thanks.

Can I get someone to try calling https://test.authorize.net/profile/manage with a token and tell me if you get a form with ok/cancel buttons?  (I tried to post a screen cap of what I'm getting.  But the forum doesn't seem to accept images.)

 

 

I've had to abandon the manage page.  Either it's broken or I can't figure it out.  A popup without Save/Cancel buttons is useless.  And I cannot get the "showPayment" to work either.  So I've had to go to managing the profiles in my code using individual Create/Edit/Delete APIs.  A lot more work.  But at least I can get these APIs to work.

 

I've got the CreateCustomerPaymentProfile working now.  Just one question.... is there a way to prime the name/address/phone/etc fields in the CreateCustomerPaymentProfile hosted page?  I've got all of that info already available for the customer.  I'd really like to pre-fill those fields rather than forcing the client to enter all of that data a 2nd time.

@MalcolmEnt1

 

Use this URL below:  It will bring up a responsive form and use the parameters described on the customer profile documentation:  

 

 


@MalcolmEnt1 wrote:

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


Hey Jerry,

 

When I use https://test.authorize.net/customer/manage I do not get the SAVE/CANCEL buttons that I get when I use https://test.authorize.net/customer/addPayment.

 

Sorry it took a while to get back.

 

Brian

eisemann970
Contributor

RichardH, what question are you answering?  I've been trying to get that API to work for over a week. My whole problem is that this API puts up a page with NO Save/Ok/Cancel pushbuttons.  No way to dismiss the form.  Also, I use the documented option to only show payment profiles and not show shipping profiles.  But the shipping profile option still appears.  How do I dismiss the form with no buttons?

@MalcolmEnt1

 

In your previous post, you mentioned trying to obtain a OK/Cancel button on the page at https://test.authorize.net/profile/manage

 

I suggested instead using our new, responsive hosted customer profile page at the URL below which will likely have better results:

 

https://test.authorize.net/customer/manage

 

Richard

I believe Jerry's issue is that the manage payment page (https://test.authorize.net/customer/manage) does not display save or cancel buttons at the form level.  This behavior is different from the add payment page (https://test.authorize.net/customer/addPayment) which does display the save and cancel buttons.

I tried the .../customer/... url instead of .../profile/...   No buttons on this version either of 'manage'.  In addition, this version no longer talks to my iCommunicator to resize the window.  Maybe somebody just decided to change all of the callback syntaxes.  Not sure why that would be necessary.  I'd prefer not to now have to recode and yet-again debug the iCommunicator. 

 

I'm STILL just trying to get someone to tell me WHY there are NO buttons on the manage page.  If it's by design, please tell me how I'm supposed to dismiss the page.  If it's a bug on your side, please pass it up the chain to get it fixed.  Seems to me this would be a reasonably simple question to ask the page developer.

 

I think I'm going the wrong direction to find a solution.

Hi Jerry,

 

I think we might be looking at some confusion with how the form is supposed to work, coupled with a little bit of possibly confusing interface, sprinkled with a dash of possible bugs.

 

I'm first going to try to explain how the manage form works, and then hopefully you can follow up with feedback about what methods work for you once you know how it's supposed to operate.

 

If the problem is just that you're confused by the way they're operating, that's good feedback for us so that we can hopefully make it more intuitive. If the problem is that we confused you with incorrect information in the documentation or elsewhere, that's something we can fix as well. And, if the problem is just that it's broken, well, we'll definitely fix that.

 

Hopefully, together we can get it working for you, or if not, at least figure out why it won't work for your application so that we can suggest future improvements.

 

Manage Profiles Form

We've got forms for managing profiles, adding payment profiles or shipping profiles, and editing payment profiles or shipping profiles. The first one we'll look at is the manage profiles form. This is what you're seeing, I assume:

Capture.PNG

 

No master confirm or cancel buttons on this form itself. However, each payment profile or shipping profile will have edit or delete buttons that interact with that part of the profile.

 

Once you add a payment profile or shipping profile, or edit an existing profile, then you get a button at the bottom that takes the browser to the "hostedProfileReturnUrl" address sent with the token request:

return.PNG

 

There shouldn't need to be any sort of master "confirm" or "save" button for the form as a whole, because changes are saved when individual profiles are edited. If a customer gets this form and makes a change, they then just click the button to indicate they're finished with the form and want to return.

 

Where this falls down, however, is the scenario where the customer is presented this form and decides not to make any changes. At that point, if you brought it up in a lightbox or in an iframe, you can have your own controls to put up a close box or a cancel button. However, the merchant doing a straight redirect is going to have a problem in this scenario. (There's another problem where if the only edit is a change to the expiration date, that doesn't trigger the hostedProfileReturnUrl button to show up.)

 

I'll definitely look into this further to see if this behavior is by design. If not, we'll fix it. If so, we'll talk about how to improve it.

 

Other forms

We've also got forms for editing specific profiles or adding new profiles:

Those forms do have Save/Cancel buttons, because they're just operating on a particular piece, so you have a simpler flow with those.

 

 

Now, having said all this, you're using the form as an iframe, correct? In that case, the documentation indicates that you shouldn't even send the hostedProfileReturnUrl value, so I would expect you would never get the return button to show up. In that case, I guess it's up to you to provide some way to close or break out of the iframe. Is that possible?

 

 

hostedProfileManageOptions

As far as not showing the shipping profiles, this works correctly for me in my testing. Make sure you're sending that as part of the token request, not as part of the form submission. Just include something like this in your token request:

<setting>
    <settingName>hostedProfileManageOptions</settingName>
    <settingValue>showPayment</settingValue>
</setting>

Make sure that each settingName and settingValue is in a seperate <setting> element. If that's not working for you, can you copy and paste the whole request?