Integration and Testing

[Housni]

Hi,

I just want to make sure I'm on the right track, with my requirements matching the choice I've made. I would really appreciate an opinion :)

I've chosen to go with DPM.

My requirements are that:

1. The process of entering the card data is done within the host site.
2. I want to be able to process a one time charge or a recurring one.
3. I am not PCI compliant.
4. I'd like to avoid using SSL, if possible.
5. I will not store card data.
6. I want a unique ID returned for each transaction with some sort of a reciept. (optional)

If someone could tell me if I've made the right choice, that would be great :)

Thanks.

[TJPride Expert · Accepted solution]

Some of your choices seem mutually exclusive.

1) DPM allows the credit card info to be entered through a URL at your site.

2) DPM is for one-time charges, though you can probably set up a subscription from a previous DPM transaction inside the control panel. If you want to do automatic recurring billing, you should look into CIM, hosted CIM, or ARB - probably hosted CIM with an iframe popup given your other requirements.

3) Not sure what you're saying here. You will need to be PCI compliant to some extent regardless of API - even solutions that go through Authorize.net will require basic password security on your end. Using DPM does allow you to avoid messing with data security, however, since the credit card data never actually passes through your hosting.

4) You don't technically need SSL if you're using DPM. However, nobody will enter their credit card info on your site if you don't have it. SSL certificates only cost like $50-$60 per year, just buy one.

5) None of the API's involve you storing credit card data. AIM, regular CIM, and ARB do involve you transferring credit card data through your hosting, however.

6) Every API returns a transaction ID, and generates an email receipt to the customer unless you turn that off. You should also receive settlement reports yourself and reports on failed transactions and so on.

[TJPride Expert · Accepted solution]

Some of your choices seem mutually exclusive.

1) DPM allows the credit card info to be entered through a URL at your site.

2) DPM is for one-time charges, though you can probably set up a subscription from a previous DPM transaction inside the control panel. If you want to do automatic recurring billing, you should look into CIM, hosted CIM, or ARB - probably hosted CIM with an iframe popup given your other requirements.

3) Not sure what you're saying here. You will need to be PCI compliant to some extent regardless of API - even solutions that go through Authorize.net will require basic password security on your end. Using DPM does allow you to avoid messing with data security, however, since the credit card data never actually passes through your hosting.

4) You don't technically need SSL if you're using DPM. However, nobody will enter their credit card info on your site if you don't have it. SSL certificates only cost like $50-$60 per year, just buy one.

5) None of the API's involve you storing credit card data. AIM, regular CIM, and ARB do involve you transferring credit card data through your hosting, however.

6) Every API returns a transaction ID, and generates an email receipt to the customer unless you turn that off. You should also receive settlement reports yourself and reports on failed transactions and so on.

[Housni]

Thanks for pointing me in the right direction. I'm going to give this a shot tomorrow.

I'll use DPM + hosted CIM.

I'm glad I don't have to implement PCI DSS completely...the last time I did that a couple of years ago, it wasn't too much fun :)

[Housni]

I checked out the PHP SDK and it looked quite simple so I just tried out DPM only.

Submitted an order and got a response.

However, my transaction ID shows up as 0 (zero) everytime.

I haven't posted any code because as long as my code didn't throw any errors/warnings/notices, the transaction ID should be generated by Authorize.net and sent to me, right?

I'm running all this in test mode...not sure if that's the issue.

Any advice, please?

Thanks.

[Housni]

Just in case, I followed these guidelines:

https://developer.authorize.net/guides/DPM/php.htm

And yes, I did correct the typos, in my code :)

[TJPride Expert]

If you're running in test mode, you're not going to get back a transaction ID. Testing should be done in live mode on a sandbox (developer) account.

[Housni]

I have one question related to the original post.

For one time payments, I display a form and use DPM to let the customer enter his details on my site and submit.

For recurring payments, I'm not sure how I should handle this.

If a customer is using this option for the first time, I should create a profile and store it's id via getProfileID() and then process the transaction, correct?

And for their recurring payment, I simply access their profile with that stored ID and charge them based on that.

Is the above description correct?

Also, I'm not sure I understand the difference between regular CIM and Hosted CIM.

[TJPride Expert]

Both CIM and hosted CIM store profiles and billing profiles. The difference is that data is collected on your site with regular CIM and passed to Authorize.net internally, while hosted CIM is done using forms entirely hosted on Authorize.net. For processing charges, the procedure is the same, you charge against the profile.

[Housni]

Alright, well in that case I'm using regular CIM since I want everything to be done within the site.

So I use DPM for one time payments.

For recurring payments, I'd run code to create a profile (createCustomerProfile()) and a payment profile (createCustomerPaymentProfile()).

This means that the customer enters their card details on the form hosted on my site and I don't save this data of course, but I use it to create the payment profile. Thereafter, I process their transaction based on the profile ID for that customer.

Have I got that right?

[TJPride Expert]

Well, hosted CIM can -sort- of be done within the site as well using iframe popups. If you're using DPM for one-time charging, it seems a pity to spoil your avoidance of PCI by using regular CIM for setting up credit card profiles. But I guess whatever works. If you decide to use regular CIM, then you may as well use AIM as well, since it involves less processing steps and therefore less delay for customers with really laggy connections.

And yes.