cancel
Showing results for 
Search instead for 
Did you mean: 

Do you know what this company is using for payment processing?

Hello,

 

I was wondering if anyone could tell me if this company was using authroize.net as their gateway, and if so which "version" of authorize.net they had. I would like to adopt their method since we too deal with digital goods.

 

I've linked over three screen shots. Screen shot  3 is not hosted on their site. The URL says worldpay, however worldpay is a merchant service not a gateway. Is their anyway to set up my site this way using authorize.net? I use a custom shopping cart, however I'm more concerned with not having to host my payment page, but be able to design the css and html of the hosted payment page. Also I like the idea of picking which CC type to use before having to go to the actual payment page.

 

http://i42.tinypic.com/23kxjxv.jpg

http://i40.tinypic.com/rkmqnl.jpg

http://i40.tinypic.com/2ajco5y.jpg

 

Thanks

blackfoot
Contributor
22 REPLIES 22

Thats for AIM rite?

 

I meant Authorize.net new DPM method; we can't really change much? I wanted to change the css of the fields to match our site theme

DPM has the form hosted by you, however the information entered into the form never passes through your server, it goes direct to Authorize.net.

 

AIM has the form hosted by you, but it submits to your server and then you pass the data internally to Authorize.net.

 

Both give you total control over the form, but DPM avoids PCI requirements while AIM definitely does not.

Can DPM be used on a custom shopping cart or does it have to be used with a compatable shopping cart? Also I called Authorize.net and I asked about DPM, and they didn't know if the payment form was in an iframe. I keep reading and it says that the credit card information does not touch our servers however how is this possible when we are the ones whose hosting the form and then passing the data along to Authorize.net?

For DPM, you are hosting the CC info form. But, when the use click the submit button, the form should post to authorize.net directly, which mean it wouldn't go thru your server.

YOU are not passing the data, the CUSTOMER is passing the data. All the form does is tell the customer's computer what data and where to send it. Yes, DPM can be adapted for use with anything (except recurring payments, that's a different subject...), and no, it's not in an iframe. It's just like a regular form, except it submits to Authorize.net. I know, it seemed a bit odd to me as well when I first found out about it.

I think I understand now. When the user clicks submit can I post the billing details to my server and at the same time send the entire form to authorize.net? Basically I would like to retain certain fields (customer address and name) and then pass along the rest authorize.net

No. However, the relay response feature built into DPM allows you to pick all that up again on the far side via the relay response page. You would just pass anything important like customer ID or session ID as a hidden field in the DPM form.

Shucks, none of the other methods would allow me to retain anything prior to passing to Authroize.net? 

Well...

 

Credit card data has to be submitted direct to Authorize.net for you to avoid PCI requirements, and you can't intercept data sent direct to Authorize.net (at least not without using Javascript...) Therefore, if your form has the user fill out their personal / shipping info and their credit card info on the same form, you can not intercept any of it on this, end, just the far end. However, you could theoretically have a two-part form, the first part to collect personal / shipping details and the second part to collect credit card details and go direct to Authorize.net. The second part would have all the info collected in the first part as hidden fields, and you could also store it in your db at the same time.

I just found this and was wondering if this goes against what you had said?

 

"WARNING: Merchant-Defined Data fields are not intended, and MUST NOT be used, to capture personally identifying information. Accordingly, Merchant is prohibited from capturing, obtaining, and/or transmitting any personally identifying information in or by means of the Merchant-Defined Data fields. Personally identifying information includes, but is not limited to: name, address, credit card number, social security number, drivers license number, state-issued identification number, passport number, and card verification numbers (CVV, CVC2, CVV2, CID, CVN). If Authorize.Net, a CyberSource solution, discovers that Merchant is capturing and/or transmitting personally identifying information by means of the Merchant-Defined Data fields, whether or not intentionally, CyberSource WILL immediately suspend Merchant�s account, which will result in a rejection of any and all transaction requests submitted by Merchant after the point of suspension."