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

Well I guess that explains it.  But I still don't understand the rationale.  No matter what form I put up, it would seem there would be consistency in how the user interaction is handled.  An option for a 'done' button would be nice.  It just looks like the manage form was designed and coded by somebody completely different than whoever coded the other forms.

 

Also, the manage form has the Authorize.net branding at the bottom.  One of my clients does not want any outside branding.  I don't see a way to remove that from the form.

 

Here's my java code for the setting:

 

       SettingType setting = new SettingType();
       setting.setSettingName("hostedProfileManageOptions");
       setting.setSettingValue("showPayment");
       alist.getSetting().add(setting);

 

I didn't check if the option is getting into to the outbound XML.  But given that I've got to code my own way out of the manage box and (currently) the manage popup has the branding, I don't think manage is going to be possible for my solution.    So I guess I'll just have to code my own 'pseudo manage' form calling all of the other add/delete/edit forms to do what it looked like the manage form would do.

 

Also, did you see my question about a way to prime a new payment profile form with name, address, phone, email, etc instead of forcing the user to enter than info again and again for each credit card?

As far as the branding goes, that goes away when you send

          <setting>
                <settingName>hostedProfilePageBorderVisible</settingName>
                <settingValue>false</settingValue>
          </setting>

It would be worth checking to see if these settings are making it into your xml request. If they are and things still aren't working, we'll need to investigate further.


@MalcolmEnt1 wrote:

 

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.


There's no way directly to get a token and then use that token to open the addPayment form with prepopulated values. In most use cases, you'll want to make sure that you're getting the appropriate billing address for the specific card they're entering, so prepopulating it runs the risk of prepopulating with the wrong address and having the customer not correct you. It's certainly something we can think about for the future, though.

 

 

One thing you can do that would is get the card number using Accept.js, then use the opaqueData returned by Accept.js along with whatever name/address you already have to create the payment profile yourself. That still serves the purpose of having you not storing or seeing the card number.

Hi Aaron,

 

Thanks for the info.  But IMHO, a gray bar where buttons appear (on other panels) that has a branding logo is NOT a 'border'.  A border is a thin line around a box in HTML terms.  That's just terminology, and the branding did indeed go away.  But strictly, my opinion, that is HORRIBLE terminology.  I wouldn't have even thought to try the border option to remove the gray bar.

 

So the 'border' branding is gone.  Good news for that.  I can add my own "Done" button outside the frame.  But I still can't get rid of the shipping section.  Here is the direct output from Log4J.  The shipping section is still there on this call:

 

2016-12-14 09:42:21 DEBUG wire:64 - >> "<?xml version="1.0" encoding="UTF-8" standalone="yes"?>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "<getHostedProfilePageRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "    <merchantAuthentication>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        <name>3ubr4HZ5mvMh</name>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        <transactionKey>**</transactionKey>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "    </merchantAuthentication>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "    <clientId>sdk-java-1.9.2</clientId>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "    <customerProfileId>1807925385</customerProfileId>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "    <hostedProfileSettings>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        <setting>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "            <settingName>hostedProfileManageOptions</settingName>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "            <settingValue>showPayment</settingValue>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        </setting>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        <setting>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "            <settingName>hostedProfilePageBorderVisible</settingName>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "            <settingValue>false</settingValue>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        </setting>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        <setting>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "            <settingName>hostedProfileIFrameCommunicatorUrl</settingName>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "            <settingValue>https://handlemyleads.com/payment/jsp/guest/iCommunicator.jsp</settingValue>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "        </setting>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "    </hostedProfileSettings>[\n]"
2016-12-14 09:42:21 DEBUG wire:64 - >> "</getHostedProfilePageRequest>[\n]"
2016-12-14 09:42:21 DEBUG wire:78 - << "HTTP/1.1 200 OK[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Cache-Control: private[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Content-Type: application/xml; charset=utf-8[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Server: Microsoft-IIS/7.5[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Access-Control-Allow-Origin: *[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "X-Cnection: close[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "X-AspNet-Version: 4.0.30319[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "X-Powered-By: ASP.NET[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Content-Length: 835[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Date: Wed, 14 Dec 2016 15:42:21 GMT[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "Connection: keep-alive[EOL]"
2016-12-14 09:42:21 DEBUG wire:78 - << "[EOL]"
2016-12-14 09:42:21 DEBUG DefaultClientConnection:229 - Receiving response: HTTP/1.1 200 OK


@Aaron wrote:

Hi @eisemann970,

 

Which value for validationMode are you sending with the validateCustomerPaymentProfileRequest? testMode or liveMode? If liveMode, then I would expect it to be aligned with the testing guide, so if it's not giving the expected result, that might be a bug.


Hey Aaron,

 

I'm using liveMode.  I read somewhere that recommended never using the test mode but I digress.

 

What is the recommended method for validating a payment profile?  Zero dollar charge?

 

Thanks!


@MalcolmEnt1 wrote:

A border is a thin line around a box in HTML terms.  That's just terminology, and the branding did indeed go away.  But strictly, my opinion, that is HORRIBLE terminology.  I wouldn't have even thought to try the border option to remove the gray bar.


Good point. I don't know if it's rendering differently on your browser, but there's definitely a thin border all around in my earlier screenshots. Still, we could be clearer in the documentation that the parameter set to false would remove the boder and the logo. I've already requested that we look at clarifying that.


@MalcolmEnt1 wrote:

But I still can't get rid of the shipping section.  Here is the direct output from Log4J.  The shipping section is still there on this call:

 


 

Okay, that's frustrating. I copied and pasted your exact request with all the parameters exactly as sent. I get a token back, then send that token in to request the Manage Profiles page and get a page with only payment profile, not shipping.

Capture.PNG

 

I didn't have time to code it up in an iframe, so I wonder if that's somehow affecting it (although I still sent the hostedProfileIFrameCommunicatorUrl parameter). If you just send do a simple form post of the token to the URL, do you get the same thing?

Okay, I can duplicate your results in testing with that ZIP. I'll write it up as a bug.

 

If you create a profile with a billing zip of 46282 and then run a charge with that profile, the transaction is correctly declined. It's just validation that's not declining.

 

testMode is fine to use in validation, as long as you know it's doing nothing more than running a Luhn check on the card number and checking that the card number matches known card types. liveMode actually does an authorization/void (zero dollar or $0.01 depending on card type) with the card number.

What is the difference between "https://test.authorize.net/customer/" + opt.action;   and "https://test.authorize.net/profile/" + opt.action;

"Somewhere" either in docs, samples, I got the 'profile' URL.  I saw earlier someone posted to use the 'customer' URL.  The 'profile' one is broken w/ regard to not showing shipping.  But it works on 'customer'.

 

The only problem I see with 'customer' now is that the window resizing is all over the board.  I start out with a window with a little white space at the bottom (and one existing profile).  It is immediately resized to several inches of unused white space at the bottom.  Then as I played around with edit/add, and expanding the existing profile, it resized really small with very large text and a scroll bar required to see the 'add' form.  I can live with it.  But it's definitely not working right on sizing.  And the add font is way oversized for the rest of the panels.

Different 'sub-topic'.... I was not even aware that I could take bank drafts.  Is that something that is available to all Authorize.net accounts just like credit card acceptance?  Is it something a merchant has to sign up for?  If I or my client want to stick with only credit cards and not do bank drafts, is there a way to remove the 'bank' option from the 'addProfile' popup?  Or does it fall into the category of "why not just leave it and use it...?"