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 Jerry,

We try to make the sandbox environment as close to the live environment as possible, but sometimes that's difficult because everyone's live environment might be a little different. For example, your actual merchant account may respond a little differently in different situations depending on the requirements of the acquiring bank, differences in the back-end processor they're using, et cetera.

Additionally, there's the possibility of differences at the card issuing bank causing a different behavior than what you'd see with the same card in the sandbox.

In your example, card code is not specifically required by general rule, but some acquiring banks might require that their merchants submit it. In other cases, it's not a requirement of the acquiring bank, but a particular card issuer might automatically decline all transactions that don't come to them with a card code attached.

Without knowing the details of your account or what specific response you were getting, I can't say if that might have anything to do with Authorize.Net configuration or merchant account setup. But generally, all declines come from the issuer. My guess would be that the issuer is declining the transaction based on the absence of the card code. In that case, trying a different card from a different issuer could get you a different result.

In that respect, the sandbok is operating just like live. They're both failing to send the card code. The only difference is that the sandbox sends the transaction to a simulated issuer who doesn't care if the card code is present, and live (in the case of that particular card) sends it to an issuer who does care.

None of that changes the fact that if your customer enters a card code, you would logically expect it would be used. So, hopefully, we can clear up exactly when and how it's not being sent so you can work around it and we can fix it.

Please let us know what happens with the hostedProfileCardCodeRequired. Also, can you tell me the full URL you're submitting the token to after you receive it? Is it https://accept.authorize.net/customer/addPayment? Or one of the other CIM (non-Accept) URLs?

[MalcolmEnt1]

I added the hostedProfileCardCodeRequired.  No change.  It accepts the card code, Then when I issue the pay command it gives me a code 33 - Card Code is Required.

I am not sure about what URL I'm supposed to be using.  There were several samples with different URLs.  I'm now using: https://secure.authorize.net/profile/addPayment.  That was what was coded in the popup sample I found.  How does that differ from https://accept.authorize.net/customer/addPayment?  Should I change?

[RichardH]

@MalcolmEnt1

If you use the latter URL, it will use our new mobile-optimized forms which will eventually become the default for both.

Richard

[MalcolmEnt1]

I changed to the accept/etc URL.  Again, no change.  Is this possibly a problem communicating with my processor (TSYS?).  Is there any way you can trace a transaction to see what is really going on?

I went to my authnet panel, found the customer profile and payment profile I've been testing with.  I clicked "charge".  A couple of panels later it asked me to enter my card code.  So either it's not being saved or TSYS is ignoring it.

I'm getting really concerned.  This doesn't appear to be an easy fix.  Is there a way to make the processor temporarily not require the card code just so I can get up and running?

[MalcolmEnt1]

I was digging into the API doc and found this:

cardCode

Optional. Because card codes are not stored, they are not a part of the paymentProfileId. A merchant can choose to collect it at checkout for additional security.

I'm really confused now.  Am I just out of luck with my entire design for initial and recurring charges since I have no way to store card codes?  Isn't there some way to turn off the requirement?

Finally, why is the card code information even presented on the payment profile form if you explicitly state you are going to throw it away?  Doesn't make sense to me.

How are others handling this situation for recurring charges if card code isn't saved?

[Aaron]

Hi Jerry,

You are correct that the card code never gets saved into a database or record anywhere. Not by us, and ideally not by anyone (as per PCI-DSS requirements). It's presented on the form because it's a useful piece of information for validation. At the time you're collecting the payment information from the customer, you can choose whether or not to do a validation transaction on that card (either a $0 or $0.01 auth, depending on processor). If that validation transaction comes back with a message about card code being incorrect, or is declined due to incorrect card code, you'd be wary of charging that card in the future since the customer can't give you the assurance that they're in possession of the card.

Now, in your case, I'll probably need more information to know exactly what's going on. When are you getting the decline response? Is it on validation right when the card is added in the form as part of creating a new payment profile? Or, is it after the card is added and you're actually creating a transaction using that profile? Or something else?

If you could give me a complete process flow and what's failing where, that would help a lot.

In general terms, once we've saved a card and you're using it to run a transaction later, I wouldn't expect to see a card code error. Transactions run from a customer profile should be going through the networks coded as recurring transactions so the processor and issuer should both know that a card code won't be present. So, if that's where you're seeing problems, we'd really have to look deeper into what's going wrong there.

[Aaron]

---

@MalcolmEnt1 wrote:

I went to my authnet panel, found the customer profile and payment profile I've been testing with.  I clicked "charge".  A couple of panels later it asked me to enter my card code.  So either it's not being saved or TSYS is ignoring it.

---

Did you proceed all the way through charging the card in the merchant interface? With or without card code entered? What was the result?

[MalcolmEnt1]

The failure occurs when I actually try to make a charge on the profile.  I've always been entering the card code as part of the process of creating the paymen profile.  Those $0.00 or $0.01 transactions are going through each time.  So theoretically, the profile should now be 'validated' correct?  But when I turn around and try to make a charge on it, that's when I get the error.

So this looks like it is indeed the situation you described.  Card is validated (I assume since I'm getting the $0.00 transaction emails), yet it's failing on susequent actual charge.

What additional info can I provide for you to trace this?

Thanks.

Jerry

[MalcolmEnt1]

On the merchant interface making a $1.00 charge with no card code specified.

===================================

Please correct the following error(s):

Card Code is required.<br>

Below is a summary:

Transaction ID: 0
Payment Method: XXXX4010
Amount: 1.00

[MalcolmEnt1]

It looks like this is not going to get resolved in the next few hours, and the fuse is already lit on my web site.  Publicity went out today.  So I'm going to begin getting hits shortly.  So in the interim, I've added an additional field to checkout to re-collect the card code to pass in on the payment.  But I'm not going to save the card code.  Therefore, I'm still dead in the water for recurring.  At least, though, this will buy me some time since recurring won't start for a month.  Please let me know what the correct solution is as soon as possible.  A month from now, I'm going to be in big trouble if I can't auto-rebill.