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

[MalcolmEnt1]

Is there a reason the 'addPayment' form asks for, and accepts, a card code when it is not going to be saved?  Then on the edit form, the card code field is presented, and it's blocked.  Why show the card code input field and have inconsistent ways of handling it on different forms, when you're not going to save it anyway?

I guarantee I'm going to get this question from my clients....

[RichardH]

Hello @MalcolmEnt1

Yes, merchants can apply for and be approved to accept ACH payments.  The option to accept checks is only presented on hosted forms if enabled on the gateway.  By default, sandbox accounts have ACH enabled.

A developer can elect to hide accepting CC or checks with Accept Customer if they wish using form parameters depending on customer requirements.

Richard

[RichardH]

---

@MalcolmEnt1 wrote:

Is there a reason the 'addPayment' form asks for, and accepts, a card code when it is not going to be saved?  Then on the edit form, the card code field is presented, and it's blocked.  Why show the card code input field and have inconsistent ways of handling it on different forms, when you're not going to save it anyway?

I guarantee I'm going to get this question from my clients....

---

When adding a profile when validationMode=livemode, the gateway will perform a zero dollar or test transaction to confirm the card will be accepted.  If you include a CCV, it will also be passed and verified by the issuer giving your merchant more confidence future transactions will be successful.

When editing a profile, the gateway does not perform any validation so a CCV isn't needed.

Richard

[Aaron]

---

@MalcolmEnt1 wrote:

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

---

The URLs with "profile" in them are from our older implementation of hosted customer profile pages. We called that "Hosted CIM". It's officially deprecated now and will be end-of-lifed in 2018 (http://developer.authorize.net/api/upgrade_guide/).

The new hosted forms that work with our customer profile management are the ones you get if you call the "customer" URLs. Collectively, we group those forms under the name of "Accept Customer", which is part of our larger Customer Profiles feature.

Sorry if there was any confusion there. I sincerely hope that the "profile" URL wasn't used in anything on our side. If it was, please let me know so that I can flog the person responsible get that corrected.

---

@MalcolmEnt1 wrote:

The only problem I see with 'customer' now is that the window resizing is all over the board. 

---

I'll play with this a little on my end. The forms are supposed to be fully responsive, so they should definitely move around and adapt if you're resizing the window. But, they should also do that in a logical and useful way so if that's not happening, we'll need to look into that.

Can you give me any specific examples of something I can duplicate on my end, like which browser and what window size you see the problem at? Perhaps a screenshot or two? (Feel free to email screenshots directly to aawright@authorize.net if you'd like).

[MalcolmEnt1]

Aaron,

You and I need to write a book when this is done.... :-)

Re: customer vs. profile URLs... the newer customer popups have a huge font that doesn't look like anything else on the client web site.  The profile popups look consistent with the client site.  I was never successful in convincing the client to go to SIM because it was so obvious the SIM page was from another site and didn't look like their site.  So they've dropped a fortune in money and pain with PCI audits, etc.  With the profile popups, it is convincing that everything is from the same site.  Now with 'customer' we get these "Fisher-Price" looking huge-font popups.  No way I'm going to convince them that this looks like their site.  So I'm going to have to stick with 'profile' for the time being.  Before deprecating profile popups, PLEASE give an option to use normal size fonts (user-override CSS for the popup??)

[MalcolmEnt1]

Another different sub-topic...

The past 5 pages of posts have been related to my quest to set up for recurring charges.  I think I finally completely understand how to do that with customerProfiles, customerPaymentProfiles, etc.  I should have that completed in another day or so.  BTW, thanks again for all of your help.

But apart from the recurring scenario, I still have the alternate situation like I've had for years with SIM where the I simply want the user to enter a credit card number (on your site), make a payment, and be done.  No saving of credit cards, and therefore no client login required due to saved credit card info.  I know I can continue to use SIM for that for a while.  But I'd really like to kill my SIM code complete and do everything via the API.  (SIM is in deprecated mode now as well, right?)

At this point, the only way I can see to do this is to still create a client profile (which now requires a client login on my side), create a client payment profile, charge the profile, delete the payment profile, delete the client profile.  This is ugly.  And if for any reason my code crashes after the profiles are created and before I can delete the profiles, it exposes me to the risk that someone else could come in and make a charge on someone else's payment profile.  Only way to prevent that is to require login, which I didn't have to do with SIM.

I don't see an "enter credit card number and charge that card $x.xx" popup on the new API.  Am I missing it?  Or do I have to remain with SIM if I want to keep the payment pattern the same with no login for this scenario?

Am I (yet again) missing something obvious here? :-(

[RichardH]

@MalcolmEnt1

As an early holiday present, let me suggest you visit our Accept Hosted page which is our replacement for SIM using the API.  It's not yet been widely communicated, that will come in January, but it's available for developers to begin working on and testing as they move to production.

Richard

[MalcolmEnt1]

Hi, Richard,

Thanks so much for the info on Accept Hosted API.  It appears to be exactly what I need.  If only now I could get it to work.  I get my favorite and most useful error message of all time "An Error Occurred" when I submit the GetHostedPaymentPage request to get a token.  I don't see anything obviously wrong in the req XML, and the error message is completely worthless.  Can you look at it and let me know what is wrong? I'm using Java.\, and  I'm using the Java sample classes for submitting the request:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<getHostedPaymentPageRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <merchantAuthentication>
        <name>xxxxxxxx</name>
        <transactionKey>xxxxxxxxxxx</transactionKey>
    </merchantAuthentication>
    <clientId>sdk-java-1.9.2</clientId>
    <transactionRequest>
        <transactionType>authCaptureTransaction</transactionType>
        <amount>32.42</amount>
    </transactionRequest>
    <hostedPaymentSettings>
        <setting>
            <settingName>hostedPaymentButtonOptions</settingName>
            <settingValue>{"text": "Pay"}</settingValue>
        </setting>
        <setting>
            <settingName>hostedPaymentOrderOptions</settingName>
            <settingValue>{"show": false}</settingValue>
        </setting>
        <setting>
            <settingName>hostedPaymentShippingAddressOptions</settingName>
            <settingValue>{"show": false, "required": false}</settingValue>
        </setting>
    </hostedPaymentSettings>
</getHostedPaymentPageRequest>

Response:

2016-12-20 16:31:37 DEBUG wire:78 - << "?xml version="1.0" encoding="utf-8"?><getHostedPaymentPageResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00001</code><text>An error occurred during processing. Please try again.</text></message></messages></getHostedPaymentPageResponse>"

[Aaron]

Hi @MalcolmEnt1,

Do you have the "Signature Key" created in your merchant interface (as described here)? One known issue with Accept Hosted is that if the Signature Key is not populated, you don't get a helpful error message. Instead, you get the extremely unhelpful one that you've encountered.

If you don't have a Signature Key, creating one so that it's on file for your account should fix your problem. We'll fix the unhelpful error relatively soon. If you do already have a Signature Key, we'll have to look further.

[MalcolmEnt1]

Aaron,

I definitely do have the signature key (assuming the same key that works for all of the CIM api calls will also work for the Hosted Payment form).  I just X'd the login and key out of the XML when I posted it on the forum above.  I have the entire CIM stuff working.  It's just when I change to the SIM replacement API that it fails.